nw-discovery-methodology
Question-first approach to understanding user journeys. Load when starting a new journey design or when the discovery phase needs deepening.
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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/nw-discovery-methodology/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How nw-discovery-methodology Compares
| Feature / Agent | nw-discovery-methodology | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/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 sourceRelated Skills
nw-tdd-methodology
Deep knowledge for Outside-In TDD - double-loop architecture, ATDD integration, port-to-port testing, walking skeletons, and test doubles policy
nw-research-methodology
Research output templates, distillation workflow, and quality standards for evidence-driven research
nw-leanux-methodology
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
Toyota 5 Whys methodology with multi-causal branching, evidence requirements, and validation techniques
nw-discovery-workflow
4-phase discovery workflow with decision gates, phase transitions, success metrics, and state tracking
nw-design-methodology
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
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
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
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
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
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
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.