Jeff Gothelf, Josh Seiden: Lean UX

You are currently viewing Jeff Gothelf, Josh Seiden: Lean UX

Jeff Gothelf, Josh Seiden
Übersetzung: Maren Feilen, Knut Lorenzen
Lean UX: Produktentwicklung und -design mit agilen Teams

2. Auflage
2020, 266 Seiten, Broschur
mitp-Verlag
ISBN: 978-3-95845-628-0

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Jeff Gothelf und Josh Seiden stellen in ihrem Buch Lean UX die gleichnamige Methode vor, welche, wie es der Name vermuten lässt, eine Übertragung von agilen und lean Ideen auf das Gebiet des User Experience Designs darstellt.


Struktur

Das Buch Lean UX von Jeff Gothelf und Josh Seiden ist dreigeteilt: Im ersten Teil werden die Grundlagen und die Prinzipien der von den Autoren entwickelten Lean-UX-Methode vorgestellt und im zweiten Teil wird die Methode selber präsentiert, die auf vier sich zyklisch wiederholende Schritte begründet ist. Im letzten Teil wird gezeigt, wie Lean UX konkret im Unternehmen eingesetzt werden kann. Anmerkung zur Schreibweise von „Lean UX“: Bei kursiv geschriebenem „Lean UX“ geht es um den Buchtitel, bei normaler Schriftlage, ist die Methode gemeint.

Inhalt

Teil 1: Einführung und Grundlagen

Im ersten Teil des Buches geht es um die „Grundpfeiler“ des Lean UX, bzw. um das, was Lean UX ausmacht und um dessen Prinzipien. Die Grundpfeiler sind: User Experience Design (UX) und Design Thinking, agile Softwareentwicklung und die von Eric Ries begründete Lean-Startup-Methode, die ihrerseits auf die Prinzipien von Lean Manufacturing und Lean Management aufbaut. Wohin das hingeht, ist absehbar: Kurze Iterationen, schnelle Validierung von „Hypothesen“, das agile Prinzip der Berücksichtigung des ganzen Teams etc.

Die Prinzipien von Lean UX sind in drei Kategorien eingeteilt: Solche, welche die Teamorganisation, solche, welche die Unternehmenskultur und solche, welche die Vorgehensweise betreffen.

Schauen wir uns an, wie ein Lean-UX-Arbeitsumfeld aussehen soll:

  • Teams sollen klein (maximal 10 Personen), interdisziplinär besetzt, idealerweise am gleichen Standort arbeitend, selbstorganisiert, mit allen notwendigen Befugnissen ausgestattet und ergebnisorientiert sein.
  • Die Unternehmenskultur soll großen Wert auf Lernen setzen, Annahmen als solche betrachten und vor deren Beweis diese nicht als Gewissheiten ansehen, Misserfolge sollen als Lerngelegenheit aufgefasst, ein gemeinsames Verständnis von den Problemen soll angestrebt, Verschwendung soll minimiert und der Fokus soll auf Ergebnisse statt auf Durchsatz gesetzt werden.
  • Das Vorgehen soll iterativ, transparent, auf kontinuierliches Lernen setzend, ergebnisorientiert, das Agieren dem Analysieren vorziehend, auf enge Zusammenarbeit innerhalb des Teams statt auf Übergaben fokussiert und an engem Kontakt mit Kunden/Nutzern interessiert sein.

Teil 2: Prozess

Der zweite Teil des Buches beschreibt den vierteiligen Lean-UX-Prozess. An dessen Anfang steht das Formulieren von „Hypothesen“, d.h. Annahmen darüber, was am besten beim Kunden/Nutzer ankommen würde und die letztendlich durch dessen Reaktion validiert werden müssen (Schritt 1). Die Hypothese wird dann konzipiert (Schritt 2) und als Minimum Viable Product (MVP) zum Leben gebracht (Schritt 3). Als letzter Schritt kommen selbstverständlich die Validierung der Hypothese und die Rückschlüsse auf deren Richtigkeit. Der Lean-UX-Prozess erinnert stark an den von Lean Startup definierten Build-Measure-Learn-Kreislauf, auf den er auch aufbauen dürfte, aber auch an verwandte Kreisläufe, wie John Boyds OODA-Loop (Observe-Orient-Decide-Act, der Lean-Startup-Kreislauf basiert auf OODA) und an den PDCA-Zyklus (Plan-Do-Check-Act, auch als Deming- oder Shewhart-Zyklus bekannt).

Die vier Kapitel des zweiten Teils gehen auf jeweils einen der vier Schritte des Lean-UX-Prozesses anfangend mit dem Generieren von Hypothesen ein.

