Lean UX, Nutzer:innen zentrierte Entwicklung im agilen Umfeld.

Lean-UX Ursprung und Intention.

Seit dem Aufkommen agiler Entwicklungsmethoden driften die Prozesse für Programmierung und Interaktionsdesign immer weiter auseinander.

Lean-UX setzt sich aus "Lean" und "UX" zusammen. Während Lean seinen Ursprung in der schlanken Produktion hat, stammt der Begriff "User Experience" aus dem ersten Jahrzehnt der 2000er Jahre und wurde vor allem von Donald Norman eingeführt. Lean-UX hat also einerseits seine Wurzeln im Lean Manufacturing Ansatz, der maßgeblich dazu beigetragen hat, Toyota zu einem der größten Automobilhersteller der Welt zu machen. Durch Eric Ries' Buch "The Lean Startup" wurde der Ansatz in der Startup Community zum Mittel der Wahl, um durch Build-Measure-Learn-Feedback-Iterationen schnell Sicherheit zu gewinnen, welche Ideen sich am Markt etablieren können. Konzepte des Lean Manufacturing sind wiederum integraler Bestandteil agiler Softwareentwicklungsmethoden wie Kanban oder Scrum.
‍
Der Begriff "User Experience" leitet sich vom "User Experience Designprozess"ab, der zwar auch iterativ ist, aber in der Vorbereitungsphase umfangreiche Recherchen und Analysen vorsieht, um dann an Prototypen i.d.R. aufwändige Tests durchzuführen, deren Ergebnisse in die nächste Iteration des Prototyps einfließen, mit dem Ziel, ein möglichst nutzerzentriertes System für die anschließende Implementierungsphase zu beschreiben. Der Prozess ähnelt dem in der DIN EN ISO 9241-210 zur Menschenzentrierten Gestaltung beschriebenen "Human Centered Design Process".

Pragmatisch, angemessen und zielgerichtet.

Während iterative Prozesse in der Softwareentwicklung darauf abzielen, den Erkenntnisgewinn während der Implementierung zu erhöhen und ein gutes System entlang konkreter Anforderungen zu entwickeln, zielt der UX-Design-Prozess eher darauf ab, ein System im Vorfeld der Entwicklung möglichst gut zu entwerfen. Die Erfahrung hat gezeigt, dass solche Modelle zusammenbrechen, wenn nicht mehr alles im Voraus geplant werden kann, was bei komplexer Software praktisch immer der Fall ist. Der Kern von Lean-UX besteht daher darin, UX-Prozesse in agile Systeme zu integrieren, indem sie in die Verantwortung von funktionsübergreifenden Teams gegeben werden und in noch kürzeren Iterationen während der Entwicklung nach dem Muster "Build-Measure-Learn-Feedback" durchgeführt werden, mit dem Ziel, einerseits so effizient wie möglich zu sein, andererseits aber immer die Sicherheit zu haben, das Richtige zu tun, also pragmatisch, angemessen und zielgerichtet zu handeln.

Besonders für bestehende Systeme, in die oft über viele Jahre hinweg Erkenntnisse - möglicherweise auch aus nutzerzentrierten Entwicklungsprozessen - eingeflossen sind, ist der forschungs- und spezifikationsbasierte Ansatz nicht angemessen und berücksichtigt die bereits gewonnenen Erkenntnisse zu wenig.

Lean-UX Einführung in den Prozess.

"Ein gemeinsames Verständnis entsteht durch eine enge Zusammenarbeit zwischen [den] Disziplinen. Darin liegt der eigentliche Effizienz- und Produktivitätsgewinn von Lean UX." - Jeff Gothelf

Die Idee von Lean-UX wurde zuerst von Jeff Gothelf und Josh Seiden beschrieben. Ähnlich dem Lean-Ansatz wird ein schneller Prototyp gebaut und dann wird gemessen, ob dieser den erwünschten Nutzen bringt. Daraus wird gelernt und die Erkenntnisse fließen als Feedback in die Entwicklung zurück. So wird sichergestellt, dass in jeder Iteration eine konstruktive Verbesserung stattfindet. Gothhelf und Seiden beschreiben den Lean UX Prozess mit einer Iterationsschleife:

Im Original heißt das Benefit hypothesis, Collaborative design, Build Minimum Marketable Feature (MMF) und Evaluate, aber um besser erklären zu können, was in jedem Schritt passiert, haben wir uns die Freiheit genommen, die Namen der Prozessschritte etwas anzupassen. Im Wesentlichen beschreibt der Prozess einen kontinuierlichen Lernprozess, bei dem darauf geachtet wird, das zu tun, was gerade wichtig ist.

Hypothese: Was verbessert mein System?

Um zu vermeiden, dass etwas gebaut wird, nur weil es möglich ist und nur vielleicht gebraucht wird, beginnt man mit einer Hypothese zu einem Feature. In dieser Phase ist es wichtig, Fragen zu stellen:

• Was wird tatsächlich gebraucht?
• Woher wissen wir das?
• Welche Auswirkung hat das auf die Nutzer:innen und das System?
• Wie finden wir das heraus?
• Wie wichtig ist das gerade?

Im Grunde werden die Fragen gestellt, die gute Product Owner:innen (PO) stellen, die die Priorität und vor allem den Wert eines Features in den Vordergrund stellen. Die Neuerung im letzten Scrum-Guide, die POs als Teil des Teams zu definieren, kommt diesem Umstand daher entgegen. Die Fragen wiederum führen zu einer Hypothese, die zu einer Verbesserung des Systems führt. Wo also bisher einfach die Erledigung einer Aufgabe gefordert wurde, wie z.B. "Baue ein Adressformular", heißt es nun: "Baue ein angemessenes Adressformular". Und "angemessen" heißt hier: "Tut, was nötig ist, um das Formular für den Zweck optimal zu machen, aber tut nicht alles Mögliche, wenn ihr nicht wisst, ob der Nutzen den Aufwand wert ist oder ob es überhaupt gebraucht wird".  Deshalb im Originial auch "Benefit hypothesis", also eine Hypothese, die verspricht, das System für Kund:innen und Anwender:innen besser zu machen.

Die Hypothese beschreibt zunächst eine Vermutung, wie sich eine konkrete Funktion oder ein System entwickeln sollte. Sie beschreibt also noch keine konkreten Lösungsoptionen und ist durchaus mit einer User Story vergleichbar. Hier ein paar Beispiele:

Hypothese

Wir glauben, dass das Hinzufügen einer Social-Sharing-Funktion zu unseren Artikeln die Interaktionsrate der Nutzer erhöhen wird.

Zu testen durch

• Implementieren von Sharing-Buttons in den Artikeln.
• Beobachten der Anzahl der geteilten Artikel und der Nutzerinteraktionen (Kommentare, Likes).
• Vergleich der Interaktionsrate vor und nach der Einführung der Sharing-Funktion.

Hypothese

Wir glauben, dass die Reduzierung der Anzahl der Schritte im Registrierungsprozess die Abbruchrate bei neuen Nutzern verringern wird.

Zu testen durch

• Implementieren eines vereinfachten Registrierungsformulars mit weniger Schritten.
• Durchführen eines A/B-Tests, bei dem die Abbruchraten der aktuellen und der neuen Registrierung verglichen werden.
• Messen der Abbruchrate und der abgeschlossenen Registrierungen.

Hypothesen wie diese sind oft schnell geklärt und das Prozedere läßt sich gut in agile Rituale wie das Backlog Refinement integrieren. Es ist wichtig zu definieren, was zur Überprüfung der Hypothese notwendig ist, denn das bestimmt, welche Artefakte gebaut werden müssen. Also z.B. Prototypen oder bereits funktionsfähige oder teilfunktionsfähige Software. Letzteres macht vor allem dann Sinn, wenn z.B. eine Grundfunktionalität klar ist, die auf jeden Fall abgebildet werden soll. Bei einem Breadcrumb Trail ist die Funktionsweise ziemlich klar. Er kann in einer ersten Iteration implementiert werden, um dann z.B. im bestehenden System getestet zu werden:

• Wie lange werden Breadcrumb-Tarils auf tieferen Ebenen? Müssen wir etwas tun, um diese z.B. abzuschneiden?
• Auf welcher Ebene kommen sie überhaupt zum Einsatz?
• Wieviel Platz nehmen sie im kleinsten Breakpoint ein? Werden sie mobil überhaupt gebraucht?
• Wie verhalten sie sich zum Rest des Systems?
• Wie sollen sie am Ende aussehen?
• Wen müssen wir einbeziehen, um die Hypothese überprüfen zu können?

Evidenz basiertes Design

"Lean UX hat keine Zeit für Helden. Das gesamte Konzept des Designs als Hypothese entthront sofort die Vorstellung von Heldentum; als Designer müssen Sie damit rechnen, dass viele Ihrer Ideen beim Testen scheitern werden. Helden geben kein Scheitern zu. Aber Lean-UX-Designer nehmen es als Teil des Prozesses an." - Jeff Gothelf

Gothelf und Seiden nennen es "Collaborative Design", weil die Zusammenarbeit in interdisziplinären Teams den entscheidenden Unterschied zu bisherigen Vorgehensweisen darstellt, bei denen UX-Spezialisten Designsysteme und Prototypen erstellen, auf die sich die Implementierung weitgehend verlassen muss. Design bedeutet hier vor allem die Beschreibung einer oder mehrerer möglicher Lösungen. Dies kann zu einer Visualisierung führen, kann aber auch beschreibend gelöst werden, wobei in den meisten Fällen eine Visualisierung effizienter ist. In jedem Fall ist es wichtig, in dieser Phase festzulegen, welche Artefakte in der nächsten Phase bereitgestellt werden müssen, um mit Hilfe der Testszenarien Sicherheit bzw. Evidenz darüber zu gewinnen, ob die Hypothese richtig und die Lösungsoptionen adäquat sind. Dafür gibt es mehrere Gründe:

