Design Talks: Bessere Zusammenarbeit zwischen Designern und Entwicklern mit Aaron Walter von InVision

Willkommen zu unserer Design Talks-Reihe, die dem Austausch von Erkenntnissen von Vordenkern und Top-Designern aus der ganzen Welt gewidmet ist. Wir interviewen Experten, die in unterschiedlichen Kontexten, mit unterschiedlichen Zielen und mit unterschiedlichen Ansätzen mit Design arbeiten. Wir hoffen, mit diesen Serien allen unseren Lesern intellektuelle und kreative Inspiration zu bieten.

Designer haben oft Schwierigkeiten, mit Entwicklern zusammenzuarbeiten und umgekehrt. Die Teams auf beiden Seiten könnten enorm viel voneinander lernen, dennoch bleiben Widerstände bestehen. Gast dieser Woche ist Aaron Walter, VP of Design Education bei InVision, und wir werden über die Zusammenarbeit von Designern und Entwicklern sprechen.

Aaron stützt sich auf 15 Jahre Erfahrung in der Leitung von Produktteams und im Unterrichten von Design, um Unternehmen bei der Umsetzung von Best Practices für Design zu unterstützen. Er gründete die UX-Praxis bei MailChimp und trug dazu bei, das Produkt von einigen tausend Benutzern auf mehr als 10 Millionen zu erweitern.

Seine Designberatung hat dem Weißen Haus, dem US-Außenministerium und Dutzenden von großen Unternehmen, Start-ups und Risikokapitalfirmen geholfen. Er ist Autor des Bestsellers Designing for Emotion von A Book Apart. Sie finden @aarron auf Twitter, wo Sie Gedanken zum Thema Design teilen, und Sie können mehr über Aaron unter aarronwalter.com erfahren.

Im Design Better Podcast interviewen die Moderatoren Aaron Walter und Eli Woolery Designführer und Influencer, die Geschichten darüber erzählen, wie sie Probleme lösen und wie sie Karriere machen. Zu den Gästen zählen unter anderem David Kelley (IDEO-Mitbegründer und Stanford d.school-Gründer), Julie Zhuo (Vizepräsidentin für Produkt und Design bei Facebook) und Jake Knapp (Bestsellerautor von Sprint).

Hallo Aaron, es ist mir eine Freude, Sie im Toptal Design Blog zu haben. Kommen Entwickler vom Mars und Designer von der Venus?

Meiner Erfahrung nach haben Designer und Entwickler wahrscheinlich mehr gemeinsam, als ihnen bewusst ist, aber es gibt definitiv einige deutliche Unterschiede in der Art und Weise, wie wir über Dinge denken. Designer denken gerne über Designsysteme nach, und Entwickler denken über modularen Code nach, der einfach zu warten ist. Aber die Art und Weise, wie wir es angehen, kann etwas anders sein.

Entwickler haben Wege gefunden, ihre Arbeit in kleinere Stücke zu zerlegen, und Designer neigen dazu, das Ganze als den „ganzen Kuchen“ zu betrachten und wie wir den ganzen Kuchen essen.

Dies ist ein Punkt, an dem sie anfangen, Köpfe zu stoßen. Ingenieure möchten in der Lage sein, Code in kleinen Schritten auszuliefern und im Rahmen der Agile-Methodik sehr schnell etwas zu machen. Designer neigen dazu, auf ganzheitliche Weise einen großen Schritt nach vorne zu machen – sie wollen ein konsistentes Erlebnis liefern. Das kann ein Streitpunkt für diese beiden Gruppen sein.

Was können Designer tun, um Entwickler ein wenig zu unserer Perspektive zu bringen? Wie bringen Designer den Entwicklern bei, dass es bei jedem kleinen ausgelieferten Feature auch um das Erlebnis geht?

Hier besteht für beide Seiten die Möglichkeit, sich zu beugen. Designer versuchen manchmal, einen Entwickler davon zu überzeugen, dass wir warten und das Ganze bauen und es dann als dieses schöne, vollständige Erlebnis herausbringen müssen.

Aber wenn der Erstellungszyklus zu lang ist, laufen Produkte Gefahr, getötet zu werden. Die Leute beginnen, das Interesse zu verlieren. Sie könnten sagen: „Schafft das tatsächlich einen Mehrwert für das Unternehmen? Wir investieren eine Menge Zeit, Energie und Ressourcen in diese Sache, warum dauert es so lange?“ Designer müssen mehr über den Geschäftszyklus nachdenken.

Wenn Apple ein Telefon verschickt – eine Hardware, die ein Problem hat – könnte es sie möglicherweise Milliarden von Dollar kosten, aber wenn Software verschickt wird und es ein Problem gibt, können wir es einfach patchen, reparieren und erneut versenden. Durch diese Herangehensweise an den Prozess können wir eleganter wieder in den Arbeitszyklus der Entwicklung einsteigen.

