Design Discovery

Derive what to build from user goals. Goals → Scenarios → Requirements → Modes → Screens.

Two Modes

Mode 1: Discovery Session

Work through the process with the product owner. One phase at a time, conversational.

Activate: "Start design discovery for [project]"

Mode 2: User Interview

Autonomous conversation with a real user to gather design input. See references/user-interview.md — MANDATORY READ before any interview.

Activate: "Interview [name] as [role] for [project]"

First message requires human approval. Subsequent messages are autonomous.

NEVER Do These

• NEVER start with features or screens. If someone says "I need a settings screen," ask "what goal does that serve?" first.
• NEVER brainstorm requirements. Extract them from scenarios. Brainstormed requirements are fantasy; scenario-derived requirements are evidence.
• NEVER write user stories in Agile format ("As a user, I want..."). Write narrative scenarios in plain language. User stories are for dev tickets, not discovery.
• NEVER skip straight to wireframes. Modes come before screens. Screens come from modes. If you don't know the modes, your screens are guesses.
• NEVER use design jargon with interview subjects. No "pain points," "user flows," "information architecture." Talk like a human.
• NEVER accept "simple" or "intuitive" as requirements. Push back: "Simple for who? In what context? At what cognitive load?"
• NEVER treat the first answer as the real answer. First answers are surface-level. The expert insight is in the follow-up: "Tell me more about that." "What happens when that fails?"
• NEVER conflate the buyer and the user. A therapist buying the app has different goals than the patient using it. Map goals for EACH role.
• NEVER design for the average case only. The edge case (2am anxiety spike, low battery, public place) reveals the real requirements. Average-case design produces mediocre products.

The Process

Phase 0: Competitive Teardown

Before defining goals, understand what exists. For each competitor:

• Feature matrix — what they actually do
• App Store 1-star reviews — real pain points from real users (this is gold)
• What's bloated — features that add complexity without value (your "won't build" list)
• What's missing — gaps your user has already complained about
• Their actual user vs your actual user — same person or different?

Key insight: 1-star reviews are more valuable than the competitor's feature list. They tell you what to NOT do.

Store: Obsidian Projects/[Project Name]/Competitive Analysis.md

Phase 1: User Goals

Three levels, each shapes different decisions:

• Life goals → brand, emotional tone, long-term positioning
• Experience goals → interaction design, pacing, density
• End goals → features, screen structure, core loop

The trap: Teams fixate on end goals and build feature lists. Life and experience goals are WHERE THE DIFFERENTIATION LIVES. Two apps can have identical end goals but completely different experience goals — and feel like different products.

Output: Goal Statement: "The user wants to [end goal] in a way that feels [experience goal] so they can [life goal]."

Phase 2: Context Scenarios

Write narrative stories. Template: "[Name] is [context]. They [trigger]. They [action]. They [result]. They feel [emotion]."

Write scenarios for: daily use, first use, edge case (worst possible moment), return after absence, success (3 months in).

The expert move: Each scenario SIMULTANEOUSLY reveals requirements. Don't wait — capture them as they emerge. A scenario that says "she's on the subway with one hand free" just told you the app needs one-handed operation. That's not a feature request, it's physics.

Phase 3: Requirements Extraction

For each scenario ask:

• What does this moment DEMAND?
• What would RUIN this moment?
• What's the MINIMUM needed?

Categorize as Must / Should / Won't (v1). The "Won't" list is as important as the "Must" list — it's your scope defense.

Phase 4: Interaction Framework

Define modes, not screens. A mode is a state the user is in:

Map transitions between modes. THIS IS YOUR APP STRUCTURE. Screens derive from it — not the other way around.

The mistake everyone makes: Designing screens first, then trying to figure out how they connect. That's architecture without a blueprint. Modes first, always.

Phase 5: Screen Derivation

Now — and ONLY now — define screens. For each screen:

• Which scenario demands it?
• Which mode contains it?
• What's the ONE primary action?
• What can be removed and the scenario still works?

If a screen can't point to a scenario that needs it, kill it.

Phase 6: Design Principles & Experience

Derive 3-5 principles FROM the work above. Good principles:

• Are opinionated ("Speed over completeness" — the opposite is also reasonable)
• Create tension (choosing one thing means sacrificing another)
• Are testable (you can audit any screen against them)

See references/design-principles-examples.md for examples from Calm, Duolingo, Linear, Things, Headspace — READ when writing principles to calibrate quality.

Define experience: emotional tone, pace, density, what real-world object is this like, what this must NOT feel like.

Deliverable

Save to Obsidian Projects/[Project Name]/Design Discovery.md:

# Design Discovery: [Product Name]
## Competitive Landscape
## User Goals (with evidence)
## Context Scenarios (3-5 narratives)
## Requirements (extracted, categorized)
## Interaction Framework (modes + transitions)
## Screens (derived, with scenario justification)
## Design Principles (3-5 with rationale)
## Experience Definition
## User Research Notes (interview quotes, observations)

This feeds into: PRD → Architecture → UX Spec