Der Lean-UX-Prozess

Lean UX definiert einen iterativen Implementierungsprozess, der aus vier Phasen besteht. Zunächst formuliert das Team seine Annahmen und Hypothesen in Bezug auf die Produktvision, Benutzer und Nutzungskontext sowie möglicher sinnvoller Funktionen. Anschließend entwickelt das Team gemeinsam Lösungen, um die Annahmen und Hypothesen zu prüfen, und erstellt Skizzen, Mockups, Prototypen oder ein MVP (»Minimum viable product«). Im letzten Schritt überprüft das Team seine Annahmen und Hypothesen, indem es seine Lösungen auf die Probe stellt. Dazu setzt es »kollaborative Recherchetechniken« ein und testet direkt mit dem Benutzer, zumeist qualitativ durch Befragungen, Beobachtungen und Tests.

Der Lean-UX-Prozess

Der Lean-UX-Prozess

Lean UX ist ein Ansatz, um Prinzipien und Methoden zur Verbesserung der Usability und User Experience in eine agile Entwicklung zu integrieren, und gleichzeitig der Titel eines Buches von Jeff Gothelf und Josh Seiden, in dem sie ihren Ansatz erklären: Lean UX – Produktentwicklung und -design mit agilen Teams (Amazon-Partnerlink). Lean UX vereint Ansätze aus der Agilen Entwicklung, dem Menschzentrierten Gestaltungsprozess und Design Thinking sowie Lean Startup zu einer neuen Methode. Diese Ansätze greifen sinnvoll ineinander und führen so zu einer schlanken (»lean«), nutzerzentrierten Entwicklung von Produkten. In dieser Artikelreihe fasse ich die wesentlichen Gedanken und Aussagen des Buchs in drei Teilen zusammen.

Dieser Artikel ist kein Erfahrungsbericht, sondern versucht, die Ausführungen von Gothelf und Seiden möglichst objektiv widerzugeben. Natürlich drückt sich eine gewisse Wertung, Gewichtung und Interpretation dadurch aus, dass ich bestimmte Teile hervorhebe und andere weglasse. Wer einen umfassenden und vollständigen Einblick in Lean UX haben möchte, sollte einfach das Buch lesen. Das ist mit rund 250 Seiten nicht umfangreich und auch in der Deutschen Übersetzung gut zu lesen.

Inhaltliche Diskussion und Austausch gerne in den Kommentaren, hier oder in den sozialen Netzwerken.

1. Annahmen und Hypothesen festlegen

Diese Phase bildet die Ausgangsbasis für jedes Projekt. Sie gibt eine klare Vision für die Arbeiten vor, die das Lean-UX-Team im Projektverlauf verrichtet.

Problemstellung formulieren

Zu Beginn und als Ausgangslage für den Lean-UX-Prozess formuliert das Lean-UX-Team zunächst die Problemstellung. Für ein vorhandenes Produkt umfasst die Problemstellung

  • die aktuelle Zielsetzung des Produkts,
  • das Problem, das gelöst werden soll, und
  • eine ergebnisoffene, lösungsorientierte WKW-Frage (»wie können wir«).

[Das Produkt] wurde für [diese Zielsetzung] entworfen. Wir haben jedoch festgestellt, dass [das Produkt] [diese Zielsetzung] nicht erfüllt, was sich in Form [dieses nachteiligen Effekts] auf unsere Geschäftstätigkeit auswirkt. Wie können wir [das Produkt] dahin gehend verbessern, dass [unsere Benutzer] aufgrund [dieser messbaren Kriterien] erfolgreicher damit arbeiten können?

Die Problemstellung für neue Produkte sieht etwas anders aus. Sie enthält

  • den aktuellen Zustand des Marktes,
  • die Chancen, die das Unternehmen ergreifen möchte, oder die Marktlücke, die es schließen möchte, sowie
  • die Vision für das Produkt.

