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.