Trigger conditions (when to apply)
- Apply when the request is to organize "persona," "assumed user," "target," "JTBD," "problem hypothesis," or "usage scenario."
doc/input/rdd.mdApply with priority when the "assumed user image" or "use cases" of are undetermined/ambiguous.
Basic policy of this Skill (organizing axes)
- Basic policy: A persona is not "character creation" but a "hypothesis model" for design decisions.
- Evidence-first: Do not assert based on guesswork. Write facts (observations/existing logs/interviews/competitors) and hypotheses separately.
- Operability: Make it something that can be verified and updated, not just created and left alone.
Philosophy (judgment rules)
- A persona is a "representative example," not "everyone." Clarify the extent to which it represents.
- Center on behavior, goals, and constraints (time/budget/skills/environment). Keep attributes (age, etc.) to the necessary minimum.
- Always include competitors and alternative behaviors (how they currently solve it).
- Hold both "pain" and "value" at the same time (what troubles them, what pleases them).
- Reduce to verifiable hypotheses (in a form that determines the next research to take).
Approach (questions to confirm first)
- Who uses it? (Is separation of user/buyer/administrator necessary?)
- What do they want to achieve? (Goal/JTBD)
- What constraints are there? (Time/frequency/environment/device/permissions)
- What are the current alternatives? (Competitors/manual work/Excel, etc.)
- How are success/failure judged? (KPI/experience/operations)
Output format (must be in this order)
- Premises (facts/hypotheses/unknowns)
- Persona candidates (1–3 people)
- Each persona's "goal/situation/constraints/alternatives/pain/value"
- Priority (which to prioritize in the MVP)
- Validation plan (what to ask/see/measure next)
Common pitfalls
- Created only from attributes, unusable for design decisions
- Depicts only the "ideal user," leaving out real-world constraints
- Hypotheses and facts are mixed, making verification impossible