Der [Marktbereich] konzentriert sich vornehmlich auf [Kundesegment, Problemfälle, Lösungen, …]. Für [diese Marktlücke] gibt es keine (oder keine guten, keine etablierten) Produkte oder Dienste. [Das Produkt] schließt diese Lücke durch [diese Vision/Strategie]. Wir werden uns zunächst auf [dieses Marktsegment] konzentrieren.

Annahmen deklarieren

Annahmen sind bestmögliche Einschätzungen nach aktuellem Wissensstand. Es gibt ein gewisses Risiko, dass die Annahmen falsch sind; sonst wären es keine Annahmen, sondern Gewissheiten. Im Lean-UX-Prozess sind Annahmen zu folgenden Themen von Bedeutung.

  • Geschäftliche Ergebnisse: Sie sind die Erfolgskriterien und die »Definition of done« für das Lean-UX-Team. Sie beschreiben eine (zumeist quantitativ) messbare Änderung des Benutzungserlebnisses oder Benutzerverhaltens.
  • Benutzergruppen: Die Menschen, deren Probleme das UX-Team lösen möchte.
  • Benutzerziele: Die effektiven Ziele (z.B. eine Aufgabe erledigen), emotionalen Ziele (z.B. sich kompetent fühlen) und langfristigen Ziele (z.B. finanzielle Sicherheit im Ruhestand) der Benutzer.
  • Funktionen: Produktumfang, -erweiterungen und -verbesserungen, die dabei helfen, die Ziele zu erreichen.

Das gesamte Team erarbeitet sich die Annahmen gemeinsam. Gothelf und Seiden schlagen dafür eine Reihe kollaborativer Methoden vor.

  • Sammeln, organisieren und priorisieren: Zunächst macht sich jedes Team-Mitglied für sich selbst Gedanken zu folgenden und ähnlichen Fragen und notiert Erkenntnisse auf Haftnotizzetteln. Wer sind die (ersten) Benutzer und was ist der größte Wert, den sie aus dem Produkt ziehen möchten/können (werden)? Was sind Erfordernisse und Anforderungen der Benutzer und wie können wir diese erfüllen? Wie akquirieren wir Kunden, wodurch verdienen wird Geld? Wer ist die wichtigste Konkurrenz und wodurch werden wir sie überholen? Was ist das größte Produktrisiko und wie werden wir es lösen bzw. umgehen? Welche Features sind wichtig? Wie sollte unser Produkt aussehen, wie sollte es sich verhalten? Wie werden wir wissen, dass unser Produkt Erfolg hat? – Anschließend stellen die Team-Mitglieder ihre Erkenntnisse der Reihe nach dem Rest des Teams vor. Dann werden die Antworten gesammelt, gruppiert und priorisiert.
  • »Start-up-Metrik für Piraten« von Dave McClure, auch »AARRR«-Methode genannt, wobei die Buchstaben für die folgenden Phasen eines Trichters stehen: Können wir Kunden für das neue Produkt/Feature gewinnen (»Acquisition«)? Wenn ja, nutzen sie das Produkt/Feature (»Activation«)? Werden sie das Produkt/Feature dauerhaft nutzen (»Retention«)? Werden sie es weiterempfehlen (»Referral«)? Sind sie gewillt, für das Produkt/Feature zu zahlen (»Revenue«)? – All dies ist messbar und daher eine gute Grundlage für Annahmen zu geschäftlichen Ergebnissen.
  • Die »Proto-Persona« ist die »lean« Variante der bewährten Persona-Methode. Auch eine Proto-Persona ist ein hypothetischer Benutzer mit konkret ausgeprägten Eigenschaften und Vorlieben sowie einem konkreten Nutzungsverhalten und steht repräsentativ für eine reale Benutzergruppe. Allerdings werden sie nicht empirisch aus umfassenden UX-Research-Ergebnissen abgeleitet, sondern repräsentieren zunächst nur die Annahmen des Lean-UX-Teams über die (vermuteten) Benutzergruppen. Dadurch sind Proto-Personas nicht »in Stein gemeißelt«, sondern können und sollen im Projektverlauf immer wieder hinterfragt, verändert und ergänzt werden.
  • Die Annahmen über die zu erreichenden Benutzerziele kann das Lean-UX-Team über Brainstorming-Methoden anhand der folgenden Fragen herausarbeiten: Was möchte der Benutzer erreichen? Welchen Eindruck möchte der Benutzer während dieses Vorgangs, davor und danach gewinnen? Wie bringt das Produkt den Benutzer einem Ziel oder der Erfüllung eines Wunsches näher? Auch Taktiken, Produktumfang und -funktionen, von denen das Team glaubt, dass sie das Benutzer- bzw. Kundenverhalten in die richtige Richtung lenken, kann das Lean-UX-Team mit Brainstorming-Methoden sammeln und ordnen.

