npx claudepluginhub nwave-ai/nwave --plugin nwThis skill uses the workspace's default tool permissions.
Use during Phase 1 (GATHER) when the user lacks clear personas or the "Who" section needs rigorous definition. Provides structured alternative to ad-hoc persona descriptions.
Use this skill when the user asks to "create user personas", "develop personas", "write a persona", "define our users", "user profile", "who is our user", "help me define the target user", "create a user archetype", or wants to build or update structured user persona definitions grounded in research or known user characteristics.
Generates user personas, journey maps, interview guides, usability tests, card sorts, and JTBD frameworks for building user understanding and product strategy.
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.
Share bugs, ideas, or general feedback.
Use during Phase 1 (GATHER) when the user lacks clear personas or the "Who" section needs rigorous definition. Provides structured alternative to ad-hoc persona descriptions.
For each user type, build a complete persona:
## Persona: {Name}
**Who**: {Role description -- one sentence capturing relationship to product}
**Demographics**:
- {Characteristic 1: e.g., technical proficiency level}
- {Characteristic 2: e.g., frequency of interaction}
- {Characteristic 3: e.g., environment/context of use}
- {Characteristic 4: e.g., primary motivation}
**Jobs-to-be-Done**: (see Job Step Table below)
**Pain Points**:
- {Pain 1} -- maps to Job Step: {step name}
- {Pain 2} -- maps to Job Step: {step name}
**Success Metrics**:
- {Quantified outcome 1: e.g., "Task completed in < 2 minutes"}
- {Quantified outcome 2: e.g., "Zero manual configuration steps"}
Each persona has job steps describing what they accomplish. Steps follow ODI format.
| Job Step | Goal | Desired Outcome |
|---|---|---|
| {Verb} | {What the user wants to achieve} | Minimize {metric} of {undesirable state} |
| Job Step | Goal | Desired Outcome |
|---|---|---|
| Discover | Find the right tool for the task | Minimize time to evaluate fit |
| Install | Get the tool running locally | Minimize steps to working state |
| Configure | Adapt to local environment | Minimize likelihood of misconfiguration |
| Verify | Confirm correct installation | Minimize uncertainty about readiness |
| Start | Begin productive work | Minimize time from install to first output |
Every pain point maps to a specific job step. Pain points without a corresponding step indicate either a missing step or irrelevant pain point.
Pain Point: "I don't know if the tool supports my OS"
-> Job Step: Discover
-> Desired Outcome: Minimize uncertainty about compatibility
Pain Point: "Installation fails silently with no error message"
-> Job Step: Install
-> Desired Outcome: Minimize time to diagnose installation failures
Prioritize: pain points on high-frequency job steps deserve attention first.
Every success metric needs a number or threshold. Qualitative metrics ("easy to use") are not actionable.
| Qualitative | Quantified |
|---|---|
| "Easy to install" | "Install completed in < 2 minutes with zero manual steps" |
| "Fast startup" | "First productive output within 30 seconds of launch" |
| "Reliable" | "Zero silent failures; all errors produce actionable messages" |
| "Intuitive" | "New user completes core task without reading documentation" |
Different users have fundamentally different jobs even when using the same product. Segment by relationship to the product.
Common axes: Frequency (first-time vs returning vs power user) | Role (end user vs admin vs developer) | Context (individual vs team vs CI/CD) | Motivation (exploration vs production vs evaluation)
| Persona | Primary Job | Key Difference |
|---|---|---|
| Explorer | Evaluate the tool quickly | Needs fast time-to-value, minimal commitment |
| Returner | Resume work after absence | Needs state preservation, quick re-orientation |
| Deployer | Install for a team | Needs configuration management, multi-user setup |
| Automator | Integrate into CI/CD pipeline | Needs scriptability, headless operation, exit codes |
Each persona gets their own Job Step table because workflows differ. Do not merge personas -- JTBD analysis value comes from surfacing differences.
After completing persona analysis, feed results into LeanUX user story template:
Cross-reference: use bdd-requirements skill for Example Mapping once personas established. Use jtbd-workflow-selection skill to determine workflow for resulting stories.