Blog

Workflow | 17.08.2020, von Mats Kubiak

Wie wir agil Designsysteme entwickeln

Und warum wir dabei das Risiko des Scheiterns minimieren

Haben Sie als AuftraggeberIn schon mal Angst davor gehabt, dass die Agentur doch nicht das liefert, was Sie sich vorgestellt haben? Als Agentur schon mal gefürchtet, dass der Auftraggeber das neue Design zu sehr am Thema vorbei findet? Beides keine unbegründeten Ängste – zumindest letzteres haben wir selbst schon mal erlebt. Konkret sah unser vermeintliches Scheitern so aus, dass wir von sipgate mit dem Entwurf für ein neues, visuelles Erscheinungsbild beauftragt worden sind und es unser Vorentwurf – nach fast drei Monaten harter Arbeit – leider nicht geschafft hat, zu überzeugen. Wie wir das Projekt dennoch zu einem gelungenen Ergebnis bekommen haben, hat viele interessiert.

Zunächst muss man sagen, dass sipgate im Vorfeld schon eine ganze Reihe an Strategie-Arbeit mit hochrangigen Experten hinter sich hatte. Unser Briefing basierte also zu einem großen Teil auf Ergebnissen, die wir nicht gemeinsam im Dialog erarbeitet haben, sondern die durch externe Dienstleister entwickelt wurden. Nachdem wir den Vorentwurf präsentiert hatten, hat sich dann leider schnell herausgestellt, dass wir zwar sauber entlang des Briefings gearbeitet hatten – rein funktional waren alle Anforderungen an das Designsystem erfüllt – trotzdem hat sich das Ergebnis für sipgate nicht richtig angefühlt. Was war passiert? Wir haben bestimmte Aspekte der Brand Personalty ganz anderes interpretiert, als die Verantwortlichen von sipgate. Markenattribute wie »stylisch und geeky«, die im Vorfeld definiert wurden, bieten jede Menge Interpretationsspielraum und bedeuten letztendlich für jeden etwas anderes. Und genau das war das Problem.

Daraus haben wir gelernt: das Thema Markenpersönlichkeit ist absolut essentiell in jedem Branding-Prozess und sollte niemals ausgelagert werden. Man kann im Vorfeld gar nicht genug miteinander reden, um ein möglichst präzises, gemeinsames Verständnis für die Marke zu entwickeln. Seitdem bestehen wir konsequent darauf, zum Kick-off mindestens einen gemeinsamen Workshop mit allen Stakeholdern durchzuführen – völlig unabhängig davon, ob darauf ein klassischer oder ein agiler Arbeitsprozess aufbaut. Im diesem Fall kam noch ein weiterer Aspekt hinzu: für sipgate selbst ist agile Zusammenarbeit quasi der natürliche Arbeitsmodus. Um von nun an deutlich effektiver ans Ziel zu kommen, haben wir uns deshalb gemeinsam dazu entschieden, ihre Arbeitsprinzipien auf unseren Designprozess zu adaptieren. 

g31 Agile Design Process Scrum
Unser agiler Designprozess im Scrum-Framework

Die Umstellung auf einen agilen Prozess frei nach Scrum war eine Herausforderung, da es ein Framework ist, das nicht unbedingt dazu gedacht ist, in einem Team aus zwei Parteien an zwei verschiedenen Standorten zu arbeiten. Zunächst haben wir Designsprint-Zeiträume von zwei Wochen festgelegt. Jeden Sprint haben wir mit einem Kick-off Termin zum »Backlog Refinement« bzw. »Sprint Planning« begonnen. Dabei haben wir gemeinsam mit sipgate die Erwartungen und Ziele des jeweiligen Sprints definiert. Anschließend haben wir unser internes g31 »Sprint Backlog« erstellt und unsere Aufgaben priorisiert – mit dem Ziel, am Ende der zwei Wochen ein brauchbares Designsystem-Einzelteil zu erhalten. Im Fachjargon: »Inkrement«. Hier gilt es darauf zu achten, dass die jeweiligen Aufgaben klein genug sind, um sie im vorgegebenen Zeitraum absolvieren zu können. Im Backlog wird also nicht stehen »Corporate Design« sondern eher eine Teilaufgabe wie z.B. »Schriftsystem«. Sollte diese Teilaufgabe noch zu groß für den definierten Zeitraum sein, wird sie so lange unterteilt, bis sie in der vorgegebenen Zeit lösbar ist. Um beim vorangegangenen Beispiel zu bleiben, könnten sinnvolle Teilaufgaben beispielsweise »Schriftauswahl«, »Schriftgrößen«, »Zeilenabstände«, »Laufweiten« usw. lauten. Mit solchen Inkrementen sind wir dann gemeinsam mit sipgate in die Review gegangen und haben geprüft, ob sie direkt in das Designsystem einfließen können oder ob wir noch einen weiteren Sprint darauf drehen müssen. 

Konkret haben sich unsere Prozesse während des Sprints eigentlich gar nicht so sehr von der Art und Weise unterschieden, wie wir auch vorher schon in Designprozessen gearbeitet hatten. Laut Scrum sollte man sich einmal täglich in einem 15 minütigen Daily Scrum Meeting austauschen. Das mag in der Software-Entwicklung etwas Besonderes sein – vielleicht haben wir nicht umsonst Bilder von einsamen Entwicklern im Kopf, die nur selten das Tageslicht sehen. In unserem Designsprozess mit mehreren Gestaltern wäre es schlichtweg unpraktisch, sich nicht morgens zum Kaffee und Abends zum Feierabend noch ein mal über den aktuellen Stand des Projekts auszutauschen. Eine weitere Angewohnheit, die wir längst kultiviert hatten, war uns dabei behilflich, unnötige Arbeit für die Sprint Reviews zu vermeiden: das Anheften aktueller Entwürfe an unsere Bürowände. Jede Skizze und jeden Entwurf hängen wir zur Diskussion an die Wand (ja, auch Webdesigns). So konnte man sich in den Diskussionen frei am Entwurfsprozess entlang hangeln und gezielt über einzelne Probleme sprechen. Das hat zudem den positiven Nebeneffekt, dass man Meetings nicht mittels einer extra angefertigten Präsentation vorbereiten muss und hier kein zusätzlicher Aufwand entsteht – ganz im Sinne einer leanen Arbeitsweise.

g31 x sipgate Agile II
Frühes Stadium des sipgate Entwurfs an unseren Bürowänden

Unsere agilen Designprozesse sehen bis heute ähnlich aus – hängen im Einzelnen aber auch immer von Auftrag und Auftraggeber ab. Den einen perfekten, agilen Prozess kann es unserer Meinung nach sowieso nicht geben, da zu viele Variablen die Zusammenarbeit bestimmen. Eine Sache haben aber alle Folgeprozesse bisher gemein: wir leisten uns mindestens vier Wochen Startzeit, bevor wir in die eigentliche Sprintphase übergehen. Das gibt uns die Möglichkeit, uns initial tief in ein Thema einzuarbeiten und frei von Zeitdruck erste visuelle Experimente zu wagen. Zudem haben nur wenige Auftraggeber das Designverständnis und Abstraktionsvermögen, um die in dieser frühen Projektphase häufig noch rohen, visuellen Skizzen richtig einordnen zu können.

Die Vorteile eines solchen Vorgehens sind für beide Seiten groß. Indem Auftraggeber laufend in den Designprozess eingebunden werden, können sie ihre Wünsche und Anforderungen viel präziser ausformulieren, als in einem einmaligen Briefing. Gleichzeitig profitiert man als Agentur von diesem laufenden Austausch und hat deutlich mehr Gelegenheit, für ein gemeinsames Designverständnis zu werben. Kurzum: man spricht viel häufiger, intensiver und zielführender miteinander. Und das führt unserer Erfahrung nach zwangsläufig zu besseren Ergebnissen. 

Potentielle Haken gibt es natürlich trotzdem. Wenn man einen solchen Prozess nicht streng fokussiert steuert, besteht immer die Gefahr, dass er ausufert. Beispielsweise ist es für Auftraggeber immer reizvoll, alle möglichen Richtungen detailliert explorieren zu lassen, weil es sie zunächst davor bewahrt, sich festlegen zu müssen. Gleichzeitig ist das natürlich aufwendig, kostet Zeit und Geld und führt im schlimmsten Fall zu Frustration auf beiden Seiten. Hier gilt es immer gemeinsam abzuwägen, wie viele Iterationen wirklich nötig sind, um ein gewünschtes Ziel zu kommen. 
 

g31 x sipgate Agile III
Gemeinsame Sprint-Review

Die Frage nach dem richtigen Prozess ist für uns seitdem zu Beginn jeder Zusammenarbeit zentral. Unserer Erfahrung nach gilt die Faustregel: je komplexer eine Aufgabenstellung, desto sinnvoller ist eine agile Zusammenarbeit zwischen Auftraggeber und Agentur. Designprozesse sind immer auch Lernprozesse – für beide Seiten. Regelmäßige Feedback-Loops helfen dabei, möglichst schnell ein tiefes, gemeinsames Verständnis für komplexe Problemstellungen zu gewinnen. Das Arbeiten in kurzen Designsprints sorgt zudem dafür, dass man nicht vom eingeschlagenen Weg abkommt und falls doch, man schnell wieder in die Spur findet. Man ist in der Lage, flexibel auf wechselnde Anforderungen zu reagieren und neu gewonnene Erkenntnisse schnell und effektiv in laufende Projekte einfließen zu lassen. 

Trotzdem sind agile Arbeitsprozesse kein Allheilmittel. Wir glauben sowieso nicht, dass es den einen richtigen Prozess gibt, sondern immer nur den passendsten für das jeweilige Team, das jeweilige Projekt und den jeweiligen Auftraggeber. Auch komplexe Projekte lassen sich innerhalb eines klassisches Designprozesses hervorragend bewältigen, wenn man vorher innerhalb einer ausführlichen Strategie- und Briefing-Phase seine Hausaufgaben macht. Am Ende kommt es (wie immer) weniger auf den Prozess selbst an, sondern in erster Linie auf die Menschen, die innerhalb bestimmter Frameworks zusammenarbeiten. Prozesse sind immer nur Mittel zum Zweck – nicht mehr und nicht weniger.

Blog

Ähnliche Beiträge