user-research
User Research
Know your users before you design for them. Assumptions are the enemy of good products.
Context
User research transforms market understanding into actionable user profiles. It can run in parallel with market-analysis but ideally uses market insights to focus the research scope.
When invoked immediately after problem-framing, the first responsibility is to turn the upstream open questions into a concrete research plan. Do not invent personas or "validated" findings before real user evidence exists.
Inputs
- intake-brief -- produced by the preceding skill in the lifecycle
- problem-frame -- produced by the preceding skill in the lifecycle
- market-research-report -- produced by the preceding skill in the lifecycle
Process
Step 1: Define Research Questions
Start from the upstream artifact before inventing new questions:
- if a
problem-frameexists, extract the target user hypothesis, non-goals, chosen direction, and open questions - if market analysis exists, use it to narrow which segments are worth validating first
- if neither exists, stop and request clearer discovery framing rather than guessing
Then define the research questions. Focus on behavior, not opinions:
- What workflows do users currently follow?
- Where do they experience friction?
- What tools do they currently use (and why)?
- What would make them switch to a new solution?
- Which upstream assumptions most need validation before requirements should start?
Step 2: Choose Research Methods
- Interviews (5-8 users): Deep qualitative understanding. Best for early discovery.
- Surveys (50+ responses): Quantitative validation. Best after interviews surface patterns.
- Observation: Watch users in their natural workflow. Reveals behavior they can't articulate.
- Analytics review: If existing product exists, mine usage data for behavioral patterns.
If no real-user evidence has been collected yet, produce a scoped research plan first:
- target segments to recruit
- key hypotheses or open questions to test
- method mix and sample size
- the evidence threshold required before moving to requirements
Step 3: Synthesize into Personas
Create 3-5 personas, each representing a distinct user segment:
- Name and role (make them memorable)
- Goals (what they're trying to achieve)
- Pain points (what frustrates them today)
- Behaviors (how they work, tools they use)
- Quote (a real or representative statement capturing their perspective)
Step 4: Map User Journeys
For each primary persona, map the journey through the problem space:
- Stages (awareness, consideration, adoption, retention)
- Actions at each stage
- Emotions and pain points
- Opportunities for your product to intervene
Step 5: Validate Personas
Test personas against real data. Can you match each persona to at least 2-3 real users? If not, refine.
If the research has not yet been executed, do not fake this step. Record that the quality gate is still open and hand off the research plan for execution.
Outputs
- research-plan -- The immediate planning artifact when the skill is invoked before evidence collection. It should name the target segments, hypotheses, methods, evidence threshold, and what question blocks downstream requirements.
- user-persona-set -- Evidence-backed personas produced only after research is actually run.
- user-journey-map -- Journey map produced only after research evidence is sufficient to describe the primary workflow credibly.
If only research-plan exists, the discovery work is better framed but the skill's full quality gate is still open. Do not pretend that planning alone equals validated research.
Quality Gate
- At least 3 distinct personas documented, or an explicit justification exists for fewer segments
- Each persona backed by real user data (not assumptions)
- User journey mapped for primary persona
- Pain points prioritized by frequency and severity
- Upstream discovery questions are either answered or explicitly carried forward
Anti-Patterns
- Designing for yourself -- You are not your user. Even if you're in the target market, your expertise makes you atypical.
- Too many personas -- More than 5 personas dilutes focus. Consolidate similar users.
- Demographic-only personas -- "25-35 year old male" is not a useful persona. Focus on goals and behaviors.
- One-time research -- User understanding should be continuously refined, not a one-time exercise.
- Inventing validated users from framing alone -- A problem frame can sharpen what to learn, but it is not evidence. If research has not been run, output a research plan and keep the quality gate open.
- Ignoring upstream non-goals -- Research should test the chosen direction and its boundaries, not silently reopen scope the framing step already ruled out.
Related Skills
- problem-framing -- shapes the problem and open questions before research starts
- market-analysis -- provides market context for targeting research
- requirements-engineering -- consumes personas and journey maps
- acceptance-criteria -- uses persona scenarios
Distribution
- Public install surface:
skills/.curated - Canonical authoring source:
skills/00-discovery/user-research/SKILL.md - This package is exported for
npx skills add/updatecompatibility. - Packaging stability:
beta - Capability readiness:
beta
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6