---
name: ux-personas
description: Create detailed, research-based UX personas for product and experience design. Use this skill whenever a user wants to create, improve, or critique personas — including requests like "help me define our users", "create a persona for X", "build user profiles for our product", "we need to define our target audience", or "turn our research into personas". Also trigger when a user shares user research, interview notes, survey data, or user segments and wants to turn that into design-ready personas. Always use this skill before attempting to write any persona content from scratch.
---

# UX Persona Creation

Personas are fictional but realistic descriptions of typical or target users. They synthesize research data into a single, memorable character — making abstract user groups feel concrete and actionable for the whole product team.

---

## When You're Asked to Create Personas

Follow this process:

### 1. Establish the research foundation

Ask the user what research they have available. Personas must be grounded in real data — not assumptions. Accepted inputs:

- Interview notes or transcripts
- Survey results
- Field study observations
- Analytics segments
- Existing user segments or market research

If no research exists, flag this clearly: **a persona built without research is a assumption document, not a persona.** Offer to help design a lightweight research plan, or proceed with clearly labeled "proto-personas" that should be validated.

### 2. Identify user clusters

From the research, group users by shared:
- Behaviors and usage patterns
- Goals and motivations
- Frustrations and pain points
- Context of use (when, where, how often, on what device)

If clusters are too similar, merge them. If a cluster seems peripheral to the product, consider dropping it. Aim for **2–4 personas** for most products — enough to cover meaningful variation without diluting focus.

### 3. Build each persona

Each persona should include:

**Required (core to memorability and empathy):**
- **Name** — fictional but believable, not generic ("Anna", not "User A")
- **Photo** — describe one if you can't provide one (stock photo type, not a real person)
- **Age, location, occupation** — enough to anchor context
- **Tag line** — one punchy sentence capturing their essence. Keep it grounded, not clever.
- **Goals** — what are they ultimately trying to achieve? (2–3 items)
- **Frustrations / pain points** — what currently gets in their way? (2–3 items)
- **Behaviors** — how do they currently solve the problem? What tools, workarounds, habits?
- **Context of use** — how would they interact with your product? Required by job or by choice? How often? What device?
- **A quote** — one direct-voice sentence that captures their attitude toward the problem space

**Optional (include only if design-relevant):**
- Experience level with similar products
- Tech comfort level
- Key tasks they need to accomplish in the product
- Decision-making style

**Never include** details that don't affect design decisions. If a field doesn't make any design choice easier, cut it.

### 4. Apply the relevance test

Before finalizing any detail, ask: *"Would this change a design decision?"*

- If yes → include it
- If no → cut it

A persona's favorite coffee order is noise. Their preferred device and time of day for using the product is signal.

---

## Output Format

Present each persona as a structured profile. Use this layout:

```
## [Name], [Age]
[Occupation] · [Location]

> "[Their defining quote]"

**[Tag line]**

### Goals
- ...
- ...

### Frustrations
- ...
- ...

### Behaviors
- ...
- ...

### Context of use
[1–2 sentences on how, when, and where they'd use the product]
```

---

## Common Mistakes to Avoid

| Mistake | Fix |
|---|---|
| Building personas from assumptions, not research | Ground every trait in observed data |
| Too many personas | 2–4 is almost always enough |
| Including irrelevant details | Apply the relevance test to every field |
| Making the tag line too witty | It should be useful, not entertaining |
| Treating personas as a one-time deliverable | Revisit them as you learn more |
| Designing only for the primary persona | Secondary personas represent real edge cases |

---

## Using Personas Beyond the Design Phase

Once created, personas have several ongoing uses:

- **Expert reviews** — walk through a task flow as each persona to surface issues
- **Usability study recruiting** — use persona traits as screening criteria
- **Stakeholder alignment** — give teams a shared vocabulary ("Would Rosa actually do this?")
- **Analytics segmentation** — map real user segments to persona profiles to validate and refine
- **Agency/consultant briefs** — describe your audience concisely without exposing raw data

---

## Persona Quality Checklist

Before delivering personas to the user, verify:

- [ ] Each persona is grounded in real research (or clearly labeled as proto-persona)
- [ ] Name and photo aid memorability
- [ ] Goals and frustrations reflect user research, not product team assumptions
- [ ] Every included detail passes the relevance test
- [ ] Tag line is clear and useful, not just clever
- [ ] Personas feel like distinct characters, not slight variations of each other
- [ ] 2–4 personas total (flag if more are requested and explain the tradeoff)