Designer könnten auch versuchen, die Kluft zwischen den beiden Gruppen zu überbrücken, indem sie Ingenieure frühzeitig in den Designprozess einbeziehen, damit sie sich in der frühen Ideenfindungsphase einbezogen fühlen und nicht nur nachgelagert. Designer sagen vielleicht: „Wir hatten diese brillante Idee, machen Sie sie für uns!“ und das gibt den Entwicklern das Gefühl, dass sie nicht Teil des Ideenfindungsprozesses sind. Sie sind nur die Hände und jemand anderes ist das Gehirn.

Die dysfunktionalste Beziehung zwischen Designern und Entwicklern entsteht, wenn es eine ausgeprägte Arbeitsteilung gibt. Je mehr sich zusammenfügt und diese Teams zusammenarbeiten, desto besser. Infolgedessen gäbe es mehrere Perspektiven und gemeinsame Verantwortung, was wirklich der Schlüssel für eine effektive Zusammenarbeit von Designern und Entwicklern ist.

Über das bessere Verständnis des Raums des anderen…

Was können Teams tun, um den Raum des anderen besser zu verstehen? Sollen sich Designer in die Entwicklung einarbeiten und umgekehrt?

Erstens könnten Designer und Entwickler mehr mit Kunden sprechen und sich gemeinsam über den Problembereich informieren . Sie konnten sich morgens beim Kaffee mit drei bis vier Kunden unterhalten; alle konnten sehr schnell lernen und zu einem gemeinsamen Verständnis der Anliegen gelangen.

Zweitens ist es im Hinblick auf den Arbeitsprozess wichtig, dass Designer und Entwickler – vielleicht nicht fließend – aber ein gewisses Verständnis für die Sprache des anderen haben. Ich meine nicht, dass ein Designer wissen muss, wie man programmiert, oder dass Entwickler Typografie beherrschen müssen, aber zumindest gibt es ein gemeinsames Verständnis.

Wenn Designer Dinge in einer Sprache formulieren könnten, die Entwickler verstehen – „das und das funktioniert nicht und das ist schlecht fürs Geschäft“ –, dann würden Entwickler das Problem schnell verstehen. Das ist für Designer nicht selbstverständlich, aber sie müssen besser darin sein, den Wert ihrer Arbeit quantitativ und nicht nur qualitativ zu kommunizieren. Das Vertriebsteam, das Marketingteam, die Technik, das Produkt, die Führungskräfte, all diese Leute sprechen in Zahlen, sie sprechen quantitativ .

Trotzdem glaube ich, dass Design etwas sehr Wertvolles bringt, dass es Dinge gibt, die zählen, die nicht gezählt werden können. Das Kundenerlebnis, die Freude, die Liebe zum Produkt ist superwertig, und das ist schwer zu quantifizieren.

Es kann jedoch quantifizierbar sein, dass Qualitätskomponenten auf der ganzen Linie einen quantifizierbaren ROI bringen.

Ja, wir können die Kundensupportkosten mit Design reduzieren, wir können die Abwanderung reduzieren, wir können die Onboarding-Geschwindigkeit erhöhen. Wenn Sie solche Metriken im Auge haben, hilft dies dem Design, seine Bemühungen an den Geschäftszielen auszurichten. Je mehr Designer das können, desto besser werden sie verstanden. Je mehr Design im Unternehmen als Wettbewerbsvorteil geschätzt wird, desto größer wird das Potenzial für höhere Investitionen.

Über die Fallstricke der Zusammenarbeit zwischen Designern und Entwicklern…

Was sind einige der größten Fallstricke, auf die Designer und Entwickler bei der Zusammenarbeit stoßen?

Einer der größten Fallstricke ist, keine gemeinsame Sprache zu haben, keine gemeinsamen Ziele zu haben und die Verhältnisse sehr unverhältnismäßig zu sein. Manchmal gibt es funktionsübergreifende Teams mit einem Designer und 75 Ingenieuren. Das klingt verrückt, ist aber ziemlich verbreitet.

Die überwiegende Mehrheit dieser Situationen ist nicht gut. Dieser einsame Designer ist ein Expatriate. Sie sind Fremde in einem fremden Land, wo sie nie ganz in die Kultur passen … und ihr Wertesystem ist anders als das Wertesystem all ihrer Kollegen.

In diesem Umfeld ist es für einen Designer äußerst schwierig, Argumente für eine UX-Funktion zu finden: „Wir sollten diese Animation im Produkt haben, weil sie ein überzeugenderes Erlebnis schaffen wird …“, wenn 75 Ingenieure sagen: „Das sind 250 mehr Codezeilen und zwei zusätzliche Arbeitstage. Lohnt es sich wirklich?” Und das ist es wahrscheinlich nicht. Für sie wird es wie „Zuckerguss“ erscheinen. Aber diese animierten Mikrointeraktionen für einen UX-Designer prägen wirklich das Kundenerlebnis. Sie sind nicht das Einzige, aber sie sind wichtig.

