Lean UX – das Standardwerk – Newsletter 2/2020

Welches Unternehmen ist heute nicht agil? Und welche von denen, die mit „nein“ antworten, wollen es nicht gern sein? So ein schönes Modewort. An nächster Stelle in der Beliebtheit steht vermutlich „lean“. Lean, also schlank, das wollen wir alle sein. Unsere Arbeitsprozesse sollen es auf jeden Fall sein.

Für die User Experience beschreibt den Weg zur Schlankheit der US-Konzepter Jeff Gothelf zusammen mit Josh Seiden im Klassiker „Lean UX“. Das Buch ist zu Recht ein Bestseller in der Branche. Denn „Lean UX“ klingt nicht nur gut, es ist auch ein Weg dazu, UX auch in Unternehmen zu bringen, die bisher noch nicht besonders nutzerzentriert arbeiten. Das können große Konzerne sein, aber auch Mittelständler, die sich mit neuen Arbeitsweisen manchmal auch schwertun.

Wenn Sie bei den Modeworten „agil“ und „lean“ abwinken, dann ist das Buch vielleicht gerade das Richtige für Sie. Denn anders als bei vielen Beratern und bei unzähligen Artikeln steckt in dem Buch viel mehr als nur schöne Worte. Es erklärt, wie man tatsächlich agil arbeitet und dabei den Nutzer in den Mittelpunkt stellt. Nicht die Manager, nicht die Entwickler und nicht die Designer.

Das Problem mit UX und agiler Entwicklung

Die Autoren beginnen mit der Analyse, warum sich agil und UX immer noch oft schwer vereinbaren lassen:

Das Problem liegt in der Art und Weise, wie wir Firmen strukturieren. Wir schaffen noch immer lineare Organisationsstrukturen, obwohl wir in einer Welt leben, die ständige Anpassung erfordert. Wir bauen noch immer Silos in einer Welt, die echte Zusammenarbeit erfordert. Wir investieren noch immer in Analysen, streiten uns über Spezifikationen und produzieren Dokumente in einer Welt, die ständiges Ausprobieren erfordert, um innovativ zu bleiben.

Aber die Autoren bleiben nicht stehen bei ihrer Diagnose. Sehr praxisorientiert erklären sie, wie die Arbeitsschritte aussehen, um (Lean) UX in die Teams zu bringen. Anhand vieler echter Beispiele berichten sie, welche Widerstände und Probleme es gibt und wie man mit diesen umgeht.

Die Grundpfeiler von Lean UX

Als einen Grundpfeiler des Lean-UX-Ansatzes bezeichnen die Autoren „Lean Startup“. Das ist der Ansatz, mit schlanken Prozessen, Iterationen und der Einbindung von Nutzern/Kunden schnell neue Produktideen zu entwickeln und zu testen.

Daneben gibt es zwei weitere Grundpfeiler:

  1. Design Thinking
  2. Agile Entwicklung

Design Thinking ist eine Methode, mit Hilfe von gemeinsamer Arbeit an Problemen und Lösungsideen im Team schnell zu neuen Ideen zu kommen. Zentral ist dabei der Bau von Protoypen und das Testen mit Nutzern. Mehr dazu siehe Design Thinking – bessere Ideen mit visuellem Denken – Newsletter 9/2017 .
Zu agiler Entwicklung muss man wohl nicht mehr viel sagen. Weshalb es für Lean UX so wichtig ist? Weil auch hier in Iterationen gearbeitet wird, also in Zyklen, bei denen immer wieder getestet wird und daraus Erkenntnisse für die weitere Arbeit gewonnen werden.

Gothelf und Seiden sagen: Mit Lean UX lösen Sie die Probleme von der Integration von UX und agiler Entwicklung.

Und die beiden haben Recht. Das heißt nicht, dass es einfach wird. Aber in dem Buch steht genau, wie es gehen kann und wie jeder es schaffen kann. Die Tatsache, dass noch immer so viel über dieses Problem gesprochen und geschrieben wird, zeigt, dass noch zu wenige das Buch gelesen haben.

Was die Autoren auch betonen:

UX in jeder Form braucht guten Input von Nutzern. Lean UX legt großen Wert auf laufendes Feedback, das die Richtung für den Design-Prozess vorgibt.

Das erscheint mir zentral, weil es immer noch Firmen gibt, die wollen „UX machen“ und machen aber kaum Nutzertests oder anderen UX-Research.

Praktisch anwendbares Prozessmodell für Lean UX

Der Prozess nach Gothelf sieht so aus:

Der Lean-UX-Prozess nach Gothelf
Wir starten mit Erkenntnissen, Annahmen, Hypothesen. Dann geht es an die Konzeption. Es folgt das MVP (minimal viable product) und schließlich heißt es testen & Feedback einsammeln.

Am Anfang stehen also nicht „Requirements“, also Anforderungen an ein Produkt. Am Anfang stehen Erkenntnisse aus der Nutzerforschung, Fragen, Annahmen und Hypothesen. All diese untersuchen wir dann im folgenden Prozess. Um mit den daraus gewonnenen Erkenntnissen wieder in die nächste Runde zu gehen.