Schritt 1 („Ergebnisse, Annahmen, Hypothesen“): Die Autoren definieren vier „Annahmen“, die besondere Wichtigkeit hätten, von denen aus man Hypothesen generieren könne (vgl. S. 61). Diese sind: Die Reaktionen des Marktes und/oder der Kunden auf die eigenen Aktionen/Änderungen, die erstellten Nutzermodelle (Personas), die Ziele der zukünftigen/aktuellen Anwender und als notwendig/sinnvoll angenommene Features. Das restliche dritte Kapitel befasst sich mit dem Aufstellen der Annahmen und dem Generieren von Hypothesen.

Schritt 2 („Designen“): Im zweiten Schritt wird das MVP innerhalb eines kollaborativen Rahmens konzipiert (collaborative design). Es werden hierfür ein informelles und das Charette-Verfahren vorgestellt. Anschließend gehen die Autoren auf Design-Vorlagen (oder Styleguides, oder auch Designsysteme) und auf Möglichkeiten der Kollaboration bei verteilten Teams ein.

Schritt 3 („MVP Erstellen“): Ein MVP soll den Lernprozess unterstützen und zur Validierung einer Hypothese beitragen (vgl. S. 151). Das MVP soll wirklich minimal sein, d.h. eine konkrete Implementierung (also Code) ist in manchen Fällen gar nicht notwendig und in anderen Fällen reicht eine teilweise Implementierung zur Überprüfung der aufgestellten Hypothese. Drei Beispiele für minimale Produkte, die kurz vorgestellt werden, sind: Landing Pages, Feature Fakes und Wizard of Oz.

Schritt 4 („Recherche & Lernen“): Erwartungsgemäß sollen die Kundenreaktionen auf die getätigten Änderungen (also das Überprüfung der neuen Hypothese sozusagen) möglichst kollaborativ und der Lernprozess kontinuierlich stattfinden. Als Teil des vierten Schrittes werden auch ein paar konkrete Techniken präsentiert, wie z.B. das A/B-Testing, bei dem Nutzer mehrere leicht unterschiedliche Konzepte/Realisierungen präsentiert werden, um zu sehen, welches/welche die positiveren Reaktionen hervorrufen.

Teil 3: Lean UX in Ihrem Unternehmen

Im dritten Teil gehen Gothelf und Seiden auf die Art wie Lean UX im Unternehmen eingesetzt und innerhalb eines Scrum-Prozesses ausgeführt werden kann. Konkret geht es unter anderem um das von Desirée Sy und Lynn Miller entwicklete sogenannte Staggered Sprint Modell, um das von Marty Cagan und Jeff Patton entwickelte Dual-Track Agile und um wahrscheinlich notwendige Änderungen im Unternehmen, die der Einsatz von Lean UX nach sich ziehen kann. Den Abschluss des Buches machen vier Fallstudien.

Diskussion

Als ich gleich im ersten Satz des Vorworts (übrigens von Eric Ries geschrieben) las, dass Lean UX „eine völlig neuartige Entwicklungsmethode“ (S. 15, eigene kursive Hervorhebung) sei, war ich skeptisch. Was könne man schon im Jahre 2016 (Publikationsjahr der zweiten englischen Auflage) noch so radikal Neues im Kontext von Lean und Agilität sagen? Das Manifest für Agile Softwareentwicklung war zu diesem Zeitpunkt schon 15 Jahre alt, das darin Kodifizierte um einiges älter (ab 2016 wird übrigens das Agile Manifest auch als „historisches Dokument“ behandelt, das nicht länger unterschrieben werden kann). Und die Lean-Ideen fanden spätestens seit Anfang der 90er Jahre des vorigen Jahrhunderts große Verbreitung. Das waren meine Gedanken, aber ich war neugierig, was kommen würde.

Leider sehe ich nach dem Fertiglesen des Buches meine Skepsis vollkommen bestätigt. Lean UX ist eine Mischung aus UX und Lean Startup mit einem Zusatz von Agilität. Das Ganze wird sinnvoll strukturiert dargestellt (Prinzipien, Vorgehen, Einsatz im Unternehmen), worin jedoch genau der Neuigkeitswert begründet sein soll, ist mir nicht klar. Wer an UX interessiert ist, wird wahrscheinlich in diesem Buch zu wenig darüber finden, um glücklich zu werden. Mit Lean verhält es sich ebenso. Was die Grundzüge und den Prozess von Lean UX ausmachen, hätte meines Erachtens vollkommen ausreichend in einem (vielleicht auch etwas längeren) Artikel beschrieben werden können.

Dabei meinte ich, gute Gründe zu haben, recht viel vom Text zu erwarten. Gothelfs und Seidens Buch ist mittlerweile bei der dritten Auflage angelangt (die dritte ist im Herbst 2021 erschienen), wurde schon in mehreren Sprachen übersetzt und obendrauf wurde die erste Auflage im Jahre 2013 mit dem namhaften Jolt Award ausgezeichnet. Zusätzlich ist Lean UX in einer leicht angepassten Form – wohl auch etwas zu Gothelfs Leidwesen – seit der Version 4.5 Teil des Scaled Agile Frameworks (SAFe). Hm…

