nw-discovery-methodology

Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.

322 stars

Best use case

nw-discovery-methodology is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.

Teams using nw-discovery-methodology should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/nw-discovery-methodology/SKILL.md --create-dirs "https://raw.githubusercontent.com/nWave-ai/nWave/main/nWave/skills/nw-discovery-methodology/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/nw-discovery-methodology/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How nw-discovery-methodology Compares

Feature / Agentnw-discovery-methodologyStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Discovery Methodology

Discover journeys through deep questioning before any sketching. The sketch is proof of understanding, not the starting point.

## Session Flow

### Phase 1: Goal Discovery (First 5-10 minutes)
Focus: What is the user trying to accomplish?

Questions:
- "What's the ultimate goal you're trying to achieve?"
- "What triggers this journey? When does a user start this?"
- "How will you know when you've succeeded?"
- "What's the happy path in your mind?"

#### Draft Sketch (after first 3 answers)

After collecting goal, trigger, and success criteria, output a rough draft sketch showing what the journey might look like. Mark unknowns with `???`. Purpose: make value visible immediately so the user sees progress, not just questions.

```
[Trigger: ???] → [Step 1: ???] → [Step 2: ???] → [Goal: {stated goal}]
  Feels: ???       Sees: ???       Sees: ???       Feels: {success criteria}
  Artifacts: ???   Artifacts: ???  Artifacts: ???
```

This is a working hypothesis, not a commitment. Update it after each phase as understanding deepens. The sketch gives the user something concrete to react to — "no, step 2 happens before step 1" is more productive than abstract discussion.

### Phase 2: Mental Model (10-20 minutes)
Focus: What does the user EXPECT to see?

Questions:
- "Walk me through step by step -- what do you type, what do you see?"
- "At this step, what information appears on screen?"
- "What would you need to see to feel confident?"
- "Where do you think this data comes from?"
- "What's your mental model of how this works?"

### Phase 3: Emotional Journey (5-10 minutes)
Focus: How should the user FEEL?

Questions:
- "How should you feel at the start? Anxious? Curious? Confident?"
- "What's the emotional arc -- where's the peak tension?"
- "How should you feel when it's done?"
- "Where might you feel frustrated or lost?"
- "What would make this feel satisfying vs frustrating?"

### Phase 4: Shared Artifacts (5-10 minutes)
Focus: What data is shared across steps?

Questions:
- "What information appears in multiple places?"
- "Where does the version number come from? Where is it shown?"
- "If this path changes, what else breaks?"
- "Who owns this piece of data?"
- "What paths or URLs are reused across steps?"

### Phase 5: Error Paths (5 minutes)
Focus: What could go wrong?

Questions:
- "What's the most likely failure?"
- "What should the user see when it fails?"
- "How does the user recover?"
- "What would a helpful error message look like?"

### Phase 6: Integration Points
Focus: How do steps connect?

Questions:
- "What did the previous step produce that this step needs?"
- "What does this step produce that the next step needs?"
- "Are there any hidden dependencies between steps?"
- "What external systems or files does this touch?"

### Phase 7: CLI UX Specifics
Focus: What commands and output does the user expect?

Questions:
- "What command would you naturally type for this?"
- "What flags or options do you expect?"
- "How verbose should the output be by default?"
- "Should there be a --dry-run option?"

## Question Format

Use AskUserQuestion with structured options:
- 2-4 concrete options based on design methodology
- Options represent real design alternatives
- Include an "Other" option for open-ended input
- Each option includes its design implication

## Sketch Readiness Criteria

Ready to sketch ONLY when all can be answered:
- Complete happy path described (no "and then something happens")
- Each step has expected output defined
- Emotional arc is explicit and coherent
- Shared artifacts identified with sources
- At least major error paths acknowledged

If ANY criterion is unclear -- ask more questions.

## When to Question

Always ask first when:
- User requests a sketch -- ask before sketching
- User describes a feature -- ask to understand journey context
- User mentions a command -- ask what they expect to see

Continue asking until:
- User can describe complete happy path without gaps
- All shared artifacts identified with sources
- Emotional arc is explicit and coherent
- Error paths are at least acknowledged

## Anti-Patterns

- Jumping to sketching before understanding mental model
- Assuming you know what the user expects
- Filling gaps with your own assumptions
- Skipping emotional journey questions
- Ignoring shared artifact tracking

Instead:
- Ask one more question when uncertain
- Reflect back understanding for user validation
- Make the user articulate their mental model explicitly
- Map emotional states at every step
- Document every ${variable} and its source

Related Skills

nw-tdd-methodology

322
from nWave-ai/nWave

Deep knowledge for Outside-In TDD - double-loop architecture, ATDD integration, port-to-port testing, walking skeletons, and test doubles policy

nw-research-methodology

322
from nWave-ai/nWave

Research output templates, distillation workflow, and quality standards for evidence-driven research

nw-leanux-methodology

322
from nWave-ai/nWave

LeanUX backlog management methodology - user story template, story sizing, story states, task types, Definition of Ready/Done, anti-pattern detection and remediation

nw-five-whys-methodology

322
from nWave-ai/nWave

Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques

nw-discovery-workflow

322
from nWave-ai/nWave

4-phase discovery workflow with decision gates, phase transitions, success metrics, and state tracking

nw-design-methodology

322
from nWave-ai/nWave

Apple LeanUX++ design workflow, journey schema, emotional arc patterns, and CLI UX patterns. Load when transitioning from discovery to visualization or when designing journey artifacts.

nw-bdd-methodology

322
from nWave-ai/nWave

BDD patterns for acceptance test design - Given-When-Then structure, scenario writing rules, pytest-bdd implementation, anti-patterns, and living documentation

nw-ux-web-patterns

322
from nWave-ai/nWave

Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.

nw-ux-tui-patterns

322
from nWave-ai/nWave

Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.

nw-ux-principles

322
from nWave-ai/nWave

Core UX principles for product owners. Load when evaluating interface designs, writing acceptance criteria with UX requirements, or reviewing wireframes and mockups.

nw-ux-emotional-design

322
from nWave-ai/nWave

Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.

nw-ux-desktop-patterns

322
from nWave-ai/nWave

Desktop application UI patterns for product owners. Load when designing native or cross-platform desktop applications, writing desktop-specific acceptance criteria, or evaluating panel layouts and keyboard workflows.