Komplexer Code ist ein Design-Problem

Design Thinking: Wie man Brücken zwischen Entwickler und Designer baut
Keine Kommentare

Zwischen Produktdesignern und Entwicklern kommt es nicht selten zu Spannungen. Oft wollen Designer neue Funktionen umsetzen, die die Entwickler möglicherweise für unnötig und zu arbeitsintensiv halten, während Designer den Eindruck haben, dass Entwicklern die Nutzer und deren Wünsche egal sind. In diesem Artikel gehen wir der Frage nach, warum Design Thinking eine Portion Ingenieur-Denke vertragen kann.

Folgende Situation dürfte bekannt sein: Das Produktteam sitzt in einem Konferenzraum und die Designer präsentieren neue Funktionen. Es folgt eine lange Pause. Schließlich sagt einer der Entwickler: „Müssen wir das wirklich alles bauen?“ Spannung macht sich breit, Arme werden verschränkt.

Die Entwickler sind frustriert. Aus ihrer Sicht zwingen ihnen Designer Produktmerkmale auf, ohne auf ihre eigenen Erfahrung oder Bedürfnisse einzugehen. Und das obwohl sie letzten Endes die Hauptlast der Arbeit tragen und sich aufreiben, wenn etwas schief geht. Die Designer dagegen haben den Eindruck, die Entwickler sind überhaupt nicht daran interessiert, die Nutzer zu begeistern oder ihre Wünsche zu erfüllen.

Diese Missverständnisse zwischen Technikern und Designern wirken sich unter Umständen negativ auf die Stimmung im Unternehmen und die Qualität der Produkte aus. Wenn den Entwicklern ein prominenterer Platz im Designprozess eingeräumt wird und sich Designer und Entwickler aktiv mit den jeweils anderen Anliegen auseinandersetzen, können die Effekte verblüffend sein.

Das einzige Mittel

Design liefert keinen direkten Nutzwert und im Software-Geschäft ist der Quellcode das einzige Mittel zur Wertschöpfung. Das beste Design der Welt ist wertlos für den Nutzer, wenn es bloß in Form einer Skizze, eines Modells oder eines Prototyps vorliegt. Produktiver Code ist das Medium, über das der Anwender mit dem Produkt interagiert und Nutzen daraus zieht. Deshalb müssen Designer lernen, der Codequalität Beachtung zu schenken.

In den meisten Fällen ist die Bedeutung der Codequalität für ein gutes Benutzererlebnis (UX) offensichtlich. Wenig optimaler Code führt beispielsweise unmittelbar zu einer geringen Ablaufgeschwindigkeit, ein Fehler kann dazu führen, dass Kunden sich abwenden.

Doch der wichtigste Faktor, mit dem sich auch Designer beschäftigen sollten, ist der schwierigste: Schleichende Komplexität oder Entropie. Sie ist ein kniffliges Problem, denn sie entsteht langsam über die Zeit, wenn das Produkt zwiebelartige Schichten aus neuen Funktionen ansetzt. Diese gewachsene Komplexität hindert das Produkt daran, sich zu verändern, sich anzupassen und zu verbessern. Vereinfacht ausgedrückt: Komplexität schwächt ein Produkt durch zusätzliche Kosten. Entwickler sollten daher übermäßige Komplexität möglichst vermeiden. Sonst fühlen sie sich nach einiger Zeit überfordert, wenn sie neue Features umsetzen sollen. Dies führt dann zu den üblichen Feindseligkeiten zwischen Designern und Codern.

Code-Komplexität oder Entropie sind schwer zu begreifende Probleme für jeden, der keine Praxis in der Entwicklung hat. Aber sie belastet die Entwicklungsprozesse und Entwickler sind in der Regel die einzigen, die darauf achten. Auch wenn Entwickler in erster Linie an den Aufwand denken und Designer hauptsächlich an den Nutzwert: Der Wert eines Features sollte gleichzeitig mit Blick auf technische Kosten und Anwendernutzen betrachtet werden. Um produktive Gespräche über diesen Zusammenhang zu führen, müssen aber alle Beteiligten das zu lösende Problem im Detail verstehen.