• Es müssen keine detaillierten Spezifikationen erstellt werden, die sich später als lückenhaft oder missverständlich erweisen könnten. Es wird nur das Notwendige dokumentiert.
• Das Team ist früh darüber informiert, was zu tun ist, und das Fachwissen über alle Gewerke ist in die Hypothese eingeflossen.
• Die Implementierung hat eine andere Verantwortung als die Abarbeitung einer Spezifikation. Sie ist mitverantwortlich für die Lösung, was hilft, technische Schulden zu vermeiden, Machbarkeiten auszuloten und auch Chancen zu nutzen, denn technische Lösungen können auch einfacher sein, als POs oder UX Designer:innen vermuten.
• Die Anforderung durchläuft mit der Beteiligung verschiedener Disziplinen bereits eine erste Qualitätssicherungsstufe. Denn das jeweilige Expertenwissen ist bereits in die Lösung eingeflossen, was in der Regel zu besseren Lösungen führt, aber auch die Wahrscheinlichkeit erhöht, dass die Bewertungsphase einfacher und mit einem aussagekräftigen Ergebnis abgeschlossen werden kann.

Auch wenn wir von Prozessen sprechen, können solche Designs je nach Feature auch in wenigen Minuten entstehen und in bereits eingeübten Ritualen wie Standups, Backlog Refinements, Swarming Phasen integriert werden. Oftmals ist die Phase "Prototyp" oder "Built", wie es im Original heißt, mit der Phase "Design" bereits abgeschlossen, da die Artefakte bereits im Designprozess mit Scribbles oder anderen Prototypen entstehen.

Prototyping

In der Prototyping-Phase, im Original "Built MMF" genannt, werden die Artefakte hergestellt, um zu evaluieren, ob die vorgeschlagene Lösung zu den gewünschten Ergebnissen führt. Das Ergebnis kann hier sein, dass die Lösung schlecht gewählt oder die Hypothese falsch war. Auch dies wäre ein gutes Ergebnis, da es verhindert, dass eine wertlose Implementierung gestartet wird, oder die Chance für eine echte Verbesserung in der nächsten Iteration wargenommen wird. Prototypische Visualisierungen sind hier in der Regel das Mittel der Wahl. Aus eigener Erfahrung können wir sagen, dass kaum etwas so sehr zu einem besseren gemeinsamen Verständnis im gesamten Projektteam führt, wie die frühe Visualisierung von Ideen in Prototypen, weshalb wir diese Phase generell auch gerne als "Prototyping" bezeichnen. Auch in dieser Phase ist es wichtig, auf Effizienz zu achten: Das bedeutet, dass nur das Nötigste gebaut werden sollte, um die Hypothese zu überprüfen, wofür das erste M in MMF (Minimal Marketable Feature) steht. Die Parallele zu einem MVP (Minimal Viable Product) aus dem agilen Umfeld ist auffällig und beides durchaus vergleichbar. "Bauen" kann letztlich bedeuten:

• Die Grundfunktionalität eines Features direkt umsetzen. Z.B. weil es ohnehin gebraucht wird und so "gemessen" werden kann, wie es sich entwickeln soll (s.o. Beispiel Breadcrumb-Trail).
• Visualisierung eines Prototyps. Hier reichen die Möglichkeiten von einfachen Scribbles bis hin zu aufwändigen, teilfunktionalen Prototypen, die auch für Nutzertests eingesetzt werden können. Wie immer ist "Angemessenheit" dafür eine wichtige Leitlinie.
• Die schlichte Beschreibung einer Idee für einfache Sachverhalte.

Evaluation

"Ich denke, der wahrscheinlich wichtigste [Grundsatz] ist [die] 'Minimum Viable Conversation'. Damit meine ich, dass man sich als Designer fragen sollte, was das Wichtigste ist, das man als nächstes kommunizieren muss. Wem müssen Sie es mitteilen? Was ist dann der geringste Arbeitsaufwand, den Sie tun müssen, damit diese Kommunikation stattfindet? Ich glaube, wenn es ein Gebot der schlanken UX gäbe, dann wäre es das." - Jeff Gothelf

In der Evaluationsphase wird die zu Beginn aufgestellte Hypothese anhand der Artefakte überprüft. Hier gibt es eine Vielzahl von Möglichkeiten und Methoden, um zu einem validen Ergebnis zu kommen. Manchmal reicht es aus, Stakeholder zu befragen oder die Lösung im Rahmen eines Reviews zu präsentieren. Also auf die Mittel zurückzugreifen, die ein agiles Setup bietet. Andere Fragestellungen lassen sich durch die Auswertung von Nutzungsstatistiken oder durch Benutzer:innentests beantworten. Hier reicht die Methodik von einfachen A/B-Tests bis hin zu qualitativen Befragungen.

Die Frage nach dem Wert der Erkenntnis ist wichtig. Nutzertests, wie wir sie aus dem forschungsbasierten klassischen UX Design kennen, die je nach Methode zwischen 5.000 und 20.000 Euro für Rekrutierung, Testdesign, Durchführung und Auswertung kosten, haben in Lean-UX eher nichts zu suchen. Wenn überhaupt, sind aufwändigere Evaluationen nur bei wichtigen Fragestellungen und besonders wertvollen Features interessant, z.B. wenn bei der Umsetzung Neuland betreten wird oder Lösungen besonders innovativ und für die gesamte Anwendung entscheidend sind. Sehr oft reicht es aber schon aus, sich mit einer Handvoll Nutzer:innen zu treffen und ihnen zu zeigen, was man vorhat, um ein gutes Gefühl für den Wert einer Lösung zu bekommen.

Ganz grundsätzlich muss die Einbeziehung von Benutzer:innen nicht immer mit hohem Aufwand und Kosten verbunden sein. Mit dem UX-Lab wir hier eine Lücke, indem wir es ermöglichen, mit minimalem Aufwand qualitativ hochwertige und aussagekräftige Evaluationen inklusive methodischer Beratung und Methodenvielfalt durchzuführen, um gezielte Fragestellungen effizient und aussagekräftig beantworten zu können.

Entscheidend ist, dass das Feedback der Nutzer, dass eine Hypothese nicht zutrifft, genauso wertvoll ist wie eine Bestätigung, da es hilft, unnötige Implementierungen zu vermeiden. Gleichzeitig erhält das Team Informationen aus erster Hand, um ein Problem besser zu verstehen und eine geeignete Lösung zu finden.

Iteration

"Ich denke, dass Agile oft daran scheitert, dass die Leute denken, dass es bei Agile nur darum geht, kleine Arbeitsschritte zu machen. In Wirklichkeit geht es bei Agile um kleine, kontinuierliche Feedbackschleifen" - Josh Seiden

Das Team kontinuierlich mit Wissen zu versorgen und Hypothesen zu überprüfen, bevor sie umgesetzt werden, ist am effektivsten, wenn dieser Prozess fest im agilen Zyklus verankert ist. Wenn Du viel Fahrrad fahren willst, schaffst du dir ein Hindernis, wenn du das Fahrrad vier Treppen tief im Keller einsperrst. Wenn es aber leicht zugänglich in der Garage steht, so dass du es nur aufschließen, aufsteigen und losfahren musst, wirst du es viel öfter benutzen. Bei kurzen Feedbackschleifen ist es wichtig, Hürden abzubauen und vor allem die Evaluationsphasen zu planen und methodisch schlank zu halten.

Ein großes Problem ist hier auch die Rekrutierung von Nutzer:innen, die bereit sind, die Fragen des Teams zu beantworten und Tests durchzuführen. Einerseits möchtest du nicht immer dieselben Leute befragen, andererseits ist der Aufwand, jedes Mal neue Benutzer:innen zu rekrutieren, eine große Hürde. Das UX-Lab haben wir entwickelt um diese Hürde abzubauen.

Werden forschungsbasierte Ansätze dadurch überflüssig?

Auf keinen Fall. Forschungsbasierte Ansätze, wie sie im Design Thinking und im Human Centered Design Prozess vorgesehen sind, schaffen großen Nutzen und sind trotz des relativen Aufwands effizient. Zum Beispiel in der Anforderungsphase, beim Design komplexer Systeme. Später im Projekt, bei der Umsetzung und Weiterentwicklung, ist es sinnvoll, über Lean-UX nachzudenken, um den Anspruch einer nutzerzentrierten Entwicklung aufrecht zu erhalten.

Insbesondere bei Neuentwicklungen ist es sinnvoll, ein systemweites Bild dessen zu erstellen, was später umgesetzt werden soll. Um auch hier evidenzbasiert vorzugehen, ist es notwendig, den Benutzer:innen ein ausreichend detailliertes Bild der gesamten Anwendung oder zumindest der wichtigen Teile zu geben, um valide Aussagen darüber zu erhalten, wie nützlich einzelne Features bewertet werden und wie verständlich deren Darstellung ist. Die guten Erfahrungen, die wir mit einem solchen Vorgehen gemacht haben, sind in der Case Study zu MyWE ausführlich dokumentiert.

Human centered design process