---
name: design-discovery
description: You MUST use this before any creative or design work — building features, creating components, designing interfaces, modifying user-facing behaviour. Explores intent, constraints, users, and context before any design decisions are made
---

# Design Discovery

Discovery is where design begins. Before pixels, before wireframes, before any visual decisions — understand the problem. This skill ensures you never design the wrong thing well.

## Welcome Gate

**BEFORE running discovery, check whether the Designpowers welcome sequence has been shown this session.** If the user has not yet seen the welcome (the bird, the greeting, and the walkthrough offer), you MUST invoke the `using-designpowers` skill FIRST and complete the welcome sequence before returning here. The bird must appear before any work begins. No exceptions.

## The Rule

DO NOT proceed to any design, UI, or implementation work until discovery is complete and the user has approved the design brief.

## Discovery Modes

### Quick Discovery (for POCs and small tasks)
When the user says "proof of concept", "POC", "quick", "small", or the task is clearly exploratory:

1. Keep it light. Ask a few essentials in a conversational way — not as a numbered checklist:
   > "Quick version: what's the problem, who's it for, and what does success feel like? If you've got a design system or any references you love, throw those in too."
2. Write the brief immediately from their answers — don't ask follow-up rounds
3. Present the brief for approval in one block (not section by section)
4. **Create `design-state.md`** in the project root immediately after brief approval

Quick discovery should take **one user message** of answers, not three. But the question should still feel like a person asking, not a form.

### Full Discovery (for products and complex tasks)
When the task is a full product, involves multiple stakeholders, or the user explicitly wants depth — use the full process below.

## Process

### Step 1: Understand the Context

Before asking questions, gather what already exists:
- Read any existing design documents, specs, or briefs in the project
- Check for an existing design system, component library, or style guide
- Look at the current state of what the user is working on
- Identify the platform, tech stack, and any constraints

### Step 2: Explore Intent

Have a conversation, not an interrogation. The goal is to understand what the user wants to build and why — but the tone should feel like two people talking, not a form being filled out.

**Start with an open invitation**, not a structured question:
> "Tell me about what you're building. What's the story behind it?"

Let the user talk. Listen for the answers to these questions in what they say, and only ask follow-ups for what's missing:

1. **What problem are we solving?** Not what feature are we building — what human problem does this address?
2. **Who experiences this problem?** Not "users" — which specific people, in what situations, with what abilities and constraints?
3. **What does success look like?** How will we know this design works? What changes for the person using it?
4. **What constraints exist?** Technical, timeline, brand, accessibility requirements, regulatory
5. **What has been tried before?** What worked, what failed, what was learned

**Ask follow-ups ONE AT A TIME.** Don't list all missing items at once. Pick the most important gap, ask about it conversationally, and repeat. Frame questions around what they've already told you:
- Instead of "What are your constraints?" → "You mentioned it needs to work on mobile — any other constraints I should know about?"
- Instead of "Who are the users?" → "You said it's for busy parents — tell me more about their typical day when they'd use this."

**Weave in taste seeds naturally.** Don't make these a separate section — fold them into the conversation when the moment feels right:
- "Do you have a design system or style guide we should work within?"
- "Any products or experiences you admire that have the feel you're going for?"
- "How should this *feel* to use? (calm, playful, premium, effortless — whatever comes to mind)"

These are lightweight prompts, not the full taste calibration — that comes later via `design-taste`. But getting the user thinking about feel early means they arrive at taste calibration with sharper instincts. If they share a design system here, note it in the brief for the taste skill to pick up.

**Acknowledge what they tell you.** Before asking the next question, briefly reflect back what you heard. This shows you're listening and gives the user a chance to correct misunderstandings early:
> "So this is about reducing no-shows for a small clinic — the receptionist is spending half their day on reminder calls. Got it. Who else is affected by this beyond the receptionist?"

### Step 3: Identify the Ability Spectrum

For every design task, explicitly consider:
- Who might use this with a screen reader?
- Who might use this with limited motor control?
- Who might use this under cognitive load or stress?
- Who might use this in a language that is not their first?
- Who might use this with low vision, colour blindness, or in bright sunlight?

This is not a checklist to rush through. These are real people who will use what you build.

### Step 4: Propose Approaches

Present 2-3 design approaches with clear trade-offs:

For each approach:
- **What it is** — one sentence
- **Why it might work** — the strengths
- **What it sacrifices** — the trade-offs
- **Who it serves best** — and who it might underserve
- **Accessibility implications** — what inclusive design considerations arise

### Step 5: Write the Design Brief

Once the user has chosen a direction, write a design brief:

```markdown
# Design Brief: [Feature/Component Name]

## Problem Statement
[What problem are we solving, for whom, in what context]

## Users
[Who this serves — including ability spectrum considerations]

## Design Direction
[The chosen approach and why]

## Constraints
[Technical, timeline, brand, accessibility, regulatory]

## Existing Design System
[Path to design system, style guide, or component library — or "None"]

## Taste Direction (Early Signal)
[Any references, feelings, or aesthetic preferences the user shared during discovery. This seeds the full taste calibration later.]

## Success Criteria
[How we will know this works]

## Out of Scope
[What we are explicitly NOT doing]
```

Save to: `docs/designpowers/briefs/YYYY-MM-DD-<topic>.md`

### Step 6: User Approval

Present the brief to the user section by section — not all at once. Get approval on each section before moving to the next. The user must explicitly approve the complete brief before any design work begins.

### Step 7: Create Design State

**This step is mandatory. Do not skip it.**

Immediately after brief approval, create `design-state.md` in the project root with:
- Brief summary (problem, primary persona, success metric)
- Design principles (if defined during discovery)
- Empty decisions log, open questions, artefact index, and handoff chain
- Link to the full brief document

This file is the shared context every agent reads. If it does not exist, the pipeline cannot run.

### Step 8: Transition

After approval and design state creation, invoke the appropriate next skill:
- If research is needed → invoke `research-planning`
- If the direction is clear → invoke `design-strategy` or `writing-design-plans`
- NEVER skip directly to UI work

## Integration

- **Called by:** `using-designpowers` (auto-triggered on any design task)
- **Calls:** `research-planning`, `design-strategy`, or `writing-design-plans`
- **Never skip to:** `ui-composition`, `interaction-design`, or any implementation skill

## Red Flags

| Flag | Response |
|------|----------|
| "Just make it look like this reference" | References inform — they do not replace discovery. Ask what about the reference works and why |
| "We already know what we want" | Great. Then discovery will be fast. But still do it — assumptions are where bad design hides |
| "This is just a small change" | Small changes to interfaces affect real people. Discovery scales to the task — it does not get skipped |