Manchmal scheinen Designer und Entwickler einfach unterschiedliche Sprachen zu sprechen. Kein Wunder – während der Eine sich auf Funktionalität im Backend konzentriert, arbeitet die Andere vorrangig an Usability und Ästhetik im Frontend. Da kann es leicht zu Verständnisproblemen kommen, unter denen schlimmstenfalls das Produkt bzw. die Kund*in leidet.
Die gute Nachricht: Da muss nicht sein!
Entwickler- und Designerteams können gut und effizient miteinander arbeiten, wenn sie dabei auf ein altbewährtes Mittel setzen: gute Kommunikation. Wie das funktioniert, erfahren Sie hier.
Wenn Entwickler und Designer einander nicht verstehen (können)
Entwickler und Designer haben es in der Zusammenarbeit oft recht schwer. Was die Eine will, kommt dem Anderen in die Quere und andersherum. Um herauszufinden, woran das liegt und wie beide Teams zu einer überzeugenden, gemeinsamen Vision kommen können, sollten wir einen Blick auf die unterschiedlichen Positionen werfen.
Nehmen wir an, Sie sind Designerin und arbeiten an einer hochkarätigen Front-End-Lösung für einen Kunden. Sie und Ihr Team haben in langen Brainstormings, Feedbackrunden und User-Experience-Tests eine Vision entwickelt, die Ihren Kunden begeistern wird. Da sind Sie sich sicher! Im Kickoff-Termin für den folgenden Sprint präsentieren Sie Ihre Ideen nun den anderen Teams aus Ihrem Unternehmen. Die Redaktion ist begeistert von Ihrer Kreativität, HR freut sich über Motivation und Teamgeist des Designer-Teams und auch die CEOs finden Ihr Design richtig gut. Nur ein Team stellt sich quer: die Entwickler. „Nicht umsetzbar, zu kompliziert, fehleranfällig“ und so weiter lauten die Begründungen. Sie sind enttäuscht, in ihrem Enthusiasmus vor den Kopf gestoßen und denken vielleicht: „Was für Spaßbremsen!“ Nach langen Diskussionen, die schon fast im Streit münden, verlassen Sie das Meeting zerknirscht, wenig motiviert und vielleicht sogar kreativ gehemmt. Eventuell haben Sie gar das Gefühl, nicht ernst genommen zu werden, weil sie kein Entwicklerdeutsch sprechen. Keine gute Ausgangsposition für den nächsten Sprint, nicht wahr?
Aber wie sieht es auf der Gegenseite aus?
Nehmen wir also an, Sie sind Entwickler. Gemeinsam mit Ihrem Team haben Sie Vollgas gegeben, um eine passable User Story zu entwickeln. Sie haben Akzeptanzkriterien für das zu entwickelnde Produkt geschaffen und bereits mit Hochdruck daran gearbeitet, diese für Ihren Kunden technisch einwandfrei zu erfüllen. Damit sind Sie auf dem besten Weg zur optimalen Gesamtlösung laut User Story. Und nun das: Design tritt auf den Plan und fordert plötzlich eine Nutzeroberfläche, die nahezu unmöglich zu implementieren ist. Und warum? Weil’s geil aussieht? Ihrer Meinung nach ist das kein Argument dafür, einen nahezu perfekten Code möglicherweise zu zerschießen bzw. die Fehlerquote erheblich zu erhöhen. Usability ist schließlich nicht nur Look, sondern in erster Linie auch Funktionalität. Darum ginge es ja, wirft das Designer-Team ein. Denn UX-Tests hätten gezeigt, dass genau dieses Design von Nutzer*innen bevorzugt würde. Natürlich ist es wieder genau das Design unter allen, das am schwersten zu implementieren ist.
Das Schlimmste: Alle Versuche, dem Design-Team zu erklären, warum die neuen Designs nicht umsetzbar sind, stoßen auf taube Ohren. Zwar sagt es Ihnen niemand, aber Sie wissen genau: Hier halten Sie alle bloß für unkreativ und unnachgiebig. Unfair, finden Sie. Nach dem Meeting gehen Sie entnervt und ermüdet an Ihren Platz zurück und müssen sich erstmal eine verdiente Runde ärgern, statt bestärkt in die Tasten zu hauen. Nervig, nicht wahr?
Sie sehen: Beide Teams in diesem Beispiel sind demotiviert und eine Lösung ist in weite Ferne gerückt.
Kommunikation schafft Nähe: Auch im Scrum-Prozess
Ist Ihnen aufgefallen, was schiefgelaufen ist? Es war vor allem die Kommunikation, die hier fehlerhaft war. Beide Teams haben ihren Standpunkt verteidigt und dabei kaum den Blickpunkt gewechselt. Dabei kann das Wunder wirken. Denn die besten Lösungen entstehen, wie wir alle wissen, in der Zusammenarbeit. Und die kann nur fruchtbar sein, wenn wir einander zuhören. Das ist im Scrum genauso wie überall sonst. Deshalb lautet die Devise: Entwickler und Designer müssen miteinander sprechen – miteinander, nicht gegeneinander. Und zwar von Beginn bis Finalisierung des Projekts. Leichter gesagt, als getan ... oder?
Goldene Regeln für die Zusammenarbeit von Design und Entwicklung
Gut, dass es auch hierfür Regeln gibt, die einfach und effizient umzusetzen sind.
- Entwickler- und Designer-Teams sollten (virtuelle) Nachbarn sein
Am besten spricht es sich face-to-face oder in gemeinsamen Gesprächen außerhalb größerer Meetings. Dies kann sowohl durch räumliche Nähe begünstigt werden als auch durch virtuelle Formate, die im plausch zwischendurch helfen, das Verständnis füreinander zu vertiefen. In Zeiten von Corona und komplett Remote arbeitenden Teams haben wir bei Ambient vor einiger Zeit den Versuch gestartet zusätzlich hierfür ein virtuelles Büro zu schaffen.
Es klingt simpel, aber es ist enorm wirkungsvoll: Je größer die Nähe und das Vertrauen im Team, desto größer das „Wir-Gefühl“. Gerade bei so unterschiedlich gepolten Teams wie Entwicklern und Designern sollte man sich an diese goldene Regel erinnern. Denn wer will schon Streit mit den Nachbarn ...? Eben!
- An der Arbeit der Anderen teilhaben
Designer und Entwickler können viel voneinander lernen. Schließlich arbeiten sie an einer gemeinsamen Gesamtlösung, wenn auch an verschiedenen Schnittstellen. Gerade weil Designer oft kaum Programmierkenntnisse haben und gerade weil Entwicklern meist das Auge fürs Design fehlt, ergänzen sie sich gut. Mehr noch: Sie brauchen einander. Kein Entwickler-Team funktioniert ohne Designer und kein Designer-Team kommt ohne Entwickler aus.
Insbesondere bei großen Projekten ist es darum wichtig, dass Sie einander regelmäßig informieren, abholen und um Rat fragen. Designer sollten frühzeitig eine*n Entwickler*in um seine Meinung bitten, ob und wie ein Designwunsch ggf. umzusetzen ist. Andersherum sollten Entwickler sich an Designer wenden, wenn sie feststellen, dass ein Backend-Problem sich aufs Design auswirkt. Ein Nebeneffekt dieser kooperativen Arbeitsweise ist, dass sich jedes Team vom anderen wertgeschätzt fühlt – und dieses Gefühl sorgt bekanntermaßen für beste Ergebnisse.
- Pairing is sharing: Entwickler-Designer-Teams bilden
Kombiniert man nun diese beiden Elemente „Nachbarschaft“ und „Teilhabe“, gelangt man zu einem formidablen Konzept, um zwei Teams einander näherzubringen: Pairing. Bilden Sie im großen Team jeweils kleine Zweierteams, bestehend aus einer Designerin und einem Entwickler, beugen Sie Verständnisproblemen bestens vor. Wenn beide direkt nebeneinander arbeiten, werden Missverständnisse blitzschnell aufgeklärt und beide bekommen ein tiefgehendes Verständnis für die Arbeit des oder der Anderen. Das wird sich nicht nur positiv auf das aktuelle Produkt, sondern auf alle Folgeprodukte auswirken.
- Das UX-Design sollte von Anfang an in den Entwicklungsprozess integriert werden
Oft besprechen Entwickler und Product Owner, beziehungsweise Kunde, das zu entwickelnde Produkt, während Designer außen vorgelassen werden. Ein Fehler, wenn man bedenkt, wie wichtig UX-Design für eine ansprechende Gesamtlösung ist. Deshalb sollten Designer von Anfang an in den User Storys Beachtung finden, und zwar von Sprint 0 an. Damit ist die Vorlaufphase einer jeden Produktentwicklung gemeint, in der ein Verständnis des zu entwickelnden Produkts erarbeitet und die technischen Voraussetzungen zur Umsetzung geschaffen werden. Wir nennen diesen Sprint 0 Konzept-Sprint. Er gehört bei uns zu jeder Projektentwicklung und das aus gutem Grund.
Wie wir solche Konzept-Sprints effektiv umsetzen, erfahren Sie in diesem Video:
https://www.youtube.com/watch?v=ef91jKTov_w
Dass hierbei auch UX eine Rolle spielen sollte, versteht sich eigentlich von selbst. Schließlich müssen die Anforderungen nicht nur technischen Aspekten genügen, sondern auch userfreundlich sein. Dennoch ist es bei vielen Unternehmen noch heute so, dass Designer-Teams erst später mit ins Boot geholt werden. Das führt zu einem Informationsüberschuss der Entwickler gegenüber den Designern.
Dieses Ungleichgewicht wiederum führt leicht zu Verwirrung, Missverständnissen und Meinungsverschiedenheiten, die später schwer aus der Welt zu schaffen sind. Alles das geht auf Kosten des Produkts. Um dies zu vermeiden, ist es wichtig, dass Entwickler, Designer, Product Owner und bestenfalls Kunde schon jetzt zusammenkommen und gemeinsam eine Vision erarbeiten.
Daily Meetings zwischen den Teams sind in dieser Projektphase unbedingt angeraten. So können Verständnishürden aus dem Weg geräumt und der Grundstein für eine effiziente Zusammenarbeit gelegt werden. Auch erste Schritte des UX-Designs können jetzt schon umgesetzt werden, beispielsweise die Erstellung von Personas. Entwickler-Teams können so bereits jetzt leichter einschätzen, welchen Aufwand die Implementierung des Designs erfordern könnte.
- Gemeinsame Scrum-Meetings beider Teams
Oft ist es so, dass Designer-Teams an vielen Scrum-Meetings auch später gar nicht teilnehmen, sondern Entwicklung und Product Owner diese allein durchführen. Ein Fehler, denn auch wenn die technischen Aspekte der Entwicklung dabei oft im Vordergrund stehen, ist es wichtig, dass auch Design-Teams informiert sind, um eventuelle Schwierigkeiten oder Änderungen der Anforderungen sofort in ihre Arbeit zu integrieren.
- Agil bleiben
Wie überall im Scrum, gilt auch in puncto Entwickler-Designer-Zusammenarbeit: Agilität lohnt sich. Es ist wenig sinnvoll, von Anfang an feststehende User Storys zu entwickeln, wenn sich die Bedürfnisse des Kunden mit hoher Wahrscheinlichkeit ändern werden. Dasselbe gilt fürs Design: Ein mühsam ausgearbeitetes UX-Design ist in den ersten Sprints zu früh dran. Mit den Anforderungen an die User Storys werden sich auch die Anforderungen ans Design ändern. Deshalb empfiehlt es sich, agil im Austausch zu bleiben. Ein erster Design-Entwurf muss immer wieder anhand von Prototypen getestet werden und kann dann bereichernd in die User Story einfließen.
- Deutlich kommunizieren
Ein großes Problem, wenn Entwickler und Designer zusammenkommen, ist, dass sie sich auf sehr verschiedene Weisen ausdrücken. Wenn ein Designer „A“ sagt, versteht ein Entwickler oft „B“ und umgekehrt.
Das passiert natürlich nicht nur im Scrum-Kontext. Aber dort wird es zum Problem, wenn das Entwickler-Team nach einem Meeting mit dem Design eine Anforderung implementiert, die so gar nicht gemeint war.
Umgekehrt können technische Erklärungen der Entwickler von Designern so falsch verstanden werden, dass die nächsten Wireframes der Designer auf unrealistischen technischen Möglichkeiten basieren. Kurz gesagt: Wenn solche Missverständnisse aufkommen, kommt dabei oft Mumpitz raus. Das sorgt nicht nur für Ärger bei den Mitarbeiter*innen, sondern kostet. Um das zu vermeiden, hilft es, User Storys und Design-Anforderungen genau, einfach und für Laien verständlich zu formulieren. Wichtiger Skill hier: Zuhören. Hören Sie Ihre*r Gesprächspartnerin aufmerksam zu. Fragen Sie nach, wenn Sie etwas nicht verstanden haben. Am besten fassen Sie am Ende noch einmal zusammen, was Ihr*e Kolleg*in Ihnen gerade gesagt hat. Eine gute Methode: Lassen Sie Ihre Anforderungen von eine*r Mitarbeiterin aus einem völlig anderen Team wie Finance oder Marketing lesen oder erklären Sie ihnen diese. So können Sie sichergehen, dass das, was Sie formuliert haben, auch von Fachfremden verstanden werden kann.
- UI-Kits verwenden
Ein praktisches Mittel, um Mehrarbeit zu vermeiden, sind UI-Kits. Damit gemeint sind Sets visueller Tools wie Fonts, Icons und Layers, die Sie immer wieder verwenden können. Einigen sich beide Teams, Entwickler und Design, auf ein solches UI-Kit, ist der optische Rahmen von Beginn an deutlich definiert und technische Lösungen sind schneller greifbar.
"Design und Entwicklung müssen miteinander sprechen ... oder tanzen. "
Fazit: Design und Entwicklung müssen miteinander sprechen ... oder tanzen
Kommunikation ist also, wie so oft, das erste Mittel der Wahl, wenn es um die Zusammenarbeit von Designern und Entwicklern geht. Ist Ihnen zu abstrakt? Dann können Sie sich die Interaktion zwischen User Experience Design und Entwicklung wie einen Paartanz vorstellen: Wenn Eine einen Schritt nach vorne macht, muss der andere mitgehen und umgekehrt. Je harmonischer die Tanzschrittfolge, umso umwerfender das Gesamtergebnis. Genauso ist es auch bei der Entwicklung digitaler Produkte: Wenn Design und Entwickler aneinander vorbeireden, einander auf die Füße treten oder jede*r für sich tanzt, kann die perfekte Lösung lange auf sich warten lassen. Aber wenn sie einander verstehen, führen und zusammenarbeiten, gelangen Sie zu brillanten Ergebnissen.