Sobald das Team seine Annahmen zu Geschäftsergebnissen, Benutzergruppen, Ergebnissen und Features zusammengetragen hat, hat es das »Rohmaterial« zusammen und kann beginnen, daraus Hypothesen zu formulieren.

Hypothesenformulierung

Das Lean-UX-Team formuliert seine Hypothesen über folgendes Schema.

Wir sind der Auffassung, dass wir [folgendes Geschäftsergebnis] erreichen, wenn [dieser User] mit [diesem Feature] [dieses Ziel] erreicht.

Im Ergebnis sollte das Team sieben bis zehn Hypothesen formuliert haben, die jeweils folgende Kriterien erfüllen:

  • Spezifisch: Jede Hypothese fokussiert sich auf jeweils genau ein Geschäftsergebnis, eine Persona, ein Feature, ein Benutzerziel.
  • Überprüfbar: Hypothesen müssen mit aussagekräftigen Tests überprüft werden können.
  • Priorisiert: Der Hauptgrund, Annahmen und Hypothesen zu formulieren, liegt darin, Projektrisiken identifizieren zu können. Daher muss das Team feststellen, welche seiner Hypothesen die riskantesten sind, das heißt, wie schwerwiegend würde es sich auswirken, wenn das Team sich in diesem Punkt irrt? Das Lean-UX-Team sollte zunächst die Hypothesen validieren, die zugleich den höchsten Wert versprechen und mit dem höchsten Risiko behaftet sind.

2. Collaborative Design

In dieser Phase geht es darum, die Mitwirkung jedes Einzelnen an der Designarbeit zu fördern und das gemeinsame Verständnis innerhalb des Teams weiter auszubauen. Dies geschieht dadurch, dass das Team in einem maximal halbtägigen Workshop gemeinsam Entwürfe skizziert, bespricht und bewertet, um sich schließlich einer Lösung zu nähern, von der sich alle Beteiligten den größten Erfolg versprechen. Der Designer im Team übernimmt die Rolle des Moderators, der die übrigen Mitglieder des Teams (und zwar alle!) durch eine Reihe von Aktivitäten führt. Das Ergebnis sind Low-Fidelity-Skizzen und -Wireframes. Dieses Verfahren nennt sich »Design Studio« und wird seit einigen Jahren zunehmend angewendet, auch von Teams, die nicht nach der Lean-UX-Methode arbeiten, vor allem in frühen Produkt-Entwicklungsphasen im Rahmen der Ideenfindung und Konzeption.

Das Lean UX Design Studio

In einem »Design Studio« erarbeitet ein (Lean-UX-)Team von bis zu acht Personen innerhalb eines halben Tages nach einem festgelegten Ablauf Lösungen für eine konkrete Problemstellung, der »Design Challenge«. Gothelf und Seiden schlagen folgenden Ablauf vor.

Das Team ruft sich die Problemstellungen, Annahmen (inkl. Personas) und Hypothesen in Erinnerung, um die es in dem Workshop gehen soll, und definiert so die »Design Challenge«: Lösungen finden in Bezug auf konkrete Persona(s) und eine oder mehrere konkrete Hypothesen.

Jedes Team-Mitglied arbeitet fünf Minuten für sich allein. In dieser Zeit sollen sechs Lösungen in Form von Low-Fidelity-Skizzen (User Interfaces oder Teile davon, Workflows, Diagramme oder andere visuelle, nicht textuelle Ergebnisse) entstehen. Als Format eignet sich ein in 6 Rechtecke aufgeteiltes A3- oder A2-Papier oder ein Whiteboard (je Team-Mitglied).

