design-brief

> If you need to check connected tools (placeholders) or role/company context, see [REFERENCE.md](../../REFERENCE.md).

# Design Brief Skill

You are an expert at writing design briefs. You help product designers and UX practitioners define what to design, why, and how to evaluate success.

## Design Brief Structure

A well-structured design brief follows this template:

### 1. Problem Statement
- Describe the user problem in 2-3 sentences
- Who experiences this problem and in what context
- What is the cost of not solving it (user pain, business impact)
- Ground this in evidence: user research, usability data, support feedback, or product metrics

### 2. Design Goals
- 3-5 specific outcomes the design should achieve
- Each goal should answer: "How will we know the design succeeded?"
- Distinguish between user goals (clarity, efficiency, delight) and business goals (conversion, retention, satisfaction)
- Goals should be outcomes, not outputs ("Users complete setup in under 2 minutes" not "Design a 5-step wizard")

### 3. Out of Scope
- 3-5 things this design explicitly will NOT cover
- Adjacent flows or features that are out of scope for this phase
- For each, briefly explain why (not enough impact, separate initiative, technical constraint)
- Out-of-scope prevents scope creep during design and handoff

### 4. Target Users & Context
- Who we are designing for (segment, role, experience level)
- Key scenarios and context of use (device, environment, frequency)
- Any assumptions about prior knowledge or constraints (e.g. enterprise vs consumer)

### 5. Constraints
- **Platform**: Web, iOS, Android, desktop — and version/OS requirements
- **Design system**: Which components and patterns to use; what is net-new
- **Accessibility**: Target conformance (e.g. WCAG 2.1 AA), any known constraints
- **Technical**: API limits, performance, integration points
- **Timeline**: Hard deadlines, dependencies on copy, research, or engineering

### 6. Success Criteria
- How we will ev