Defining Persona and Problem Statement
Identify target users and articulate the core need.
Step 1: Gather Insights from Research
Personas need evidence. Run 5–8 semi-structured interviews when possible, or for practice synthesize desk research, forum comments, and 3–4 realistic profiles into a proto-persona you plan to validate later.
Ask about recent behavior, not opinions only: "Tell me about the last time you missed a deadline — what happened?" After each session, extract single insights as notes: pains, goals, behaviors, and quotes.
Step 2: Build the Persona
A persona is a fictional character grounded in repeated research patterns — not a random invented user. One primary persona is enough for an MVP. Include name, role, short bio, three goals, three frustrations, tech comfort, and a representative quote.
Goals should be outcome-oriented: "See all deadlines this week in one view" beats "Use an app." Add an anti-persona — who you are not designing for — to prevent scope creep from stakeholder requests outside your target segment.
Step 3: Problem Statement and HMW
Write the problem in this format: "[User] needs [need] because [insight]." Example: "Alex needs centralized visibility on weekly deadlines because dates scattered across chat and spreadsheets get missed without a single reminder hub."
Avoid naming solutions in the problem statement. Turn it into one or two How Might We questions for ideation: "How might we give Alex weekly deadline visibility without complex setup?" Prioritize problems by impact times frequency.
Step 4: Validate Assumptions
List assumptions your persona relies on — for example, that users check mobile notifications daily. Mark each as validated, partially validated, or untested.
Plan lightweight checks: five more interview questions, a survey, or analytics if a product exists. Update the persona when evidence contradicts it; stale personas mislead design decisions.
Step 5: Share with the Team
Keep the persona to one page — PDF or a Figma frame. Use it in kickoffs and reviews: "Would Alex understand this label?" or "Does this solve the stated need?"
Pair persona with the problem statement on the same slide or wall board. Alignment on who and why comes before wireframes and visual design.
FAQ
How many personas do I need?
One primary persona covers most MVPs. Add a secondary persona only when another segment is distinct and critical to product success — for example, admin vs end user.
Can I create a persona without interviews?
You can draft a proto-persona from secondary research for learning, but label assumptions clearly and validate with real users before major build investment.
What makes a good problem statement?
It names a real user need and insight without prescribing a feature. If your statement already says "needs an app," rewrite it to describe the underlying job to be done.