/design-discovery

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:

# Design Brief: [Feature/Component Name]

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

## Users
[Who this serves — including ability spectrum cons