Wie gelingt die Zusammenarbeit zwischen Digital Design und Entwicklung?

Hand-Off oder Hand-In-Hand?

Bei einem Kaffeeplausch vor einigen Wochen stellten meine Kollegin Barbara und ich fest: wir haben in unseren agilen Projekten ganz unterschiedliche Erfahrungen an der Schnittstelle zwischen Digital Design und Entwicklung gemacht. Dazu gehören Entwickler*innen, die in unsere (GUI-)Projekten „mit dem Anforderungsprozess nicht viel zu tun haben wollen – fertige Screen Designs reichen völlig aus“ und solche, die „von Anfang an bei jeder neuen Funktionalität bitte in den Anforderungsprozess einbezogen werden wollen“. Manche Entwickler*innen sagen uns „Wirf mir einfach Wireframes oder Papierscribbles rüber, damit komme ich klar“, während andere konkrete Vorgaben machen „Am besten zeigst du mir das Responsive Grid der Anwendung, indem du es selbst einmal programmierst“.

Mit dieser Erkenntnis und den vielen erlebten Stolpersteinen an dieser Schnittstelle im Gepäck machten wir uns auf Problem- und Lösungssuche. Warum ist diese Zusammenarbeit jedes Mal so überraschend anders? Warum führt sie so oft zu Problemen?

Kommunikation zwischen Rollen

Als Digital Designer*in ist es notwendig, nicht nur die Fachlichkeit zu kennen und zu schärfen, sondern auch einen Blick für die technische Umsetzung zu behalten. Dennoch muten wir uns nicht zu, bei den oben genannten Fragen alleine auf Ursachenforschung zu gehen.

Daher fragten wir vor einigen Wochen die geballte Entwicklungskompetenz unserer Firma mithilfe einer anonymen Online-Umfrage. Die spannenden Ergebnisse zeigen: eine frühzeitige Kommunikation und die gegenseitige Perspektiveinnahme sind das A&O für eine erfolgreiche Zusammenarbeit. Sie zeigen aber auch einen anderen wichtigen Punkt: als Digital Designer*in ist es essenziell, die Systemarchitektur von Beginn an gemeinsam mit dem Tech-Team zu erarbeiten und / oder fachliche Eckpunkte zu liefern, die die Systemarchitektur beeinflussen können. Was wir damit meinen, möchten wir euch mit unseren sieben Regeln für erfolgreiche Zusammenarbeit zwischen Digital Design und Entwicklung präsentieren.

Regel Nr. 1

Überlegt euch im Team, welche Dinge Feature- und Projektbezogen so früh wie möglich geklärt sein können.

Klar ändern sich Dinge. Nicht umsonst entwickeln wir agil. Aber wir sollten die Möglichkeit nutzen, feature- und v.a. projektbezogen gewisse Aspekte so früh wie möglich zu klären – damit sie uns später nicht überraschen und der Produktentwicklung Steine in den Weg legen.

Deshalb sind Projekt-Kickoffs, an denen das GANZE Team teilnimmt, essenziell. Hier muss besprochen werden, welche Zielgruppe das Produkt verfolgt, für welche Zielplattform(en) entwickelt wird, wie das Deployment laufen soll (z.B. Cloud, um besser skalierbar zu bleiben? Embedded?), wie es um Barrierefreiheit und Suchmaschinenoptimierung steht, welche besonderen Sicherheitsanforderungen zu beachten sind und natürlich wie der TechStack aussehen kann.

Featurebezogen sollten so früh wie möglich fachliche Anforderungen, besondere technische Einschränkungen / Anforderungen, ggf. Informationsarchitekturen und Screen Designs geklärt sein. In welchem Umfang die genannten Dinge vor Feature-Implementierung vorhanden sein müssen bzw. können, ist in jedem Projektumfeld und bei jedem Entwicklungsteam unterschiedlich.

Nehmt euch also bewusst die Zeit bzw. fordert sie vom Team und dem Kunden ein, um diese Fragen zu klären. Eine mögliche Antwort kann auch sein „Wird erst später entschieden“ – wichtig ist vor allem, über alle Punkte einmal gesprochen zu haben, damit ein einheitliches Verständnis im ganzen Team herrscht.

Regel Nr. 2

Der Aufwand von Änderungen hängt maßgeblich an der Architektur.

Bei einer komplexen Fachlichkeit ist die Architektur sinnvollerweise meist selbst so modular aufgebaut, dass Änderungen von Fachlichkeit oder Inhalten an der Anwendung leicht nachträglich umzusetzen sind. Bei einer einfachen Fachlichkeit und einer simplen Systemarchitektur dahinter ist die Anpassung von bestimmten Komponenten häufig komplizierter.

Das bedeutet nicht, dass eine simple Systemarchitektur schlecht ist. Es bedeutet einfach nur, dass jedes Projektmitglied dies im Hinterkopf behalten sollte und dass v.a. die Digital Designer*innen die Systemarchitektur kennen müssen und sich über den Aufwand bestimmter Anpassungen im Klaren sein müssen, da sie die Fachlichkeit und Änderungen an dieser maßgeblich (über Stakeholder und Endnutzer) einsteuern,.

