User Modeling
Build just enough understanding of your users to make better product decisions.
Why This Exists
Creates behavior-based user models that reveal what users need and how they'll behave, not marketing personas with stock photos.
Input Requirements
This skill works best with:
-
problem-framing output (problem statement, target user, JTBD)
-
Any existing research (interviews, surveys, support tickets, Reddit threads, reviews)
Can also work from assumptions if no research exists—but flags that these need validation.
Workflow
Step 1: Gather Context
Ingest upstream artifacts or ask:
-
Who are you building this for?
-
What do you know about them already?
-
Have you talked to any potential users?
-
Any data sources—reviews, forums, support tickets?
Step 2: Identify User Segments
Look for meaningful differences in:
-
Goals — What are they trying to accomplish?
-
Context — When/where do they encounter the problem?
-
Constraints — What limits their options?
-
Skill level — How sophisticated are they?
-
Frequency — How often do they face this problem?
Not every difference matters. Focus on differences that change what you'd build.
Step 3: Build Personas
For each meaningful segment, create a lightweight persona. Limit to 2-3 personas max—more than that dilutes focus.
Step 4: Define Scenarios
For each persona, define 2-3 concrete scenarios where they'd use the product. These become the basis for user stories and flows.
Step 5: Identify Insights
Surface patterns that inform product decisions:
-
What do all personas have in common?
-
Where do they diverge?
-
What would you build differently for each?
Automatically save the output to design/02-user-modeling.md using the Write tool while presenting it to the user.
Output Format
User Modeling: [Project Name]
Context
[Brief summary of the problem space and what we know]
Research basis:
- [Source 1: what it told us]
- [Source 2: what it told us]
- [Or: "Based on assumptions—needs validation"]
Personas
Persona 1: [Name/Label]
[One-line description of who they are]
Goals:
- [Primary goal]
- [Secondary goal]
Context:
- [When they encounter the problem]
- [Where they encounter it]
- [What else is going on]
Pain points:
- [Frustration 1]
- [Frustration 2]
Current behavior:
- [How they solve this today]
- [Tools they use]
- [Workarounds they've developed]
Constraints:
- [Time/budget/skill/access limitations]
What success looks like:
- [How they'd know the problem is solved]
Quote: "[Something they might say that captures their mindset]"
Persona 2: [Name/Label]
[One-line description]
[Same structure]
Persona 3: [Name/Label]
[One-line description]
[Same structure]
Scenarios
Persona 1 Scenarios
Scenario 1.1: [Name]
- Situation: [Context—what's happening]
- Trigger: [What prompts them to act]
- Goal: [What they're trying to accomplish]
- Current approach: [How they handle it today]
- Frustration: [What's broken about current approach]
Scenario 1.2: [Name] [Same structure]
Persona 2 Scenarios
Scenario 2.1: [Name] [Same structure]
Key Insights
Commonalities
[What all personas share—these are table-stakes features]
- [Insight 1]
- [Insight 2]
Divergences
[Where personas differ—these inform prioritization]
- [Persona 1] needs [X], while [Persona 2] needs [Y]
- [Persona 1] is [context], while [Persona 2] is [different context]
Design Implications
[How this should influence what you build]
- [Implication 1]
- [Implication 2]
- [Implication 3]
Validation Needed
[What assumptions need testing]
- [Assumption to validate]
- [Assumption to validate]
Adaptation Guidelines
Minimal (single obvious user type):
-
One persona, 2-3 scenarios
-
Skip Divergences section
-
1 page total
Standard (2-3 user types):
-
Full structure as shown
-
2-3 pages total
Research-heavy (actual user data):
-
Include research summary
-
Add quotes from real users
-
Link to source data in appendix
What Makes a Good Persona
Good persona:
-
Defined by goals and behaviors, not demographics
-
Reveals something that changes what you'd build
-
Based on patterns, not individuals
-
Specific enough to make decisions against
Bad persona:
-
Stock photo + age + job title + hobbies
-
So generic it could be anyone
-
Based on one interview or pure assumption
-
Doesn't inform any product decisions
Anti-Patterns to Avoid
-
The Kitchen Sink — Don't add demographics unless they matter
-
The Clone Army — If personas don't differ meaningfully, merge them
-
The Wishful Thinker — Model who users are, not who you wish they were
-
The Edge Case Collector — Focus on primary users, not every possible user
Handoff
After presenting the personas, ask:
"Want to move to /solution-scoping to prioritize features, or straight to /prd-generation ?"
Note: File is automatically saved to design/02-user-modeling.md for context preservation.