Für wen ist das?

Teil fünf der Werkzeugkiste des Product Owners. Das Ferientool hat eine Vision und ein erstes Epic. Bevor wir das Epic in Features herunterbrechen, müssen wir die Menschen kennen, für die wir es bauen.

Personas

Eine Persona ist ein erfundenes, aber konkretes Mitglied einer Nutzergruppe, mit persönlichen Merkmalen, Absichten und Gefühlen.

Gute Personas entstehen aus Daten. Du sammelst sie mit Interviews oder Fragebögen, gruppierst sie mit einer Segmentierung oder Clusteranalyse und verdichtest jede Gruppe zu einer Persona. Eine Persona, die in einem Workshop von Leuten erfunden wurde, die nie einen Nutzer getroffen haben, ist ein Klischee mit Namen. Das ist schlimmer als gar keine Persona, weil es wie ein Beleg aussieht.

Eine Persona macht eine Nutzergruppe greifbar. Das Team kann sich vorstellen, wie diese Person denkt, und baut deshalb nicht an ihr vorbei. Personas helfen auch beim Priorisieren: «Hilft das Sandra?» ist eine Frage, die Diskussionen beendet.

Eine Persona hat vier Teile:

• Wer: Name, Alter, Beruf, Funktion, Aufgaben, Ausbildung, Wissen
• Bedürfnisse und Verhalten: Wie sieht ein typischer Tag aus? Mit welchen Problemen kämpft sie?
• Ziele und Erwartungen: Was will sie erreichen?
• Werte und Ängste: Welche Gefühle begleiten ihre tägliche Arbeit? Was leitet ihre Entscheidungen?

Fang mit einer primären Persona an. Ergänze eine oder zwei für den erweiterten Umfang, aber nicht mehr. Mit fünf Personas dient jedes Feature irgendwem, und die Personas helfen dir bei keiner Entscheidung mehr.

Die primäre Persona des Ferientools

Sandra, 41, Teamleiterin im Lager. Sie führt 14 Leute in zwei Schichten. Sie ist gelernte Logistikerin und seit zwölf Jahren in der Firma. Ihre Schichten plant sie in einer eigenen Tabelle, die sie selbst gebaut hat und auf die sie stolz ist.

• Bedürfnisse und Verhalten: Sie bewilligt Anträge auf dem Handy, zwischen zwei Regalen. Bis sie eine E-Mail sieht, haben schon zwei andere dieselbe Woche beantragt.
• Ziele: Im August darf das Lager nicht unter neun Leute pro Schicht fallen.
• Werte und Ängste: «Das Tool ist mir egal. Mir ist wichtig, dass der August nicht leer ist.» Sie hat Angst, jemandem Nein sagen zu müssen, weil sie nicht wusste, dass die Woche schon voll war.

Die sekundäre Persona ist Marco aus dem HR, der heute jede Bewilligung von Hand in die Haupttabelle überträgt.

In dieser Serie sind Sandra und Marco Illustrationen. Bei einem echten Produkt wären sie das Ergebnis von Gesprächen mit einem Dutzend Teamleitenden und dem ganzen HR-Team.

User Journeys

Eine User Journey beschreibt, wie sich ein Nutzer durch einen Prozess, ein System oder ein Produkt bewegt. Sie kann das ganze Erlebnis abdecken oder nur einen Teil davon. Entscheidend ist die Sicht des Nutzers: was er bei jedem Schritt wahrnimmt, tut und fühlt.

Halte für jeden Schritt vier Dinge fest:

• Kontext: Wo ist der Nutzer? Was lenkt ihn ab?
• Fortschritt: Was muss er tun, um zum nächsten Schritt zu kommen?
• Gefühl: Ist er engagiert, gelangweilt oder genervt?
• Funktionalität: Was erwartet er vom Produkt? Ist das möglich? Was fehlt?

Markier ausserdem die Pain Points, die Momente, in denen der Nutzer aufgeben könnte.

Bleib auf einer groben Ebene und meistens beim Happy Path. Die Journey ist ein Kommunikationsmittel für Product Owner, Entwickler, Tester und Stakeholder, und sie hält die Sicht des Nutzers im Zentrum, wenn über Funktionen und Prioritäten diskutiert wird. Je vollständiger sie den Ablauf der Screens abdeckt, desto besser taugt sie als Grundlage für eine Story Map. Zusammen mit den Personas ist sie auch eine gute Basis für User Acceptance Tests.

Die Journey des Ferientools

So sieht die Journey eines Mitarbeiters aus Sandras Team aus, der eine Woche im August beantragt:

Schritt	Kontext	Gefühl	Funktionalität	Pain Point
1. Guthaben prüfen	Zu Hause, abends	Unsicher	Verbleibende Tage auf einen Blick	Heute: muss HR fragen
2. Team prüfen	Ebenda	Hoffnungsvoll	Wer in der Woche schon weg ist	Heute: keine Möglichkeit
3. Beantragen	Handy, Sofa	Neutral	Daten wählen, absenden
4. Warten	Am nächsten Tag bei der Arbeit	Ungeduldig	Status des Antrags	Heute: tagelang Stille
5. Entscheid erhalten	Irgendwo	Erleichtert, oder nicht	Benachrichtigung mit Begründung	Ein Nein ohne Grund
6. Reise planen	Buchungsseite	Glücklich	Abwesenheit erscheint im Teamkalender

Zwei der grössten Pain Points (Schritte 1 und 2) passieren, bevor überhaupt jemand etwas beantragt. Ein Tool, das nur das Antragsformular digitalisiert, würde beide verpassen.

Als Nächstes

Die Schritte der Journey werden zum Rückgrat einer Story Map. Nächstes Mal: Features, und wie eine Story Map aus einer Journey einen Release-Plan macht.