Im Jahr 2022 ist Scrum inzwischen Mainstream – und dank des Erfolgs von Produkten wie dem iPhone von Apple, dem Kindle von Amazon oder der Suche von Google gilt dasselbe auch für User Experience.
Und doch weiß ich, dass das Zusammenbringen von Softwareentwicklung und UX fast jedes Team vor Schwierigkeiten stellt.
Die beste Hilfe, die ich diesen Scrum Teams geben kann, ist das Professional Scrum mit UX-Training von Scrum.org. Es hilft Scrum-Praktikern UX-Praktiken in die kontinuierliche Produktentwicklung zu integrieren und es unterstützt UX-Experten dabei, innerhalb von Sprints zu arbeiten. Das Training wurde von Jeff Gothelf und Josh Seiden entwickelt, den Begründern der Lean UX Bewegung. Ein zentrales Hilfsmittel, welches die Teilnehmer im Training lernen, ist das Lean UX Canvas. Da ich viele Fragen zur Verwendung dieses Canvas bekomme, werde ich es in diesem Artikel anhand eines Beispiels ausführlich vorstellen.
Übersicht über das Lean UX Canvas
Wie jedes Canvas ist das Lean UX Canvas ein Werkzeug, um Gespräche im Team zu führen.
Das Canvas strukturiert die Gespräche entlang vier grundlegender Fragestellungen:
- Heute. Welches Unternehmensproblem (Business Problem) existiert heute und wer sind die Kunden, für die wir es lösen möchten?
- Später. Wenn wir das Unternehmensproblem gelöst haben, welches Unternehmensergebnis (Business Outcome) haben wir erreicht? Welche Verhaltensänderungen bei den Nutzern zeigen uns, dass die Problemstellung erfolgreich gelöst wurde? Was machen die Nutzer jetzt anders? Welche Vorteile haben unsere Nutzer mit der Verwendung unseres Produkts erlangt?
- Wie kommen wir von „Heute“ zu „Später“? Was können wir entwickeln? Welche Lösung werden wir unseren Kunden bereitstellen?
- Woher wissen wir, dass das Unternehmensproblem gelöst und das angestrebte Unternehmensergebnis erzielt wurde?
- Für Produktteams, die diese Fragestellungen gemeinsam im Team beantworten, stellt das Canvas eine Grundlage zur funktionsübergreifenden Zusammenarbeit dar. Sie erarbeiten dabei Schritt für Schritt die Inhalte von Box 1 bis Box 8 und ergänzen Informationen, wenn sie Neues zu einer Frage in Erfahrung gebracht haben.
Box 1: Unternehmensproblem
Die Beantwortung der ersten Box läutet für viele Teams ein Umdenken ein.
Es führt sie davon weg, wie eine Feature-Factory zu denken, und dahin, wie ein Produktteam zu denken. In einer Feature-Factory denkt man nur in Lösungen. In Produktteams denken wir in Problemstellungen, die es zu entdecken und zu durchdenken gilt. Dieses Umdenken ermöglicht nun den Teams kreativ nach einer Kombination aus Design, Code, Produktmanagement, Kundenservice, Werbetext, Preisstrategie usw. zu suchen, die das Problem bestmöglich löst.
Ein gutes Unternehmensproblem zeichnet sich dadurch aus, dass es
- eine spezifische Herausforderung beschreibt, welche das Team lösen soll,
- aus der Nutzersicht betrachtet wird,
- sich auf eine Problemstellung konzentriert,
- den Umfang der Arbeit, welche ein Team unternimmt, durch klar messbare Erfolgsfaktoren beschränkt und
- keine Lösung vorschreibt.
Diese Rahmenbedingungen ermöglichen dem Team fokussiert und kreativ an einer Lösung zu arbeiten.
Dazu sollte ein Unternehmensproblem folgende drei Fragen beantworten:
- Wie lautet das aktuelle Ziel des Produkts?
- Was hat sich jetzt verändert und welches Problem ist daraus entstanden? Wo wird das Ziel nicht mehr erreicht?
- Wie lautet ein spezifischer Verbesserungswunsch, welcher keine spezielle Lösung vorschreibt?
Mit der Beantwortung dieser Fragen lässt sich dann ein Unternehmensproblem formulieren, wenn wir folgendes Template verwenden:
[Unser Produkt] wurde für [diese Zielsetzungen] entwickelt. Wir haben [auf diese Weise] festgestellt, dass das Produkt dieses Ziel nicht erfüllt, was [diese negative Auswirkung/dieses Unternehmensproblem] für unser Unternehmen verursacht. Wie könnten wir [unser Produkt] dahingehend verbessern, dass unsere Kunden aufgrund [dieser messbaren Kriterien] unser Produkt erfolgreicher nutzen können?
Im Folgenden ein Beispiel, um die Formulierung eines Unternehmensproblems zu veranschaulichen. Betrachten wir dazu die Situation von Mobile Drive:
Mobile Drive ist ein Technologieunternehmen, das daran arbeitet, selbstfahrende Fahrzeuge für die breite Masse zugänglich zu machen. Anstatt die Fahrer zu zwingen, ein neues Auto zu kaufen, verspricht Mobile Drive, jedes Auto nachträglich mit seinem Mobile-Drive-Kit, bestehend aus Sensoren, Adaptern und Software, in ein selbstfahrendes Auto zu verwandeln. Die Fahrer können Mobile Drive über eine App von einem nachträglich im Armaturenbrett des Fahrzeugs installierten Tablets aus bedienen.
In den letzten Jahren hat Mobile Drive erfolgreiche Alpha- und Beta-Tests durchgeführt und mit dem Verkauf seines Produkts im europäischen Markt begonnen. Die ersten Ergebnisse sind gemischt. Mobile Drive hat festgestellt, dass die Sensoren und die Hardware gut funktionieren. Aber die Fahrer berichten, dass sie frustriert sind, wenn sie versuchen, Mobile Drive über das Tablet zu bedienen.
Ein mögliches Unternehmensproblem für die Situation, in der sich Mobile Drive befindet, könnte wie folgt lauten:
Mobile Drive wurde entwickelt, um autonomes Fahren in Fahrzeugen nachzurüsten, damit jeder bequem und sicher ans Ziel kommt.
Durch Kundeninterviews, Umfragen und Bewertungen im App Store haben wir erfahren, dass die Displays der nachgerüsteten Tablets häufig schlecht vom Fahrersitz aus zu lesen sind. Darüber hinaus ist die Bedienung umständlich und kostet manchmal so viel Zeit, dass die Fahrer auf die Unterstützung von Mobile Drive bei kurzen Fahrten verzichten. Deshalb würden Kunden Mobile Drive nicht weiterempfehlen und viele haben sich bereits in Reviews über die Bedienung beschwert.
Wie können wir Mobile Drive verbessern, sodass unsere Kunden komfortabler ans Ziel gelangen und ihren Freunden begeistert davon erzählen?
Box 2: Unternehmensergebnisse
Woran erkennen Produktentwicklungsteams, ob sie das Problem ihres Unternehmens gelöst haben?
Wenn die Unternehmensergebnisse dies widerspiegeln. Unternehmensergebnisse sind übergeordnete Erfolgskriterien eines Unternehmens. Diese Ergebnisse werden durch Kennzahlen beschrieben, welche sich häufig auf einem KPI-Dashboard des CEO eines Unternehmens wiederfinden lassen. Beispiel hierfür sind Kundenzufriedenheit, Umsatz oder Kundenbindungsrate.
Allerdings sind Kundenzufriedenheit, Umsatz und Kundenbindungsrate ungeeignete Kennzahlen, da sie abstrakt und schwer messbar sind oder keine Trends erkennen lassen. Gute Metriken hingegen zeichnet aus
- dass sie ein Verhältnis oder einen Anteil ausdrücken,
- die Art und Weise verändern, wie Menschen sich verhalten und
- das Wichtigste, was das Team jetzt wissen muss, wiedergeben (die Kennzahlen einer Produktentwicklung verändern sich über den Lebenszyklus des Produkts).
Ob Mobile Drive erfolgreich ihr Unternehmensproblem gelöst haben, zeigt sich in gesteigerter Kundenzufriedenheit.
Drei mögliche Metriken zur Kundenzufriedenheit könnten lauten:
- 25 % Steigerung des Net-Promoter-Score
- 75 % der Fahrer verwenden Mobile Drive mehr als einmal pro Woche
- 25 % weniger negative Reviews im App Store
Box 3: Nutzer
Wie können Produktteams das Unternehmensproblem lösen?
Das Unternehmensproblem kann nur gelöst werden, indem die Nutzer ihr Verhalten so ändern, dass es sich positiv auf die Unternehmensergebnisse auswirkt.
Deshalb müssen wir als Nächstes unsere Anwender besser verstehen. Das erreichen wir, indem wir beschreiben, was sie auszeichnet und welche Vorteile sie mit der Verwendung unseres Produkts erlangen werden. Um die Nutzer zu beschreiben, verwenden wir im Lean UX Proto-Persona. Proto-Persona ist ein leichtgewichtigerer Ansatz als beispielsweise Marketing oder Käuferpersonas, da weniger Marktrecherche oder Marktforschung vorab nötig ist. Es genügen bereits Kundeninterviews, um erste Annahmen über die möglichen Anwender des Produkts zu formulieren.
Dabei wollen wir folgende 3 Dinge über die Nutzer festhalten:
- Einen Namen und eine Skizze, die diese Nutzergruppe gut beschreiben.
- Verhaltens- und demographische Informationen, die sich auf die Art und Weise auswirken, wie diese Person unser Produkt nutzen würde.
- Bedürfnisse, die der Kunde hat, bei deren Befriedigung wir ihm helfen wollen, und was ihn derzeit daran hindert, diese Bedürfnisse zu erfüllen.
Im Beispiel von Mobile Drive könnten wir folgende Nutzerin identifiziert haben:
Diese ersten Annahmen, zusammengefasst zu einem Prototyp einer Persona, genügen Produktteams, um iterativ die Persona weiterzuentwickeln, wenn sie mehr über die Nutzer lernen.
Box 4: Ergebnisse und Vorteile für Nutzer
Die Beantwortung der nächsten Fragen entscheidet über Erfolg oder Misserfolg des Produkts:
- Welchen Vorteil werden die Nutzer durch die Verwendung des Produkts erhalten?
- Welchen Nutzen werden die Nutzer aus der Verwendung des Produkts ziehen?
- Was wird das Ergebnis davon sein, welches wir messen können?
- Welches neue Verhalten ermöglicht unser Produkt den Nutzern?
Nur wenn ein Produktteam die Motivation der Anwender hinter der Verwendung des Produkts versteht und zusätzlich messen kann, wenn der Nutzer seine Ergebnisse mit der Verwendung des Produkts erreicht, ist das Produktteam in der Lage, zu bewerten, ob das Unternehmensproblem gelöst wurde und somit die Unternehmensergebnisse erreicht werden konnten. Denn die Produktorganisation sollte niemals vergessen: Über den Erfolg eines Produkts entscheidet am Ende immer der Kunde, indem er das Produkt verwendet oder eben nicht.
Als Startpunkt zur Beantwortung der Fragen in Box 4 können wir die Porto-Persona aus Box 3 betrachten. In der unteren Hälfte des Porto-Persona-Template finden sich bereits erste Vorteile, die sich die Nutzer bei der Verwendung des Produkts erhoffen. Möchte das Team weitere Vorteile erarbeiten, ist es hilfreich, in Kundeninterviews speziell auf diesen Bereich zu fokussieren.
Die Ergebnisse, die Volvo Viktoria erhalten möchte, könnten die Folgenden sein:
- entspannt mit dem Auto unterwegs sein
- während des Autofahrens auch Zeit für ihre Kinder haben
Box 5: Lösungen
Welche Lösung können wir anbieten, die unserer Person hilft und die unserem Unternehmen hilft, die Geschäftsergebnisse zu erreichen?
Diese Frage sollte das Team gemeinsam in dieser Box beantworten. Eine einfache Möglichkeit dazu ist mit einem Brainstorming zu starten. Wichtig dabei: Es sollten keine Ideen zurückgehalten werden. Hier macht es sich bezahlt, wenn das Produktteam sehr unterschiedlich zusammengesetzt ist, um noch mehr Kreativität zu entwickeln.
Im Beispiel von Mobile Drive könnten dies mögliche Lösungsideen sein:
- verschlanktes User Interface
- sprachgesteuertes User Interface
- Speichern und Anzeigen der wahrscheinlichsten Route als Voreinstellung
- Kooperation mit dem Autohersteller, um Mobile Drive direkt ins Auto zu integrieren
- Kooperation mit dem Kartenanbieter, um Mobile Drive bereits zu Hause mit dem Smartphone zu konfigurieren
Nach dem ersten Brainstorming kann sich das Team noch weitreichendere Details zu den einzelnen Lösungsmöglichkeiten erarbeiten. Dazu können Sketches, Skizzen, Wireframes oder Ähnliches verwendet werden.
Dies spiegelt auch einen der Grundgedanken des Lean UX wider: Lean UX vereint Designer und Nicht-Designer in gemeinschaftlicher Kreativarbeit.
Box 6: Hypothesen
Lean UX Canvas Box 1 bis Box 5 vereint eines: Es sind Annahmen!
Um zu überprüfen, ob sie sich bewahrheiten, müssen wir jede formulierte Annahme in ein einfach zu testendes Format umwandeln: eine Hypothese.
Wir glauben, dass [Unternehmensergebnis] wird erreicht, wenn [Nutzer] erfolgreich [Vorteile oder Ergebnisse] mit [Lösung] erzielt.
Da die Elemente der Hypothesen genau mit den Boxen im Lean UX Canvas korrelieren, lassen sich die Hypothesen im Falle von Mobile Drive einfach aufstellen.
Wir glauben, dass der Net-Promoter-Score um 25 % steigt, wenn Viktoria Volvo entspannt mit dem Auto unterwegs ist, da ihr ein sprachgesteuertes User Interface zur Verfügung steht.
Wir glauben, dass 75 % der Fahrer Mobile Drive mehr als einmal pro Woche verwenden, wenn Viktoria Volvo während der Autofahrt mehr Zeit für ihre Kinder hat, da wir eine Kooperation mit dem Kartenanbieter eingegangen sind, um Mobile Drive bereits zu Hause vom Smartphone aus zu konfigurieren.
Wir glauben, dass wir 25 % weniger negative Reviews im App Store erhalten, wenn Viktoria Volvo entspannt mit dem Auto unterwegs ist, was wir ihr mit einem verschlankten User Interface ermöglichen.
Hierbei ist das Aufstellen einer Hypothese bereits der erste Test, ob es sinnvoll ist, diese Lösung zu entwickeln. Wenn Teams nicht in der Lage sind, eine Hypothese zu formulieren, sollte die Lösung unter keinen Umständen entwickelt werden. Darüber hinaus sollte immer nur eine Lösung pro Hypothese betrachtet werden, sonst ist die Hypothese nicht überprüfbar.
Box 7: Risiken
Die meisten Produktteams leben nicht in einer Realität, in der ihr gesamtes Budget für Lernaktivitäten verwendet werden kann. Irgendwann müssen sie Produkte ausliefern. Deshalb stellen die Teams sich die Frage:
Welche Hypothesen auf dem Weg zu neuen Produktfeatures sollten wir testen?
Die Antwort liefert das Hypothesen-Priorisierungs-Canvas. Dieses Canvas können Produktteams verwenden, um herauszufinden, welche Hypothesen tatsächlich mit Experimenten ergründet werden sollten und welche sofort verworfen werden können.
Nachdem das Produktteam die Hypothesen priorisiert hat, stellt sich für die Hypothesen, die getestet werden sollen, die Frage:
Was ist das Wichtigste, das wir als Erstes lernen sollten?
Dazu wird es jetzt mindestens so viele Antworten geben, wie unterschiedliche Experten im Team versammelt sind. Hier einige Beispiele im Fall von Mobile Drive:
- Erkennt das System zuverlässig die Stimme?
- Reicht die Prozessorleistung, um die Sprachsteuerungsfunktion auszuführen?
- Werden die Nutzer die Funktion annehmen?
- Wird die Sprachsteuerung die Nutzer so begeistern, dass sie Mobile Drive weiterempfehlen?
- Bei der Auswahl des größten Risikofaktors sollte sich ein Team auf den möglichen Wert der Hypothesen fokussieren und nicht auf die Machbarkeit, da die Machbarkeit nebensächlich ist, wenn die Lösung keinen Mehrwert liefern wird.
Im Beispiel könnte das größte Risiko für den Wert des Produkts darin bestehen, dass die Nutzer die Sprachsteuerungsfunktion nicht annehmen. Wenn die Nutzer die Sprachsteuerung als Bedienung nicht akzeptieren, hält die Hypothese dem Test nicht stand.
Box 8: Experimente
Was ist das kleinste Experiment, das wir durchführen können, um unsere Hypothesen zu testen?
Um dieses Experiment zu erhalten, müssen wir diese zwei Fragen beantworten:
- Was ist das Nächstwichtigste, was wir lernen müssen?
- Wie können wir das mit dem geringsten Aufwand erreichen?
Die Antwort zur ersten Frage finden wir bereits in Box 6. Für die Beantwortung der zweiten Frage, der Beschreibung des Experiments, sollte sich das Team immer vor Augen führen:
Je geringer der Aufwand ist, desto weniger Zeit wird verschwendet, falls wir uns irren sollten, und desto schneller können wir etwas Neues versuchen!
Um Ideen für Experimente mit vertretbarem Aufwand zu finden, kann die Truth Curve nach Giff Constable helfen.
Die Wahrheitskurve zeigt, dass Lernen stetig verläuft und ein erhöhter Aufwand nur gerechtfertigt ist, wenn die Fakten es nahelegen.
In unserem Beispiel könnte ein erstes Experiment sein, bestehende Kunden zu interviewen, ob sie eine Sprachsteuerung verwenden würden.
Nach der Durchführung des Experiments folgt die Auswertung. Im Beispiel von Mobile Drive ist es hilfreich, wenn das ganze Team an der Auswertung teilnimmt. Denn am Ende geht es beim Lean UX Canvas darum, ein gemeinsames Verständnis herzustellen.
Nach der Auswertung bieten sich dem Team drei Möglichkeiten, mit der Hypothese umzugehen:
- verwerfen
- pivotieren
- weiterverfolgen
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie man mit dem Lean UX Canvas arbeitet, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.