Dieser Artikel wurde in Deutschland zuerst im Entwickler Magazin Vol. 29 veröffentlicht (September 2021)
Die Arbeit in interdisziplinären Teams erzielt in der Produktentwicklung bessere Ergebnisse für Kund:innen. Allerdings ist es nicht immer offensichtlich, wie die Zusammenarbeit genau aussieht. Welche Praktiken sind für den Erfolg des Teams erforderlich? Welche Werte sollte das Team verkörpern?
Die folgenden Vorschläge lassen sich gut in einem Remote Team in die Praxis umsetzen – auch unter hohem Druck, falls es innerhalb der Kundenorganisation keine Designkapazitäten gibt. Trotz enger Zeitvorgaben lässt sich ein Weg finden, Erkenntnisse zu sammeln und zu experimentieren.
Der Artikel zeigt konkrete Beispiele, wie die interdisziplinäre Zusammenarbeit aussieht. Gleichzeitig sollen einige der Werte und Prinzipien vermittelt werden, die das Team motivieren. Auf diese Weise kann Design im Geschäftsprozess einen größeren Mehrwert liefern. Die Tipps eignen sich für:
- Designer:innen, die definieren wollen, wie Agilität im Design aussieht – von der Strategie bis zur Umsetzung
- Produktmanager:innen, die den Unterschied zwischen ihrer Rolle und der eines/einer Designer:in definieren wollen
- Mitglieder des Delivery Teams (Entwickler:in/ Qualitätsanalyst:in/Projektmanager:in etc.) die sich fragen: „Was ist überhaupt Design? Warum oder wie sollte ich mich am Designprozess beteiligen?”
- Team Leads, die versuchen herauszufinden, wie man die richtigen Dinge aufbaut
- alle, die nach konkreten Beispielen suchen, wie sich Silos in der Produktentwicklung aufbrechen lassen, sodass das Team schnell neue Funktionen für die Benutzer:innen bereitstellen kann.
Der getrennte Workflow
Organisatorische Trägheit ist schwer zu überwinden. Silos zwischen Design, Geschäft und Technologie führen zu langen Feedbackschleifen zwischen Erkenntnissen und Delivery. Ohne eine Kultur der interdisziplinären Zusammenarbeit ist es schwer, mit dem Tempo von Veränderungen mitzuhalten.
Es gibt viele Methoden zur Einführung von personenbezogenen Ansätzen, wie z.B. Lean UX, Agile Experience Design, Balanced Teams, personenbezogenes Design, DesignOps und Design Thinking. Diese Strategien stellen den Menschen in den Mittelpunkt und unterstreichen auch die Bedeutung von Ergebnissen gegenüber dem Output als wichtigstes Erfolgsmaß. Interdisziplinäre Zusammenarbeit ist der entscheidende Treiber, um diese Ergebnisse zu erzielen.
All diese Methoden durchzugehen kann überfordern. Ohne entsprechende Modelle, mit denen sich diese Strategien in Taktiken übertragen lassen, stellt sich womöglich die Frage, ob das Team der richtigen Methode folgt.
Vielleicht sieht die derzeitige Designpraxis in etwa so aus:
Die Prozesse sehen so aus:
- Produktmanager:innen erfassen von den Fachexpert:innen aus dem Geschäftsbereich eine Liste von Anforderungen, die sie an die Designer:innen weitergeben.
- Designer:innen entwerfen unabhängig und ohne Feedback von realen Benutzer:innen High-Fidelity-Mockups. Sie laden die Mockups in Story Cards hoch und greifen diese Mockups nicht wieder auf.
- Entwickler:innen nutzen die Mockups als pixelgenaue Spezifikationen – hier wird es schwierig, die richtigen Fragen zu stellen, ohne das zugrundeliegende Interaktionsdesign zu verstehen und zu wissen, wie diese Arbeit in die User-Journey passt.
- Qualitätsanalytiker:innen testen das Verhalten der Anwendung, ohne die beabsichtigten Ergebnisse zu verstehen, z.B. wie diese Funktionen die Probleme von Benutzer:innen lösen und die geschäftlichen Anforderungen unterstützen sollen.
- Niemand misst, ob das bereitgestellte Produkt den Benutzer:innen tatsächlich einen Mehrwert liefert.
In dem oben beschriebenen Szenario interagieren diese Rollen nur in sehr minimalem Umfang miteinander und oftmals sind sie nicht im gleichen Team. Sie könnten allerdings zu dem Schluss kommen, dass sie in einer kollaborativen Umgebung arbeiten. Und das ist nicht ganz falsch, denn das Endergebnis resultiert aus einer Kombination von Bemühungen. Aber das entspricht nicht dem, wie Zusammenarbeit im interdisziplinären Team aussehen sollte. Dieser getrennte Workflow ist auf Übergaben ausgerichtet. Übergaben sind jedoch das Gegenteil von Zusammenarbeit.
Die Beziehung zwischen Innovation und Empathie
Die Entwicklung benutzerorientierter Produkte beginnt damit, dass die Teammitglieder Empathie gegenüber den Kund:innen und zueinander aufbauen und sich schnell an das anpassen, was sie über die Bedürfnisse der Kund:innen und ihre eigenen Bedürfnisse herausfinden. Das Modell der „Drei Linsen der Innovation“ stellt diese Sichtweise dar:
- Welche Bedürfnisse versucht das Team zu erfüllen? (Ist unsere Lösung wertig?)
- Wie können wir Projekte umsetzen? (Ist unsere Lösung machbar?)
- Können wir unser Momentum aufrechterhalten? (Ist unsere Lösung rentabel?)
Wir betrachten unsere Forschung und Erkenntnisse durch alle drei Linsen – immer mit einem empathischen Blick. Wir benötigen Empathie für Benutzer:innen, um ein Verständnis für den Wert und die Machbarkeit zu erlangen. Wir nutzen Empathie, um Vertrauen ineinander aufzubauen und besser zusammenzuarbeiten. Indem wir einander vertrauen, versuchen wir zu verstehen, wie machbar unser Produkt ist, um auf dem Markt wertvoll und rentabel zu sein. All dies zeichnet Designarbeit aus. Wir alle können viel von unseren Benutzer:innen und voneinander lernen, deshalb glauben wir an die Design-as-a-Team-Methodik.
Die „Drei Linsen der Innovation“
Die „Drei Linsen der Innovation“: Unser Ziel ist es, etwas zu schaffen, das wertvoll (wünschenswert), machbar und rentabel ist. Das erreichen wir, indem wir Empathie und Vertrauen in unserem Team und in den Communities fördern.
In unserem Ansatz ist Design eine gemeinsame Verantwortlichkeit. Das bedeutet, wir schaffen ein gemeinsames Verständnis der User Journey und arbeiten Hand in Hand zusammen, um die verschiedenen Fähigkeiten und Perspektiven, die jedes Teammitglied mitbringt, zu nutzen. Das Ergebnis dieser Arbeit repräsentiert unsere Annahme dessen, was machbar, rentabel und wertvoll ist, und weitere Tests in der Produktion erfordert. Ohne diese Hypothese raten Produktmanager:innen nur, was die Benutzer:innen brauchen, Designer:innen übergeben UI-Spezifikationen ohne Erklärung und Entwickler:innen codieren ohne Gesamtverständnis.
Eine ausgewogene Teamzusammensetzung ist entscheidend für eine effektive interdisziplinäre Zusammenarbeit. Sie setzt Lernmöglichkeiten frei, die das Team sonst nicht in Betracht gezogen hätte. Teams aus Designer:innen und Entwickler:innen ("Pairing") haben die Tendenz, die Dynamik eines auf diese Weise zusammengesetzten Teams voranzutreiben. Hier zeigt sich der Wert aus diesem besonderen Match am deutlichsten. Aber es gibt noch viele weitere Möglichkeiten. Was könnten wir lernen, wenn beispielsweise Qualitätsanalytiker:innen und Designer:innen zusammenarbeiten? Produktmanager:innen und Entwickler:innen? Designer:innen und Techniker:innen vor Ort? Entwickler:innen und Mitarbeiter:innen aus dem Kundensupport?
Wenn Design zur Teampraxis wird, fangen wir an, die Verantwortlichkeiten unserer Rollen zu überdenken und wie unsere Arbeit zu dem beiträgt, was wir über die User Journey wissen.
Der Ansatz: Minimum Viable Practices
Um diese Vision in die Tat umzusetzen, müssen die Verhaltensweisen mit den Werten und Bedürfnissen des Teams in Einklang gebracht werden. Dies lässt sich explizit über Brainstorming erreichen. Zusätzlich kann das Team über Grundsätze abstimmen und eine Team-Charta entwerfen. Auf diese Weise lässt sich regelmäßig prüfen, welche Practices hinzugefügt oder geändert werden müssen, um die Vision zu verwirklichen und aktiv zusammenzuarbeiten.
Neue Gewohnheiten herauszubilden, erfordert bewusste Bemühungen. Daher sollte das Team immer versuchen, eine neue Übung als „Minimum Viable Practice" zu betrachten. Eine Minimum Viable Practice ist das Einfachste, was wir tun können, um den benötigten Lernerfolg zu erzielen. Dies erreicht man mit der kleinstmöglichen Gruppe an Teilnehmern, die erforderlich ist, um das Erlernte abzuleiten. Echtzeit-Feedback und Retrospektiven eignen sich zur Verbesserung der Übungen, um sicherzustellen, dass sie noch Gültigkeit haben. Im schlimmsten Fall gehen 30 Minuten bis eine Stunde Zeit verloren, um etwas auszuprobieren, was sofort wieder verworfen wird. Im besten Fall gewinnt das Team wichtige Erkenntnisse und kann sie beim nächsten Mal umsetzen.
Dank des Einsatzes von Minimum Viable Practices geht keine Zeit für ineffektive neue Practices verloren. Das Team sollte dabei bereit sein, verschiedene Experimente auszuprobieren, da die Aktivitäten zeitlich begrenzt und ergebnisorientiert sind.
Beispiele für funktionsübergreifende Practices
Es existieren zahlreiche Methoden für funktionsübergreifende Zusammenarbeit. Hier sind einige Beispiele für mögliche Team-Szenarien, die Anregungen liefern, wie sich eine Strategie in Taktiken für die Problemlösung umsetzen lässt:
Überprüfung der Design- und Technikschulden
Die meisten Teams sind mit dem Konzept der Technikschulden vertraut, aber nur wenige Teams verfolgen Designschulden. Designschulden repräsentieren Usability-Probleme, die aufzeigen, ob Inhalte wahrnehmbar, bedienbar, verständlich, robust und konsistent sind. Im besten Falle handelt es sich bei diesen Problemen um leicht irritierende Eigenheiten, im schlimmsten Falle hindern sie Benutzer:innen an der Erreichung ihrer Ziele. Die Anhäufung von Designschulden kann das Vertrauen der Benutzer:innen in das System oder – im schlimmsten Fall – in sich selbst untergraben, weil sie nicht herauszufinden, wie sie Probleme überwinden.
Wenn Entwickler:innen aufgrund früherer Erfahrungen bereits recht geübt im Umgang mit Technikschulden sind, ist der Aufwand zur Einführung einer neuen Dimension relativ gering. Entwickler:innen, Qualitätsanalytiker:innen und Designer:innen erfassen dann sowohl Technik- als auch Designschulden unmittelbar. Abhängig von Aufwand und Wirkung werden diese dann in der Gruppe regelmäßig überprüft.
Paarweise Untersuchung von Lösungen
Der Begriff „Pairing“ kann neben dem reinen Programmieren auch auf andere Rollen und Aktivitäten angewendet werden. Ein übliches Pair sind Designer:in und Entwickler:in; die Aktivität hängt davon ab, wer die Untersuchung anleitet.
So entwerfen beispielsweise Designer:innen und Entwickler:innen gemeinsam Designoptionen und prüfen gleichzeitig die technische Machbarkeit. Entwickler:innen und Designer:innen codieren gemeinsam und führen während der Umsetzung eine Validierung durch. Dadurch sind sie in der Lage, spontan Anpassungen zu machen, wenn sie auf Probleme stoßen. Diese Art der Untersuchung verbessert die Empathie der Teammitglieder für Technik- und Designperspektive und fördert die gemeinsame Verantwortung für die User Experience.
Nutze unser Design-as-a-Team Playbook, um die besten Pairing-Techniken für dein Team zu ermitteln.
Messung der Auswirkung
Eine gute Übung ist, die Praktiken kontinuierlich anhand der Werte zu prüfen. So lässt sich entscheiden, wann Praktiken ergänzt, modifiziert oder sogar aufgegeben werden sollten. Woher wissen wir, dass unsere Arbeit unmittelbar zu erfolgreichen Erlebnissen für unsere Benutzer:innen beiträgt?
Wir können die Effektivität bestimmter Praktiken durch Echtzeit-Retrospektiven messen, aber um unsere technischen und sozialen Praktiken ganzheitlicher zu bewerten, müssen wir sie aus dem Blickwinkel der drei Linsen der Innovation betrachten. Der Erfolg des Produkts hängt nicht nur davon ab, wie es sich verkauft und welchen Wert es für das Unternehmen hat, sondern auch vom technischen Zustand, dem Befinden des Teams und der Zufriedenheit der Benutzer:innen. Die Wirkung muss über all diese Variablen hinweg gemessen werden.
Grundsätzlich hängt unsere Fähigkeit, die Wirkung zu messen, von der Teamzusammensetzung und von Conway's Law ab. Es ist unmöglich, die Bestandteile unserer Arbeit von der Art, wie wir arbeiten, zu trennen. Die Linsen der Innovation veranschaulichen dieses Prinzip sehr gut: Für ein effektives Design as a Team müssen wir die bestehenden Kommunikationsmuster innerhalb der Organisation neu entwickeln und die soziotechnischen Dysfunktionen angehen, die ein schnelleres Feedback verhindern.
Fazit
Eine Strategie ohne Taktiken ist Wunschdenken, und Taktiken ohne Strategie sind kurzsichtig. Die Konzentration auf Praktiken hilft zunächst, die Methoden für funktionsübergreifende Teams flüssig zu beherrschen.
Beim Design as a Team geht es darum, Reibungen zu verringern und Trägheit zu überwinden. Dies ermöglicht das Nachdenken darüber, wie agile Softwareentwicklung über den Bereich der Entwickler:innen hinaus aussieht. Design as a Team ist das Frontend für Continuous Delivery.
Es mag überraschen, dass einige der beschriebenen Aktivitäten als ein Akt des Designs betrachtet werden können. Beim Design geht es um Visionen, Absichten und Handlungen – um die Vorstellung von dem, was möglich ist, und den gemeinsamen Aufbau einer neuen Zukunft. Wenn wir einen personenbezogenen Ansatz verfolgen, beginnen wir, unseren kollektiven Einfluss auf Benutzer:innen, Team und Gemeinschaft als Ganzes genauer zu betrachten. Das ist in Kürze das, was Design as a Team ausmacht. Die Verbindung dieser Praktiken mit den Prinzipien und Werten macht deutlich, warum sie wertvoll sind, und ermöglicht, den Erfolg von einem Team auf das nächste zu übertragen.
Es ist in Ordnung, wenn ein Team nicht dafür bereit ist, all dies auf einmal umzusetzen. Es braucht Zeit zu wachsen, und Veränderungen sind nicht immer einfach. Diese Tipps dienen als Ausgangsbasis. Wenn das Team sich beispielsweise in einer Umgebung befindet, in der Experimente auf Angst und Widerstand stoßen, ist es ratsam, mit kleineren Projekten zu beginnen, die schnell zum Erfolg führen. Die genannten Beispielübungen lassen sich neu mischen und es lassen sich eigene erfinden – basierend auf den Team-Werten und den zu lösenden Problemen. Was am meisten zählt, ist: Dinge ausprobieren, Zuhören und Beobachten, Erkenntnisse gewinnen und kontinuierlich Fortschritte machen.