Was vorher fertig sein muss
Mindestens 10-15 strukturierte Interviews oder qualitative Beobachtungen aus der Zielgruppe liegen vor, aus denen Muster ableitbar sind.
Demografische, behavioral oder Funnel-Daten aus Analytics, CRM oder Surveys ergänzen die qualitativen Erkenntnisse, sodass Segment-Größen abschätzbar sind.
Was vor Start vorliegen muss
Affinity-Mapping-Board (Miro, FigJam) für Research-Synthese; Persona-Template mit Feldern (Name, Foto, Demografie, Ziele, Pains, Verhalten, Kontext, Zitate); ggf. Quant-Datenexport (Analytics, CRM).
Ein UX-Researcher als Owner; ein bis drei Researcher mit direktem Interview-Kontext; Product Manager für Segment-Priorisierung; ein bis zwei Designer für Persona-Format und Bilder.
Interview-Notizen oder transkribierte Highlights; Demografie-Quant-Daten; bekannte interne Persona-Versuche und ihre Schwächen; Persona-Zweck (Design-Entscheidungen vs. Marketing-Messaging vs. Strategie).
1-3 Tage (Synthese 1 Tag, Persona-Bau 1 Tag, Validierung 0,5-1 Tag)
Research-Highlights als Stickies auf Affinity-Board sammeln. Clustern in Verhaltens-Muster. Persona-Template festlegen (was muss drauf, was wegfallen). Persona-Zweck explizit klären (Design vs. Marketing).
Die eine Frage, die diese Methode beantwortet
Welche unterscheidbaren Nutzergruppen mit verschiedenen Bedürfnissen, Zielen und Verhaltensweisen lassen sich aus der Forschung ableiten, und welche treiben Design-Entscheidungen?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Research synthetisieren | 4-8 h | Interview-Highlights auf Stickies. Affinity-Mapping: Clustern nach ähnlichem Verhalten, Zielen, Pain Points. 3-5 Cluster identifizieren (mehr ist meist überfaktorisiert). | Wer nach Demografie clustert (Alter, Geschlecht), bekommt schwache Personas. Verhalten und Ziele sind die richtigen Achsen. |
2Phase 2: Persona-Profile entwerfen | 3-5 h | Pro Cluster ein Persona-Profil: Name (fiktiv, aber prägnant), Foto, kurze Kontext-Story, Goals (3-5), Pain Points (3-5), Verhalten, typische Zitate. Realistische Details aus Interviews. | Stock-Photo-Personas ohne Substanz werden ignoriert. Konkrete Zitate und Verhalten machen Personas nutzbar. |
3Phase 3: Quant-Validierung | 2-4 h | Quant-Daten gegen Personas prüfen: Wie groß ist jedes Segment? Wie verteilen sich die Behaviorals? Wenn Daten widersprechen, Personas anpassen. | Personas ohne Quant-Anchor schweben. Wenn Persona X für 1% der Nutzerbasis steht, sollte das Team das wissen, bevor sie zu treibend wird. |
4Phase 4: Stakeholder-Validierung | 1-2 h | Personas mit Stakeholdern (Sales, Support, Service) abgleichen. Wer hat regelmäßigen Kundenkontakt? Stimmen Personas mit deren Erfahrung überein? | Sales und Support sehen oft andere Personas als Research-Team. Wenn signifikante Diskrepanz, Research-Lücke prüfen oder Personas verfeinern. |
5Phase 5: Aktivierung im Team | 1-2 h | Personas im Team verteilen, in Designräumen aushängen, in Backlog-Templates referenzieren. Pro Persona einen Champion benennen, der Entscheidungen aus deren Sicht challengt. | Personas im Schubladenschrank haben keinen Effekt. Sichtbarkeit und aktive Nutzung sind die Hebel. |
Was am Ende rauskommt
Set von 3-5 Persona-Profilen als 1-Seiten-Dokumente (PDF, Miro-Board, Notion-Seite) mit Foto, Demografie, Kontext, Goals, Pain Points, Verhalten, Zitaten und Segment-Größe, plus Anleitung zur Persona-Nutzung im Team.
Personas jährlich auf Aktualität prüfen (Markt ändert sich). Bei größeren Research-Runden neue Version mit Datum. Veraltete Personas explizit als „archiviert“ markieren, nicht löschen (Historie wertvoll).
Kompakte Arbeitsvorlage für Personas mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Personas Arbeitsvorlage
## Ziel
Evidenzbasierte Archetypen unterschiedlicher Nutzergruppen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Persona Profiles:
- Needs Summary:
- Scenario Notes:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Persona-Set: methodatlas-Nutzer (v1, 2026-05-18, n=18 Interviews)
### Persona 1: „Sabine, die Generalistin“ (~45% Segment)
**Kontext**: Senior Product Manager, 8 J Berufserfahrung, mittelgroßes Unternehmen, leitet Produkt-Triad
**Goals**: Schnellen Methodenüberblick für anstehende Workshops; Vergleich von Methoden für ähnliche Probleme
**Pain Points**: Bestehende Methodenseiten zu generisch; keine Praxis-Anleitung; keine Negativ-Hinweise wann eine Methode nicht passt
**Verhalten**: Sucht Methoden am Sonntag-Abend vor Montag-Workshops; bookmarkt 3-5 Seiten; pickt einzelne Stellen heraus
**Zitat**: „Ich brauche keine Theorie, ich brauche den Trick, wie man das in 45 Minuten durchzieht.“
**Segment-Größe**: ~45% der Erstbesuche (Analytics)
### Persona 2: „Marcus, der Lernende“ (~30% Segment)
**Kontext**: Berufseinsteiger als PM oder UX, 1-3 J Erfahrung, sucht Struktur und Grundverständnis
**Goals**: Methodenüberblick als Curriculum; Verstehen wann welche Methode
**Pain Points**: Methodennamen kennt er, Anwendung unklar; Angst vor falscher Wahl
**Verhalten**: Liest sequentiell, schaut auch verwandte Methoden, längere Sessions
**Zitat**: „Ich will erst verstehen, was die Unterschiede zwischen User Story Mapping und Event Storming sind.“
**Segment-Größe**: ~30% (geschätzt aus Session-Length-Buckets)
### Persona 3: „Lena, die Coach“ (~15% Segment)
**Kontext**: Externe Beraterin oder interne Coach, 10+ J Erfahrung, baut Methoden-Sets für Kunden zusammen
**Goals**: Methoden-Set für ein konkretes Kundenproblem zusammenstellen; Quellenangaben für Pitches
**Pain Points**: Source Links oft schwach; keine kuratierten Pakete; Tags nicht praktisch genug
**Verhalten**: Filtert nach Tags, kopiert Listen, teilt Links
**Zitat**: „Wenn ich für einen Kunden ein Discovery-Programm baue, brauche ich 5 Methoden mit klaren Quellen.“
**Segment-Größe**: ~15% (höhere Wiederkehr-Rate)
### Persona 4: „Ben, der CTO-Allrounder“ (~10% Segment)
**Kontext**: CTO im Startup, 50-150 MA, sucht Architektur- und Produktmethoden parallel
**Goals**: Schnelle Methodenwahl für gemischte Probleme; Cross-Domain-Mapping
**Pain Points**: Methoden meist in Silos; keine Cross-Empfehlungen Produkt/Architektur
**Segment-Größe**: ~10% (kleine, aber sehr wiederkehrende Gruppe)Symptome erkennen, gegensteuern
Personas unterscheiden sich nach Alter, Geschlecht, Wohnort, nicht nach Verhalten und Zielen.
Achsen wechseln auf Goals, Pain Points, Nutzungs-Verhalten. Demografie als Hintergrund, nicht als Differenzierungsmerkmal.
8+ Personas mit kleinen Unterschieden, Team kann sich nicht erinnern wer wer ist.
Auf 3-5 Personas verdichten. Wenn mehr nötig, sind es eher Sub-Personas oder das Segment ist zu heterogen für ein Persona-Set.
Personas entstehen in Stakeholder-Workshop, ohne Interview-Daten.
Personas aus Research synthetisieren, nicht in Sprint-Planning erfinden. Ohne Datenbasis ist Persona Marketing-Schmuck.
Personas einmal erstellt, dann nie wieder verwendet oder aktualisiert.
Personas sichtbar im Designraum aushängen, in Sprint-Refinement referenzieren, jährlich refreshen. Sonst sind sie Deko.
Niemand verteidigt die Sicht einzelner Personas in Entscheidungen, sie verschwinden im Konsens.
Pro Persona einen Owner benennen, der in Diskussionen die Persona-Sicht einbringt. Persona ohne Stimme ist nutzlos.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.