In einem unserer Projekte hatten wir über 50 Backend-Services für eine Smartphone App. Dem DEV-Team und dem Digital Designer waren die Backend-Services nicht bekannt und so wurde der Einbau eines einfachen Buttons zu einer deutlich größeren Sache, als gedacht und kommuniziert. Hätten wir gewusst, dass der Button laut Architektur seine Informationen aus dem Backend bekommen soll, hätten wir direkt richtig schätzen und kommunizieren können.

Regel Nr. 3

Halte fest, welche Komponenten sich zukünftig ändern können.

Die nächstlogische Konsequenz aus Regel Nr. 2 ist es, frühzeitig anzusprechen bzw. festzuhalten, welche Komponenten sich mit welcher Wahrscheinlichkeit immer wieder ändern können.

Wenn man bei einer iOS-App-Entwicklung z.B. von Beginn an auf die iOS-Standardschrift setzt und dann von außen die Anforderung kommt, eine einzigartige Schriftart zu verwenden, die z.B. das Markenbild und die CI des Produkts besser unterstützt, steht das Team vor einem Problem. Das ist aufwändig, da der komplette Code nochmal angefasst werden muss. Ist von vornherein bekannt, dass die Schrift einmal einzigartig werden kann, kann dies von Anfang an berücksichtigt werden. Dann ist der Austausch einer Schriftart kein großer Aufwand mehr.

Sind solche Aspekte schon früh absehbar, sollten sie so früh wie möglich im Team und vor allem an die Entwicklung kommuniziert werden. Erfahrungsgemäß sind von diesen Aspekten v.a. angepasste Animationen, ein verändertes responsive Layout und Anpassungen der User Journey bzw. des Interaktionskonzepts betroffen. Hier fließen nicht nur hohe Entwicklungs- sondern ebenso hohe Testing-Aufwände ein.

Weit unproblematischer ist dahingegen oftmals die Anpassung von einzelnen Icons, Texten oder Bildern.

Regel Nr. 4

Lass Entwickler*innen an der Gestaltung der User Journey teilnehmen.

Diese Regel gilt fürs ganze Team! Die User Journey zu kennen und zu verstehen, in welchem Schritt der Journey der Nutzer mit welchen visuellen Reizen und welcher Benutzeroberfläche konfrontiert wird, ist essenziell, um sich fachliche und auch technische Fragen selbst beantworten zu können.

Vor allem für Entwickler*innen ist es z.B. auch notwendig zu wissen, ob die Nutzer*innen des Produkts durch einen Wizard geleitet werden oder in einer Anwendung interagieren, die es zulässt, jeden Bereich von überall aus erreichen zu können. Das hat wiederum Auswirkungen auf die Systemarchitektur (siehe Regel 2). 

Das Team hinsichtlich der fachlichen Anforderungen und wie diese sich in den einzelnen Schritten der User Journey widerspiegeln, up-to-date zu halten, ist wichtig. In einem unserer aktuellen Projekte haben wir die User Journey(s) visualisiert und für alle zugänglich gemacht, so halten wir sie auch aktuell. Über die Visualisierung konnten wir uns dann auch im ganzen Projektteam zu konkreten Schritten der Journey austauschen. Diese Journey kann auf einer digitalen Pinnwand auch leicht um technische Aspekte ergänzt werden, um eine Art Service Blueprint des Systems abzubilden.

Regel Nr. 5

Die Vision ist Ausgangspunkt und Grundlage für alle.

In der Entwicklung einer Smartphone App für E-Autos gehört es zu unseren Projektvisionen, Ladesäulen auf einer Karte anzuzeigen. Kontinuierliches Feedback der Endnutzer*innen erweiterte die Vision, sodass nun auch Tankstellen angezeigt werden sollten. Dies verursachte großen Aufwand, da die Systemarchitektur (siehe Regel 2) komplett umgearbeitet werden musste.

An diesem Beispiel erkennt man gut die Wichtigkeit einer Vision. Die Vision ist richtungsweisend für die komplette Fachlichkeit der Produktentwicklung. Schärfen wir die Vision, so schärfen wir gleichzeitig die Fachlichkeit. Sie wird greifbarer, konkreter und besser testbar. Ändert sich die Vision, so ändert sich meist auch die Fachlichkeit. Das ist okay, muss aber von allen Projektmitgliedern verstanden werden.

Einzelne Zitate aus unserer Umfrage belegen zudem, wie wichtig es ist, eine Vision zu haben, die allen bekannt ist:

• Kenne ich die Vision, kann ich mir daraus Antworten auf aufkommende Fragen selbst ableiten und/oder sinnvolle Lösungsvorschläge machen.
• Wenn ich ein konkretes Ziel habe, verliere ich nicht so viel Zeit mit “what if”-Fragen.
• Ohne Vision hätte ich keine sinnvolle Entscheidungsbasis für so gut wie … alles
• Die Vision hilft mir dabei, für die gute Experience des Endnutzers und nicht für den PO zu entwickeln.
• Die Vision erklärt mir, wie ein Feature in das große Ganze passt. So kann ich sinnvolle Vorschläge machen, falls ein Spezialfall nicht definiert ist.