Reihum bekommt jeder Teilnehmer drei Minuten Zeit, um seine Skizzen dem Rest des Teams zu präsentieren und zu erläutern. Anschließend gibt es reihum (konstruktives) Feedback.

Die Gruppe teilt sich in Paare auf, wobei Teilnehmer mit ähnlichen Ideen sich zusammentun sollten. Das Ziel dieser Phase ist es, die vielversprechendsten Ideen als Paar weiterzuentwickeln und konkreter auszuarbeiten. Das Ergebnis sind auch hier Low-Fidelity-Skizzen (auf A3-Papier oder einem Whiteboard), aber nicht mehr zwölf (zwei mal sechs), sondern nur wenige oder vielleicht auch nur eine, besonders vielversprechende.

Erneut werden die Ergebnisse reihum präsentiert und besprochen.

Abschließend verständigt sich das gesamte Team auf die Ideen, die ihrer Ansicht nach die größten Erfolgsaussichten haben, und entscheidet, welche Schritte als nächstes unternommen werden. Diese Ideen können die Grundlage für die nächste Phase bilden, der MVP-Erstellung, oder bereits direkt fürs Collaborative Discovery verwendet werden. Die weiteren guten Ideen landen auf einem »Parkplatz für gute Ideen«, alle anderen werden verworfen.

Passend dazu

Woran ein Design scheitern kann und wie Designer die Probleme umgehen
Es gibt verschiedene Probleme, die aus Trägheit oder Bequemlichkeit des Designers bzw. des Designteams resultieren. Sie führen alle dazu, dass das Design schlecht wird – oder zumindest weniger gut, als es sein könnte, wenn das Designteam motiviert, kreativ und benutzerzentriert arbeiten würde.

Verteilte Teams

Natürlich ist es besser, wenn alle Teilnehmer des Design Studios an einem Ort sind, wo sie fokussiert und ungestört zusammenarbeiten können. Aber aus verschiedenen Gründen ist das nicht immer möglich – zu der Zeit, in der ich diesen Artikel schreibe, hat die Corona-Pandemie das Leben in Deutschland weitergehend heruntergefahren; wir befinden uns im zweiten Lockdown und viele arbeiten im Home Office. Aber Design Studios lassen sich auch remote durchführen! Es gibt mittlerweile zahlreiche Screensharing- und Videokonferenztools (mit »Breakout«-Funktion zur Aufteilung der Gruppe in Paare, z.B. Zoom, Webex), Tools zur Kommunikation und Dateiablage (z.B. Slack, Teams) und virtuelle kollaborative Whiteboards (z.B. Mural, Miro) – und zudem viel Erfahrung in der Durchführung kreativer Formate.

3. MVP erstellen

Ein »Minimum viable product«, kurz: »MVP«, ist – im Sinne von Lean UX – die kleinste, rudimentäre Produktversion, die das Lean-UX-Team mit minimalem Aufwand erstellen kann, um zu ermitteln, ob eine ihrer Hypothesen zutrifft. Es repräsentiert eine Annäherung an die User Experience und simuliert die Nutzung des betreffenden Produkts oder Dienstes. Es geht darum, den zentralen Nutzwert der Idee herauszustellen.

Dazu stehen dem Team die folgenden Varianten der MVP-Erstellung zur Verfügung. Welche Variante es wählt, ist abhängig davon, wie sicher das Team sein kann, dass seine Hypothese zutrifft und dass seine Idee gut ist. Je sicherer das Team ist, desto mehr Arbeit kann es in das MVP investieren. Die zentrale Frage ist: Wie groß ist der minimale Aufwand, um die nächste wichtige Sache in Erfahrung zu bringen? Alles, was darüber hinaus geht, widerspricht dem Prinzip »Verschwendung minimieren«.

Design-Studio-Skizzen und Low-Fidelity-Prototypen auf Papier

Die einfachen Low-Fidelity-Skizzen, auf ein A3-Blatt oder Whiteboard geschmiert, können bereits ausreichend sein, um Feedback zur zugrundeliegenden Idee und Informationsarchitektur zu erhalten. Mit etwas mehr Zeit und Mühe (ein oder zwei Stunden) mit Techniken wie auf- und zu klappbarer oder in sich verschiebbarer Bereiche, ausgeschnittener oder passend zugeschnittener Flächen können Interaktionen wie Ein- und Ausblenden, Scrollen, Diashows, Blättern etc. simuliert werden und dadurch der User Flow des Produkts. Derartig einfache MVPs sind schnell und preiswert herzustellen und erlauben es, Ideen einfach mal auszuprobieren und auch wieder zu verwerfen – außerdem machen sie viel Spaß.

Papier-Prototyp, rechts ein High-Fidelity-Prototyp mit Sketch (Amélie Mourichon, Unsplash)

Digitale Low-Fidelity-Prototypen

Es gibt viele Gründe, warum Papier-Prototypen nicht mehr ausreichen, etwa weil der gewünschte Grad der Simulation sich nicht mehr darstellen lässt, ein digitales Artefakt benötigt oder gefordert ist oder weil der Benutzer selbst (ohne Hilfe und ohne, dass jemand »Schnipsel« austauscht) mit dem Prototyp interagieren soll. In diesem Fall erstellt das Lean-UX-Team (in ein oder zwei Tagen) digitale, klickbare Prototypen (Wireframes, Mockups) mit dem Tool ihrer Wahl, z.B. Balsamiq, Figma oder auch PowerPoint. Einfache, klickbare Prototypen vermitteln eine gute Vorstellung vom Workflow und der Art der Interaktion mit dem Produkt.

Low-Fidelity-Prototyp (balsamiq.com)

Mid- und High-Fidelity-Prototypen

Prototypen mit mittlerer oder hoher Wiedergabetreue sind qualitativ hochwertige und realistische Prototypen, die Workflow- und User-Interface-Interaktionen umfassend abbilden. Häufig enthalten sie realistische Texte und Labels (keine »Lorem ipsum«-Texte mehr, aber auch noch keine echten Daten) und sind visuell ausgestaltet, wodurch sie der finalen User Experience (sehr) nahekommen. Die Erstellung eines solchen Prototyps (mit den oben genannten Tools oder zum Beispiel mit Axure oder Adobe XD) nimmt mehrere Tage in Anspruch, und häufig wird er im Projektverlauf weiter ausgebaut, wodurch zusätzliche Aufwände entstehen, weil echte Produkt-Funktionalitäten nachgebaut und der Prototyp konsistent gehalten werden muss.

Prototypen in Ziel-Technologie

Wenn sich das Team seiner Sache sehr sicher ist und mehr Zeit investieren will, um ein realistisches MVP zu erstellen, oder wenn es in der Entwicklung dermaßen effizient ist, dass die Programmierung den Aufwand für die Arbeit mit dem Prototyping-Tool nicht oder kaum überschreitet (und Entwickler verfügbar sind), dann kann der Prototyp auch direkt in der Ziel-Technologie gebaut werden. Im Ergebnis erhält das Team einen Prototypen, der nicht von finalen Produkt zu unterscheiden ist. Denkbar ist auch, den Prototypen innerhalb des echten Produkts darzustellen und mit realistischen Test- oder Livedaten zu speisen. Derartige Prototypen erlauben analytische Einblicke in das Nutzerverhalten und eigenen sich für die Durchführung von A/B-Tests. Allerdings muss das Team aufpassen, dass es sich nicht verzettelt; es handelt sich schließlich immer noch um einen Prototypen, der bei den Nutzertests durchfallen könnte und wieder verworfen (und ausgebaut) werden müsste.

Andeuten, was noch nicht da ist: Pseudo-Features und Wizard-of-Oz

Die bisher beschriebenen Prototyping-Techniken zeigen etwas, was da ist – vielleicht nur grob skizziert, aber dennoch sichtbar und »anfassbar«. Daraus lassen sich Schlüsse ziehen, ob eine Lösung funktioniert – aber gibt es überhaupt eine Nachfrage nach dieser Lösung? Trifft die Hypothese, dass der Benutzer dieses Feature benötigt, an sich zu, unabhängig davon, wie gut das Feature umgesetzt ist? Um das herauszufinden, können »Pseudo-Features« oder »Wizard-of-Oz« verwendet werden.

Pseudo-Features deuten eine Funktion an, etwa über einen Button (zum Beispiel »Für den Newsletter anmelden«), aber dahinter gibt es noch keine echte Funktion (es gibt also überhaupt keinen Newsletter – jedenfalls noch nicht). Das Lean-UX-Team kann messen, wie häufig diese Funktion aufgerufen wird, und daraus Rückschlüsse ziehen, ob es sich lohnt, daran weiterzuarbeiten.

Bei einem Wizard-of interagieren Benutzer mit dem Interface, resultierende Systemreaktionen werden jedoch durch menschliche Akteure durchgeführt oder simuliert und durch das Interface an den Benutzer zurückgemeldet. Als Beispiele nennen Gothelf und Seiden die Entwicklung von Amazon Echo (die Antworten kamen zunächst von Menschen aus dem Nebenraum) sowie einen Online-Marktplatz für die Vermittlung von Freiwilligen, der über Monate nur aus einer Handvoll statischer Webseiten bestand ohne echte Funktionalität und Automatisierung; System-Nachrichten beispielsweise kamen von Mitarbeitern, die nur so taten, als hätte das System sie verschickt. Auf diese Art und Weise kann die Akzeptanz von Ideen sowie Abläufe und Geschäftsprozesse ausprobiert und getestet werden ohne viel Zeit in das Design und die Entwicklung der falschen Dinge zu investieren.

4. Collaborative Discovery: Recherche und Feedback

Die gesamte bis hierhin verrichtete Arbeit basierte auf Annahmen – nun beginnt die Validierung mit leichtgewichtigen, kontinuierlichen und kollaborativen Evaluations-Techniken. In dieser Phase des iterativen Lean-UX-Prozesses geht es darum, das MVP auf die Probe zu stellen. Die Idee ist, dass das gesamte Lean-UX-Team Rechercheaktivitäten in jeden Sprint einbaut und gemeinsam durchführt.

Damit das funktioniert, braucht das Team entsprechende Kenntnisse und Fähigkeiten, muss also Research- und Evaluationsmethoden kennen und anwenden können. Dazu sollte ein entsprechender Experte Teil des Teams sein, der aber nicht die ganze Arbeit übernimmt (denn dann wäre diese Phase nicht kollaborativ), sondern der vielmehr als eine Art Coach fungiert, der das Team bei der Planung und Ausführung seiner Aktivitäten anleitet und unterstützt.

Feldstudien

Bei Feldstudien im Sinne von Lean UX schwärmt das gesamte Lean-UX-Team in wechselnden Paaren (verschiedener Disziplinen) aus, um Benutzer vor Ort im Nutzungskontext zu befragen – im Büro, Einkaufszentrum, Lagerhalle, Autohaus; wo auch immer Benutzer das Produkt oder den Service verwenden bzw. verwenden würden. Zur Vorbereitung hat das Lean-UX-Team Annahmen, Hypothesen und MVPs gesichtet und entschieden, welche Informationen es als nächstes einholen muss. Das Ziel des Gesprächs ist es, die Annahmen und Hypothesen zur Nutzergruppe sowie zum Produkt oder Service zu validieren. Das Team zeigt auch das MVP und lässt es den Nutzer ausprobieren, falls möglich. Allerdings sollte dies erst zum Schluss geschehen, denn sonst besteht die Gefahr, dass sich das gesamte Interview nur um das MVP dreht und anderer, hilfreicher Input unter den Tisch fällt.

Continuous Learning: Jeden Donnerstag testen

Ein wichtiges Erfolgsrezept bei Lean UX ist es, eine in regelmäßigen Abständen erfolgende Nutzerbeteiligung zu etablieren, damit das UX-Team seine Hypothesen schnell validieren und gegebenenfalls wieder verwerfen kann, ohne bereits zu viel Arbeit in »Sackgassen« investiert zu haben. Gothelf und Seiden empfehlen wöchentliche Usability-Tests nach der »3-12-1-Methode«: drei Benutzer bis zwölf Uhr mittags, einmal die Woche, und zwar am Donnerstag. Der Ablauf ist hierbei wie folgt.

Das Lean-UX-Team entscheidet, was in dieser Woche getestet wird und welche Testteilnehmer es dafür benötigt. Das Anwerben der Teilnehmer sollte das Team einem externen Dienstleister überlassen.

Das MVP wird so angepasst und optimiert, dass der Testteilnehmer die Story verstehen und auch testen kann.

Das Testskript dient dem Moderator (ein Mitglied des Lean-UX-Teams, idealerweise jede Woche ein anderes) als Leitfaden für den Test.

Der Moderator führt die Teilnehmer (nacheinander) durch den Test; alle anderen Mitglieder des Lean-UX-Teams und gegebenenfalls weitere Stakeholder schauen (über entsprechende Screensharing- und Videokonferenztools) zu und machen sich Notizen. Nach dem Ende der Test-Sessions stößt der Moderator zum Rest des Teams und es beginnt die Auswertung nach der Methode: Sammeln, organisieren und priorisieren.

Das Lean-UX-Team validiert die Hypothesen und überlegt sich, was als Nächstes zu tun ist.

Bei klassischen Usability-Tests versucht ein Usability-Testteilnehmer unter Benutzung des interaktiven Systems oder eines Prototyps repräsentative Usability-Testaufgaben zu lösen. Das geht bei Lean UX nicht immer, denn es gilt die Devise: Die Benutzer testen alles, was auch immer am Testtag fertig ist. Das können auch Skizzen oder einfache Low-Fidelity-Prototypen sein. Wichtig ist die Kontinuität und der Mut des Lean-UX-Teams, sich in jedem Design- und Entwicklungsstadium schnell Nutzerfeedback und damit neue Erkenntnisse einzuholen.

Kontinuierlich Feedback einholen

Feldstudien und Usability-Tests sind hervorragende Methoden, speziell für die Konzeptionsphase. Sobald das Produkt auf dem Markt ist und genutzt wird, kann das Lean-UX-Team zudem sehr viel über die Nutzung des Produkts lernen, auch ohne die Benutzer direkt zu fragen.

  • Den Kundendienst einbeziehen durch Gespräche, regelmäßige Meetings und Beteiligung an den Collaborative-Design- und Test-Sessions.
  • Verschiedene Online-Kanäle für Kunden-Feedback bereitstellen und nutzen, zum Beispiel Feedback-Formulare, Zufriedenheit oder NPS-Umfragen, aktive Teilnahme des Lean-UX-Teams an Support-Foren und vieles mehr.
  • Suchprotokolle auswerten: Was wollen Benutzer auf der Website finden und finden sie es tatsächlich?
  • Nutzungsdaten analysieren, um mehr darüber herauszufinden, wie die Benutzer eine Website oder Webanwendung tatsächlich nutzen und wo sie anscheinend Schwierigkeiten haben, etwas weil Abbrüche sich häufen.
  • A/B-Tests durchführen, eine Testmethode zur Bewertung zweier Varianten einer Lösung, bei der die Originalversion gegen eine leicht veränderte Version, die zumeist nur an einen kleinen Teil der Benutzer ausgeliefert wird, getestet wird. Über die Analyse der Nutzungsdaten kann das Lean-UX-Team herausfinden, welche Lösung bessere Ergebnisse erzielt.
Michael Jendryschik
0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlassen Sie mir einen Kommentar!

Ihre Kommentareingaben werden zwecks Anti-Spam-Prüfung an den Dienst Akismet gesendet. Darüber hinaus nutze ich die eingegebene E-Mail-Adresse zum Bezug von Profilbildern bei dem Dienst Gravatar. Weitere Informationen und Hinweise zum Widerrufsrecht finden sich in der Datenschutzerklärung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert