Stats
Actions
Tags
From grimoire
Builds 2-4 behavior-based persona profiles from user research synthesis, providing a shared evidence-grounded reference for design decisions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:design-user-personaThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Build 2–4 behavior-based persona profiles from research data to give the team a concrete, named representation of who they are designing for — and who they are not.
Build 2–4 behavior-based persona profiles from research data to give the team a concrete, named representation of who they are designing for — and who they are not.
Adopted by: Alan Cooper introduced the persona method at Apple in the 1980s; Microsoft adopted personas organization-wide in the early 2000s (documented in Pruitt & Adlin 2006); Google, IBM, and Amazon all use persona-based design as the standard for aligning cross-functional teams on user needs; IDEO's HCD process includes persona creation as a core synthesis artifact Impact: Cooper (1999) documented that teams without personas consistently design for edge cases and hypothetical "elastic users" — leading to features that satisfy no one; Pruitt & Adlin (2006) studied Microsoft teams and found persona adoption correlated with fewer late-stage design reversals and reduced cross-team disagreements about target user needs; NNG reports that teams with research-grounded personas ship 20% fewer features that users consistently don't use Why best: Demographic profiles ("male, 25–40, tech-savvy") describe who users are but not what they need; ad-hoc user stories describe tasks but not goals or context; behavior-based personas synthesize both into a single artifact that teams can reference in any product decision — "would Maya do this?" is a faster, more consistent decision filter than re-running the research
Sources: Cooper "The Inmates Are Running the Asylum" (SAMS, 1999) Ch. 9; Pruitt & Adlin "The Persona Lifecycle" (Morgan Kaufmann, 2006); NNG "Personas Make Users Memorable for Product Team Members" (Harley, 2015)
From research synthesis, identify 2–4 distinct behavioral patterns across participants. Behavioral patterns are defined by what participants do and why — not by age, gender, or job title.
Look for variation in:
Example: a project management tool might find two distinct patterns — "coordinator" (tracks others' work, high communication frequency, frustrated by status-request overhead) and "executor" (works head-down on assigned tasks, low collaboration need, frustrated by interruptions). Same product, different behavioral clusters.
Do not create personas by:
For each behavioral cluster:
Name: Maya Chen
Photo: [stock photo matching the persona's context — not a headshot of a real participant]
Tagline: "I need to know the status of everything without having to ask."
Role/context: Operations coordinator at a 50-person logistics company
Experience level: Moderate technical proficiency; heavy spreadsheet user
The name and photo are memory aids — they make the persona easier to reference in conversation than "user type 2". The name should be culturally plausible for the demographic the research surfaced, not aspirational or generic.
Primary goal — the underlying outcome the persona is trying to achieve, beyond the immediate task:
Goal: Know her team's status at any moment without chasing people for updates
Secondary goals — supporting outcomes:
Secondary: Keep her manager informed without spending time preparing status reports
Top frustrations — specific pain points grounded in research observations:
Frustrations:
- Spends 30+ min/day asking teammates for status updates via Slack
- Status information lives in 3 different tools with no single view
- Teammates mark tasks "done" before they're actually complete
Frustrations must be grounded in specific research observations — not invented to make the persona more sympathetic.
One direct quote from research (or a composite of similar quotes) that captures the persona's core tension:
"I have a spreadsheet that I update manually every morning because I don't trust the system to be current."
The quote should be something a real participant said (or closely paraphrased). It anchors the persona in evidence and gives the team language to reference.
List 3–5 tasks the persona performs that are in scope for the product:
Key tasks:
1. Checks project status first thing each morning
2. Assembles a weekly status report for her manager
3. Escalates blocked tasks to the project owner
4. Onboards new team members to the project workflow
Include context: device, environment, time pressure, collaboration patterns.
For each persona, write one sentence about who they are NOT — to prevent the team from designing for everyone simultaneously:
Maya is NOT the project owner making strategic decisions about scope — that's Persona 2 (Amir).
Maya is NOT a solo freelancer with no team to coordinate.
This boundary is as important as the persona definition itself. Without it, teams expand personas to include edge cases until they become meaningless.
Before publishing, check each persona against the raw data:
Flag invented attributes as assumptions to be validated in future research.
A persona that lives in a Confluence page no one reads is not being used. Make it visible:
npx claudepluginhub jeffreytse/grimoire --plugin grimoireCreate refined user personas from research data with demographics, goals, frustrations, and behavioral patterns. Use when synthesizing user research into actionable persona profiles for design decisions.
Generates user personas through conversational ideation, brainstorming, and exploration for design research, challenging assumptions and creating user stories.
Generates behavioral user personas from product descriptions, user data, or research notes. Outputs 2-4 ranked personas with goals, pain points, behaviors, and product implications to personas-[product].md.