Regel Nr. 6

Tools helfen, sind aber kein Allheilmittel.

Bei der Entwicklung von graphischen Benutzeroberflächen können für den Austausch zwischen Design und Entwicklung sogenannte Hand-Off-Tools genutzt werden. In diesem hinterlegt der/die Designer*in Screendesigns, die der/die Entwickler*in dann benutzen kann – mit Abständen, Icons zum Herunterladen, fertigen CSS, …

Solche Handoff-Tools helfen uns im Alltag oft in Projekten, in denen wir eine graphische Benutzeroberfläche erstellen. Sie ermöglichen es den Entwickler*innen, die visuellen Anforderungen an eine Produktseite oder -komponente einzusehen und Farbcodes, Schriftarten oder Abstände zu entnehmen. Oft helfen sie durch eine Kommentarfunktion auch beim Austausch über neue Screen Designs im ganzen Team. Sie sind dennoch kein Ersatz für eine vollumfängliche Hand-in-Hand-Zusammenarbeit. Meist werden User Journeys durch das Nutzen eines Handoff-Tools nicht deutlich und viele Screen Designs bilden oft nur Happy Cases ab und vernachlässigen Edge Cases.

Bei Fragen verlangsamen solche Tools manchmal den ganzen Prozess und tragen durch ihre Nutzung nicht automatisch dazu bei, dass Silos zwischen Entwickler*innen und Digital Designer*innen vermieden werden. Es ist wichtig, dass wir miteinander reden und im ständigen Austausch und gegenseitigem Verständnis bleiben.

Regel Nr. 7

Redet Miteinander!

Die wichtigste Regel von allen: nur durch eine frühzeitige, offene Kommunikation kann die Basis für eine erfolgreiche Produktentwicklung und effiziente agile Projektarbeit geschaffen werden. Es ist wichtig, vor dem Start der Entwicklung und immer wieder währenddessen Aspekte der Zusammenarbeit und der gemeinsamen Schnittstellen zu besprechen und Verantwortlichkeiten festzulegen. Wer das nicht tut, stolpert mit großer Sicherheit im weiteren Projektverlauf über Missverständnisse und Aufwände, die auf Fehlkommunikation basieren.

In meinem aktuellen Projekt hat der fehlende Austausch zu Projektbeginn dazu geführt, dass wir im 3. Sprint mit einer Situation konfrontiert waren, in der sowohl mein Entwicklerkollege als auch ich der festen Überzeugung waren, dass das Responsive Grid der Anwendung im Verantwortungsbereich des jeweils anderen liegt. Nachdem mich mein Kollege fragte, ob ich das Grid schon code-technisch umgesetzt und damit auf Machbarkeit geprüft habe, war ich zunächst ziemlich überrascht. Ich dachte, mit den entsprechenden Screen Designs zu den einzelnen Breakpoints ist mein Aufgabenbereich abgeschlossen. Diese Situation, die uns Zeit und Nerven gekostet hat, hätten wir vermeiden können, wenn wir uns am Anfang unserer Zusammenarbeit die Zeit genommen hätten, über genau solche Aspekte zu sprechen.

Checkliste für den Start

Nur ein funktionierendes Team schafft ein erfolgreiches Produkt. Mit diesem Gedanken und den Regeln im Hinterkopf hoffen wir, die Zusammenarbeit speziell zwischen Digital Design und Entwicklung verbessern zu können. Für einen besseren und strukturierten Austausch zwischen Digital Designer*in und Entwickler*in haben wir eine Checkliste erstellt, die sowohl zu Beginn einer Zusammenarbeit, genauso aber auch immer wieder währenddessen herangezogen werden kann. Sie ist eine Kommunikationsgrundlage, mit der die wichtigsten Aspekte für den erfolgreichen Verlauf eines Projekts sowie eine gute und effiziente Zusammenarbeit sichergestellt werden kann.

Wir empfehlen euch, die Checkliste gemeinsam mit allen direkt am Produkt beteiligten Digital Designer*innen und Entwickler*innen durchzugehen, um ein gemeinsames Vorgehen und Zusammenarbeitsmodell zu definieren. Je nach Größe und Anzahl der Beteiligten solltet ihr euch dafür mindestens eine Stunde und maximal zwei Stunden Zeit nehmen. Solltet ihr nach zwei Stunden noch nicht alle Fragen der Checkliste beantwortet haben, lohnt es sich, eine Pause einzulegen und zu einem späteren Zeitpunkt weiter zu machen.

Ihr könnt die Checkliste hier als bearbeitbares pdf herunterladen.

Wir freuen uns sehr über eure Gedanken zu diesem Thema und eure Erfahrungsberichte, wenn ihr die Checkliste selbst einmal ausprobiert habt.

Anmerkung:

Wir haben das Thema im Rahmen der Konferenz Modern RE als Vortrag präsentiert.

---

Über den Autor