Lösungen für den einmaligen Gebrauch

Sobald Designer die Anwenderprobleme verstanden haben, entstehen Lösungsideen mit zwei wünschenswerten Eigenschaften. Erstens sind sie stark in den tatsächlichen Kundenbedürfnissen verankert und zweitens entstehen sie leicht und in großer Zahl. Wenn es reichlich Lösungen gibt, muss niemand an einer davon festhalten. Sie besitzen nun eine neue Qualität: Sie sind frei verhandelbar. Designer sollten deshalb für jedes Benutzerproblem möglichst viele Ideen so einfach wie möglich darstellen, beispielsweise mit Modellen oder Skizzen. Wenn Ideen auf diese Weise präsentiert werden, wirken sie weniger kostbar. Sie können leichter verworfen oder beiseite gelegt werden.

Ideen verwerfen – für den Anwendernutzen

Angenommen, ein Designer hat zwei Ideen, die beide gleich gut auf die Anwenderbedürfnisse eingehen. Nun äußern die Entwickler bei einer davon Bedenken. Der Designer sollte in der Lage sein, diese Idee ohne Bedauern zu verwerfen. Ideen sind leicht zu haben, kosten wenig und können problemlos aussortiert werden. Code dagegen ist aufwendig, teuer und langlebig.

Designer liefern bestenfalls Ideen, die ein ausgewogenes Kosten-Nutzen-Verhältnis haben. Dabei hilft die frühe Zusammenarbeit mit Entwicklern. Gemeinsam können sie daran arbeiten, Komplexität zu senken und damit die zukünftige Entwicklung zu vereinfachen. Langfristig nützt das auch den Anwendern.

Ideen verteidigen – für den Anwendernutzen

Ein guter Design-Thinking-Prozess erzeugt also eine Halde aus verworfenen Ideen. Aber das heißt nicht, dass ein Designer nicht auch an einer Idee festhalten kann.

Viele Designer sind frustriert, wenn die Entwickler ihre Lösungen nicht umsetzen wollen. Schlimmer noch: Sie haben eine Designspezifikation ausgearbeitet und die Entwickler haben ihre Entwürfe in schlechten Code verwandelt. Der Grund ist wahrscheinlich, dass sie die Bedürfnisse der Nutzer nicht verstanden haben. Da es keine Zusammenarbeit mit einem Designer gab, haben sie vermutlich irgendeine Lösung improvisiert.

Sind Designer wirklich an einer bestimmten Lösung interessiert, gegen die es Widerstand aus den Entwicklerreihen gibt, dann sollten sie zuerst deren Probleme verstehen. Anschließend können sie deren Sicht mit einbeziehen und erläutern, warum diese eine Lösung wichtig ist und alternative Lösungen nicht zufriedenstellend sein können.

Brücken bauen

Es ist hilfreich, die Perspektive der Entwickler in den Designprozess zu integrieren. Doch für Designer wird das nicht einfach. Entwickler stapeln nämlich nicht nur Funktionen übereinander. Sie bauen ein System mit sehr vielen beweglichen Teilen, während sie gleichzeitig versuchen, die Komplexität möglichst niedrig zu halten. Entwicklerteams überwinden Hürden, die Designer oft nicht sehen können. Aber es gibt zwei gute Methoden, um zwischen Designern und Entwicklern Brücken zu bauen: Co-Creation und Design-Reviews.

Co-Creation – gemeinsam am Design arbeiten

Der beste Weg für möglichst frühzeitige Rückmeldungen aus dem Entwicklerteam ist die Zusammenarbeit beim Entwurf des Designs. Normalerweise entwerfen Entwickler Lösungen, indem sie über technische Möglichkeiten nachdenken. Diese Ingenieur-Denke hat zwei Vorteile: Erstens führt es Design Thinking in die Richtung solider Machbarkeit und zweitens führt es Design Thinking zu (für den technischen Laien) unvorstellbaren Ideen.

Wie Sie die Methode einsetzen: Setzen Sie sich für eine Stunde mit einem oder zwei Entwicklern zusammen vor ein Whiteboard. Beginnen Sie das Meeting mit einer informellen Diskussion ihrer Gedanken zum Anwenderproblem, das sie zu lösen versuchen. Diskutieren Sie auch über Dinge wie die kritischen Punkte der Lösung.

Zeigen Sie anschließend den Weg des Produkts in die reale Welt, zum Beispiel durch Benutzerszenarien. Wichtig ist, zunächst das Problem, den Bedarf oder den Anwenderwunsch zu nennen und anschließend zur Lösung überzugehen. Die „Bildschirme“, die sie dabei zusammen mit den Entwicklern skizzieren, überbrücken diese beiden Punkte. Dabei funktionieren weniger formale Prozesse genauso wie die etablierten Design-Thinking-Praktiken.

Für nicht persönlich Anwesende hat sich der Einsatz von Video-Chats bewährt. Jeder kann seine Ideen auf Papier zeichnen und anschließend seine Ergebnisse vor die Kamera halten und zur Diskussion anbieten.

Wann Sie die Methode einsetzen: Der beste Zeitpunkt für Co-Creation ist die frühe Phase eines Projektes. Dort können Designer die großen Probleme angehen und eine Beziehung zu den Entwicklern aufbauen. Das funktioniert nicht mehr so gut, wenn die Entwickler bereits mit Schreiben von produktivem Code beschäftigt sind. In diesem Fall haben sie das Hauptziel, eine robuste Lösung zu entwickeln – alles andere wird als Ablenkung betrachtet.

Tipp: Es kommt recht häufig vor, dass Entwickler nicht gerne an einem Whiteboard zeichnen. Doch es gibt einen einfachen Trick: Zeichnen Sie ein User Interface und machen Sie dabei einen kleinen Fehler. Sobald der Entwickler Sie darauf hinweist, fragen Sie nach einer Lösung und geben ihm einen Stift. Das funktioniert überraschend gut.

Design-Review – Probleme frühzeitig zurückmelden

Eigentlich sollten Designer möglichst häufig mit Entwicklern zusammenarbeiten. Doch in der Realität klappt das oft nicht. Design-Reviews sind eine Technik, mit der frühes Feedback von den Entwicklern institutionalisiert werden kann. Dabei wird das Backlog ebenfalls berücksichtigt.

Wie Sie die Methode einsetzen: Bringen Sie das ganze Team regelmäßig für 30 Minuten an einen Tisch, etwa einmal pro Woche oder alle zwei Wochen. Lassen Sie dann die Designer präsentieren, woran sie gerade arbeiten: Skizzen, User-Flows, Wireframes, UI-Komponenten usw. Dann fordern Sie das Entwicklerteam auf, ihre Überlegungen und Bedenken zu nennen. Geben Sie kurze Hinweise zum Thema Komplexität, damit sie eine Diskussion über das Verhältnis von Nutzwert und Kosten frühzeitig in Gang bringen können. Äußern die Entwickler Kritik, fragen Sie zurück: „Was stört Sie daran?“ oder „Wie können wir das besser angehen?“.

Sie sollten die Design-Review möglichst am Ende des Tages einplanen, um den Arbeitsablauf der Entwickler nicht zu unterbrechen. Denken Sie auch daran, die Entwickler zu bitten, über die Zukunft des Produkts nachzudenken. Deshalb sollten Sie sich etwas Zeit nehmen und sich auf die Präsentation vorbereiten.

Wann Sie die Methode einsetzen: Benutzen Sie Design-Reviews in der heißen Phase der Entwicklung, wenn alle Entwickler damit beschäftigt sind, robuste Lösungen zu coden. Die Methode ist darauf ausgelegt, diese Situation zu respektieren. Sie kann auch dazu verhelfen, dass die Sprint-Planung und die entsprechenden Meetings reibungsloser ablaufen, weil jeder mit den vorgestellten Lösungen vertraut ist und die größten Schwierigkeiten bereits behoben sind.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -