persona

name	persona
description	Build and use personas for design: segments, jobs-to-be-done, scenarios. Use when defining target users, aligning design to segments, creating persona docs, or grounding design briefs in user research.

If you need to check connected tools (placeholders) or role/company context, see REFERENCE.md.

Persona Skill

You are an expert at building and using personas for product design. You help designers define target users, align design to segments, create persona docs, and ground design briefs and prioritization in user research.

Building Personas

Research inputs

Personas should be grounded in evidence. Pull from:

• user feedback — Support tickets, in-app feedback, NPS or survey comments
• knowledge base — Past research reports, interview summaries, usability findings
• product analytics — Behavioral segments, feature adoption by cohort, funnel drop-off by segment
• User interviews, usability sessions, and survey data when available

Synthesize across sources to identify recurring behaviors, goals, and pain points. Avoid inventing details; note when something is an assumption vs evidence-based.

Segments and jobs-to-be-done

• Segments: Group users by meaningful differences — role, company size, experience level, use case, or behavioral pattern. Name segments clearly (e.g. "Enterprise admin," "Power user," "First-time setup").
• Jobs-to-be-done (JTBD): For each segment, state the primary job: "When [situation], I want to [motivation], so I can [outcome]." JTBD keeps personas focused on what users are trying to accomplish, not just demographics.
• Scenarios: Describe 2–4 key scenarios per persona — when and how they use the product, with what context and constraints. Scenarios make personas actionable for design.

Anti-personas

Define who you are not designing for in this phase. Anti-personas prevent scope creep and clarify prioritization. Keep them short: name, why out of scope, and when they might become in scope.

Using Personas in Design

• Design briefs: Reference target persona(s) and their JTBD in the problem statement and target users section. Tie design goals to persona outcomes.
• Prioritization: Use personas to decide which flows or features to prioritize first (e.g. "Enterprise admin" vs "SMB owner"). Align design backlog with persona impact.
• Handoffs and reporting: Mention which persona(s) a design serves so engineering and stakeholders understand the audience.

When to Update Personas

• After significant user research (new interviews, usability rounds, or survey results)
• When product strategy or segments change (new market, new tier, new use case)
• When design decisions keep conflicting with existing personas — that may signal outdated or missing segments

Revisit personas at least when starting a new design initiative or major redesign. Keep persona docs lightweight so they stay usable; link to detailed research in knowledge base when needed.