Wenn Sie diese ungleichen Verhältnisse zwischen Designern und Entwicklern haben, wird es wirklich problematisch. Es gibt jedoch Lösungen. Unternehmen wie Slack lösen dieses Problem mit „Paired Design“. Wenn es in einem Team einen Designer auf 10 Ingenieure und in einem anderen Team das gleiche Verhältnis gibt, verbringen diese Einzeldesigner etwa acht Stunden pro Woche damit, zusammenzuarbeiten und sich gegenseitig Lösungen vorzustellen: „So löse ich dieses Problem, macht das für dich sinnvoll? Gibt es einen besseren Weg, dies zu tun?“ Sie können sich gegenseitig helfen, sich zu lösen, und fühlen sich nicht wie auf einer Insel.

Über Designer, die die Bedeutung von UX vermitteln…

Wie können Designer die Bedeutung von Human-Centered Design gegenüber Entwicklern betonen, die HCD nicht wirklich verstehen? Wie vermitteln Designer beispielsweise, dass das Hinzufügen von Funktionen nicht unbedingt dem Kunden dient, dass die Erfahrung bei der Verwendung des Produkts wichtiger ist als seine Funktionen?

Es gibt ein paar effektive Möglichkeiten, dies zu tun. Die meisten Designer haben dies wahrscheinlich auf ineffektive Weise getan, indem sie den Entwicklern direkt gesagt haben: „Hey, das Hinzufügen weiterer Funktionen macht das Erlebnis nicht besser. Die Leute sagen, sie wollen es, aber es macht das Produkt eigentlich nur komplizierter“, und die Entwickler werden wahrscheinlich antworten: „Ich glaube nicht, dass Sie recht haben, das ist eine Meinung. Das hören wir von unseren Kunden, also sollten wir ihnen folgen.“

Am besten nicht frontal anpacken, sondern seitlich anpacken und sagen: „Lasst uns gemeinsam den Problemraum besser verstehen.“ Ich habe für morgen Mittagessen für uns gekauft und ich habe arrangiert, Ihnen fünf unserer Kunden zu zeigen, die unser Produkt verwenden.

Ich habe gesehen, wie sich Ingenieure auf ihren Sitzen winden, wenn sie einem Kunden dabei zusehen, wie er das Produkt tatsächlich verwendet, und feststellen: „Wir haben etwas entwickelt, das ziemlich schwierig zu bedienen ist, und die Leute sind davon frustriert.“ Ingenieure wollen großartige Arbeit leisten, genau wie Designer. Oft haben sie einfach nicht die Möglichkeit, das Ergebnis ihrer Arbeit zu sehen.

Sie haben wahrscheinlich von Jeff Gothelf gehört, der predigte, dass wir uns auf „Ergebnisse, nicht Ergebnisse“ konzentrieren sollten. Das ist eine weitere Art, wie wir unser Denken umgestalten können, dass ein Ergebnis lautet: „Wir haben fünf weitere Funktionen ausgeliefert“ im Vergleich zu einem Ergebnis: „Wir haben die Abwanderung um 10 % reduziert.“

Über die Zukunft der Zusammenarbeit von Designern und Entwicklern…

Sie sprechen mit vielen Unternehmen und sehen viele Design- und Entwicklerteams zusammenarbeiten. Die Tools, Umgebungen und Methoden ändern sich. Was hält die Zukunft für die Designer/Entwickler-Beziehung bereit?

Es entsteht Brackwasser – wenn sich Salz- und Süßwasser vermischen – verschmelzen Ingenieur- und Designwerkzeuge. Anstelle eines Prozesses, der sich wie eine Übergabe anfühlt, bei der alles, was Design ist, hier und alles, was Technik ist, dort drüben ist, fangen sie an, miteinander zu verschmelzen.

Insofern sehen wir Designer, die viel Zeit in Jira verbringen, in User Stories denken und beginnen, auch mit einer technischen Denkweise zu denken. Und umgekehrt sehen wir Ingenieure, die Tools wie InVision Inspect verwenden, wo sie Spezifikationen und den Zusammenbruch eines Designsystems sehen und die Komponenten verstehen, wie alles zusammenpasst. Durch diese Tools und eine Vermischung der Disziplinen entwickelt sich ein gemeinsames Verständnis.

Ob Entwickler oder Designer, Sie können beginnen, die Perspektive Ihres wichtigsten Partners zu verstehen. Das bedeutet nicht, dass Sie als Designer ein erfahrener Programmierer sein müssen. Aber es wird einen Designer nicht umbringen, wenn er ein wenig darüber Bescheid weiß, wie man Git verwendet und wie man HTML und CSS schreibt, vielleicht ein bisschen JavaScript. Das wird Designern helfen zu verstehen, wie Dinge aufgebaut sind, und eine bessere Zusammenarbeit zwischen Designern und Entwicklern fördern.

Weiterführende Literatur im Toptal Design Blog:

• Wie man Design für Entwickler angeht
• Design Talks: Forschung in Aktion mit UX-Forscherin Caitria O'Neill
• Design Talks: Emotional intelligentes Design mit Pamela Pavliscak
• Design Talks: Das Streben nach wertbasiertem Design mit Nick Disabato
• So wechseln Sie vom UX-Designer zum UX-Berater