Prompt library
Draft a design brief that prevents rework
Separating problem from smuggled solution preserves the design exploration a brief exists to enable, and pre-agreed success behavior prevents the taste-war reviews that cause rework. Naming the direction-vs-detail purpose of each checkpoint stops the classic failure of relitigating strategy at the polish stage.
Last reviewed July 17, 2026
The prompt
Draft a design brief.
The project: {{project}}
What I know about constraints and context: {{context}}
Sections:
1. The problem, not the solution: what users cannot do or feel today, with the evidence. If my project description already smuggles in a solution, extract it and park it under "one candidate direction".
2. Success definition: how we will know the design worked, as observable behavior or a metric, decided BEFORE concepts exist.
3. Audience and moment: who, and in what state (rushed? anxious? expert?) they meet this design.
4. Constraints, all of them: brand rules, technical limits, deadline, budget, and the political constraint nobody writes down (whose approval actually matters).
5. Scope edges: what is explicitly out of scope, because scope creep in design arrives as "while you are at it".
6. Deliverables and checkpoints: what gets reviewed when, and what kind of feedback each checkpoint is for (direction vs detail).
7. The 3 open questions the designer should push back on before starting.
A good brief is falsifiable: someone could look at the outcome and say it missed.Run in idaptOpens a new chat with the prompt prefilled. Nothing sends until you press send.
Fill in the variables
| Variable | What it is | Example |
|---|---|---|
| {{project}} | The design work needed | redesign the onboarding flow of our mobile app |
| {{context}} | Constraints, deadlines, politics | 6 weeks, existing design system, CEO cares about step one |