alexe-ev Write Design Brief
Purpose
Help product teams produce a design brief that enables designers to start work confidently — with a clear problem statement, known constraints, and defined success criteria — without prescribing the solution.
Skill type
Conceptual skill
Use this skill when
- A product problem is being handed to design for exploration
- Designers are starting work without sufficient context
- Design work keeps going in the wrong direction because the brief was unclear
- A design sprint or design phase needs a documented starting point
Do not use this skill when
- The goal is design review or handoff to engineering (use manage-design-handoff)
- Requirements need to be defined at the engineering level (use write-requirements-prd)
Required inputs
- Problem to be solved
- Target user or segment
- Goal or desired outcome
Optional inputs
- Research findings or user insights
- Known constraints (technical, business, time)
- Existing design patterns or system constraints
- Non-goals (what design should not do)
Upstream context
Works best when:
- Research insights exist
- User journey is mapped or at least known for the relevant area
Downstream handoff
Output can feed:
- manage-design-handoff (brief opens the design process; handoff closes it)
- run-usability-testing (brief defines what the design should be tested against)
Instructions
- State the problem from the user's perspective — not a solution.
- Describe the target user and relevant context.
- State the outcome the design should help achieve.
- List known constraints: technical, time, brand, business.
- List explicit non-goals — what this design effort should not address.
- Define success criteria: how will the team know the design solves the problem?
- Attach relevant research, data, or prior design work.
Output
Provide:
- Problem statement (user-perspective)
- Target user and context
- Desired outcome
- Constraints (technical, business, brand, time)
- Non-goals
- Success criteria
- Supporting materials (research, data, prior design)
- Open questions for the designer to explore
Risks / caveats
- A brief that specifies the solution is not a brief — it's a spec
- Constraints must be real — invented constraints waste design cycles
- Success criteria in a brief must be UX-measurable, not just business metrics