Vorlage Problem-Statement nach Gothelf
Vorlage für die Problembeschreibung nach Gothelf und Seiden

Sehr sinnvoll erscheint mir auch die Vorlage für die Problembeschreibung für bereits bestehende Produkte oder Dienste:

[Unser Produkt/Dienst] soll [diese Ziele] erreichen.
Wir haben festgestellt, dass es [diese Ziele] nicht erreicht, was für unser Geschäft [diese negativen Effekte] hat.
Wie können wir [unser Produkt/unseren Dienst] so verbessern, dass unsere Kunden erfolgreicher sind, gemessen an [folgenden Kriterien]?

Das ist an sich super simpel, aber nach meiner Erfahrung gibt es so eine klare Definition in kaum einem Projekt. Es heißt immer nur „wir wollen unser Produkt besser machen“, wir „müssen uns um die UX kümmern“ oder „die Nutzer kommen nicht zurecht“. Das ist ein Ausgangspunkt, und von da aus geht es weiter.

Design Studio, Zusammenarbeit, MVP

Als zentrale Methode von Lean UX erklärt Gothelf die Methode Design Studio (siehe auch Design Studio Workshop – neue Konzepte entwickeln). Er gibt Tipps zur Zusammenarbeit im Team, auch wenn die Mitglieder über viele Orte verteilt sind (remote collaboration).

Sehr schön finde ich auch den Ansatz zum MVP, dem minimal viable product (also der Minimal-Version, die sich praktisch nutzen und/oder verkaufen lässt). Die Autoren sagen, das MVP sei dazu da, Fragen zu beantworten. Es beantwortet immer die Frage, ob die Nutzer eine bestimmte Funktion gut finden. Ob sie sie verstehen, ob sie bereit sind, dafür zu zahlen.

Sie bringen ein schönes Beispiel: Ein Unternehmen überlegt, einen Newsletter zu starten. Wer das selbst schon einmal gemacht hat, weiß: Wenn man das richtig machen will, dauert es Monate. Neben Idee und Konzept braucht man Anmeldung, Werbung, gute Inhalte, einen Redaktionsplan und vor allem Menschen, die die Inhalte erstellen. Für ein MVP und die Entwicklung eines Prototypen scheint sich ein Newsletter kaum anzubieten. Was hat das Team gemacht?

Es hat einfach ein Newsletter-Anmeldeformular gestaltet und auf die Website gestellt. Mehr nicht. Man hat also mit minimalem Aufwand gesehen, wie viele Leute sich überhaupt anmelden. (Voraussetzung ist natürlich eine Website mit ausreichend Besuchern, um hier relevante Erkenntnisse zu gewinnen.)

Dieses MVP hat also die erste, wichtigste Frage beantwortet: Lohnt sich der Aufwand überhaupt, einen Newsletter anzubieten? Und ich würde sagen, es erfüllt auch die Kriterien eines MVP: Es hat schon funktioniert, die Anmeldungen für den Newsletter kann man ja in der Tat nutzen, um den Interessenten Infos zu schicken.

UX in der Organisation verankern

Ausführlich erklären die Autoren auch, wie die praktische Zusammenarbeit von Entwicklern und UX aussehen soll. Das Prinzip Dual Track Agile ist Vielen bekannt, aber in vielen Unternehmen werden die Teams aufgeteilt: Der eine Teil ist für „Discovery“ zuständig, also für die Nutzerforschung. Der andere für „Delivery“, also die Entwicklung/Programmierung. Die Autoren plädieren aber stark dafür, so viele Entwickler wie möglich auch bei der Discovery mitmachen zu lassen, vor allem in frühen Projektphasen. Nur so entwickeln sie auch ein Gefühl dafür, wie die Nutzer ticken und wie man mit ihnen arbeitet, um ein besseres Produkt zu entwickeln.

Gothelf gibt den Teams mit:

Damit Lean UX in agilen Projekten funktioniert, muss das ganze Team bei allen Aktivitäten dabei sein – bei Retrospektiven, IPMs, Brainstorming Sessions. […] Selbst wenn 90 Prozent eines Meetings für dich nicht relevant sind – die 10 Prozent, die relevant sind, sparen dir Stunden an Zeit, die du sonst damit verbringst, zu erklären, was besprochen wurde und warum bestimmte Entscheidungen getroffen wurden.

Wer sollte das Buch lesen?

Für wen ist das Buch also Pflichtlektüre? Aus meiner Sicht für alle, die UX und Agile Entwicklung zusammenbringen wollen.

Und vor allem für Manager und Produktverantwortliche/Product Owner. Ich fürchte aber, die meisten von denen werden es leider nicht lesen.

Und schließlich ist die nahe liegende Zielgruppe natürlich UX Designer wie auch Entwickler, die eine bessere Arbeit machen wollen.

Also, ran ans Buch – es liest sich leicht, spart einem die Lektüre unzähliger Blogbeiträge und hat in der gedruckten Ausgabe nur 181 Seiten (bei Amazon ansehen). Wer es auf Deutsch lesen will, Ende Februar erscheint die 2. Auflage bei mitp.

Cover Buch Lean UX

Schreibe einen Kommentar