Zusätzlich muss ich noch sagen, dass mir zuweilen auch eine etwas kritischere, bzw. differenziertere Position der Autoren zum Geschriebenen fehlt. Betrachten wir zwei von mehreren Beispielen, die mir aufgefallen sind.

Teams sollen klein und interdisziplinär sein, das ist eine altbekannte agile Forderungen. Das interdisziplinäre Team wird bei Gothelf und Seiden relativ weit gefasst: So „[…] sollten die Disziplinen Software Engineering, Produktmanagement, Interaction Design, Visual Design und Content Strategy ebenso vertreten sein wie das Marketing und die Qualitätssicherung […]“ (S. 42 f.). Gleichzeitig aber soll das Team „aus nicht mehr als insgesamt zehn Personen bestehen“ (S. 43), die obendrauf auch nur an einem Projekt arbeiten sollen (ebenfalls auf S. 43 zu findende Forderung). Auch wenn man davon ausgeht, dass etliche Rollen von einer Person eingenommen werden können, arg viel lässt sich mit zehn Personen nicht anstellen, wenn man das Konzept „Team“ so weit fasst. Dadurch, dass die Teammitglieder auch noch Vollzeit dem Team zugewiesen werden sollen, dürften sich weitere Ineffizienzen einstellen.

Das zweite Beispiel: Der Gedanke Softwareentwickler und andere Nicht-Designer in den Design-Prozess einzubinden, der öfters im Buch wiederholt wird (z.B. S. 91 ff.), ist sicherlich interessant und ich will ihm auch nicht die prinzipielle Richtigkeit absprechen. Gute Designideen können ja auch von Nicht-Designern kommen. Das ist, denke ich, unumstritten. Ich würde aber an dieser Stelle gerne den „Spieß“ umdrehen, und fragen, ob ebenfalls Designer und Nicht-Softwareentwickler (z.B. Marketing, Produktentwicklung, technische Dokumentation etc.) beim Design der Software eingebunden werden sollen? Es steckt meines Erachtens eine etwas naive Vorstellung hinter diesem Gedanken, dass alle irgendwie alles zusammen machen sollen, nur weil sie ein Team sind und zusammen könne man eh alles besser, weil … nun ja, weil man zusammen sei. In Einzelfällen kann solch eine Strategie zwar Sinn machen und auch funktionieren, als generelle Forderung, halte ich dies jedoch für nicht effizient und auch nicht für implementierbar. An dieser Stelle hätte ich mir eine differenziertere Betrachtung der Autoren gewünscht.

Alles in allem vermag das Buch nicht zu überzeugen. Vor allem dürfte Lean UX für solche Leser zu wenig bieten, die mit Agilität und Lean und mit Eric Ries‘ Buch Lean Startup: Schnell, risikolos und erfolgreich Unternehmen gründen (mehrere Auflagen im Redline Verlag) schon vertraut sind.


Zu den Autoren

Sowohl Jeff Gothelf als auch Josh Seiden sind bekannte Berater, Autoren und Redner, die wahrscheinlich am ehesten für die Entwicklung der Lean-UX-Methode bekannt sein dürften.

Jeff Gothelf und Josh Seiden haben bisher zwei Bücher in Zusammenarbeit veröffentlicht:

  • 2013. Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly. (Zweite Auflage 2016 mit leicht geändertem Titel: Lean UX: Designing Great Products with Agile Teams, weitere Auflage 2021, beide bei O’Reilly).
    Deutsche Ausgabe: Lean UX: Mit der Lean-Methode zu besserer User Experience. mitp. 2015. (zweite Auflage 2020, ebenfalls mitp, ebenfalls mit leicht geändertem Titel: Lean UX: Produktentwicklung und -design mit agilen Teams)
  • 2017. Sense & Respond: How Successful Organizations Listen to Customers and Create New Products Continuously. Harvard Business Review Press.

Quellen: Die Informationen über die beiden Autoren sind den entsprechenden Selbstpräsentationen auf den eigenen Webseiten entnommen. Angaben zu den Publikationen gemäß den Katalogen der Library of Congress und der Deutschen Nationalbibliothek. Letzter Zugriff: 10.11.2021.


Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Nachdem er sein Bachelorstudium im Fach Psychologie abschloss, orientierte er sich neu und studierte Software Engineering an der Hochschule Heilbronn, ebenfalls mit einem Bachelor abgeschlossen. Anschließend war er knappe sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Aktuell ist er mit dem Masterstudium der Praktischen Informatik und der Rezensionsplattform für IT-Fachbücher nososo.de beschäftigt.

Schreibe einen Kommentar