How to write a usable design brief

A usable brief makes decisions visible

A vague request names an output: “make a landing page” or “refresh the deck.” A usable brief also explains the audience, the decision the work should support, the required content, the constraints, and who can approve it.

The aim is not to predict every design decision. Give the designer enough context to explore, and make the fixed parts unmistakable. Put unresolved questions in the brief instead of hiding them inside confident-sounding instructions.

Ten fields—and why each one matters

Start with the smallest version that answers these prompts. Add supporting documents by link when the request needs more depth.

1. 1. The request in one sentence

   Name the thing to design and the reason it exists. This gives the request a boundary before the detail begins.

   Prompt: We need [deliverable] for [audience or moment] so that [decision or action].

2. 2. Background and problem

   Explain what changed, what is not working, or why the request matters now. Link to supporting context instead of pasting a history lesson.

   Prompt: What prompted this request, and what problem should the work address?

3. 3. Audience and situation

   Describe who will encounter the design, what they already know, and where they will see or use it.

   Prompt: Who is this for, and what are they trying to understand or do?

4. 4. Desired outcome

   State the decision, understanding, or next action the design should support. Avoid asking the layout itself to be the goal.

   Prompt: After seeing this, what should the audience be able to decide, understand, or do?

5. 5. Deliverables and formats

   List quantities, sizes, channels, breakpoints, states, and final file types so the request has a visible definition of done.

   Prompt: What exactly must be delivered, in which sizes or states, and in what format?

6. 6. Content and asset status

   Separate final material from placeholders. Link the approved copy, logo files, imagery, product screens, data, and usage permissions.

   Prompt: What is final, what is missing, and who owns each missing input?

7. 7. Brand direction and useful references

   Link current brand rules and explain what each reference communicates. A reference is more useful when the designer knows what to notice.

   Prompt: Which rules are fixed, and what should the designer learn from each reference?

8. 8. Accessibility and inclusion

   Name the needs the work must support, such as readable contrast, keyboard states, captions, text alternatives, plain language, or localization.

   Prompt: Which people, devices, languages, and access needs must the design account for?

9. 9. Constraints, timing, and priorities

   Surface fixed technical limits, dependencies, launch dates, and what can move. A date without its reason hides the real priority.

   Prompt: What is fixed, what is flexible, and what event makes the timing matter?

10. 10. Review and decision rights

    Name who can give input, who combines feedback, and who makes the final call so the designer receives one usable direction.

    Prompt: Who reviews, who resolves conflicts, and who approves the work?

Keep answers short enough to scan. Use links for source files, research, and detailed specifications.

REQUEST
We need [deliverable] for [audience or moment] so that [decision or action].

BACKGROUND AND PROBLEM
[What prompted the request? What is not working or changing?]

AUDIENCE AND SITUATION
[Who is this for? What do they know, need, or do next?]

DESIRED OUTCOME
[What should the audience understand, decide, or do?]

DELIVERABLES AND FORMATS
[Quantities, sizes, channels, breakpoints, states, and final file types.]

CONTENT AND ASSETS
[Links to final copy, brand files, imagery, screens, data, and permissions.]
[Missing inputs, owner, and expected date.]

BRAND DIRECTION AND REFERENCES
[Fixed rules. For each reference, explain what is useful and what is not.]

ACCESSIBILITY AND INCLUSION
[Contrast, keyboard/focus states, captions, text alternatives, language, localization, or other needs.]

CONSTRAINTS, TIMING, AND PRIORITIES
[Technical limits, dependencies, fixed date and why it matters, flexible items.]

REVIEW AND DECISION RIGHTS
[Reviewers, feedback owner, final approver, review dates.]

NON-GOALS AND OPEN QUESTIONS
[What is explicitly outside this request? What still needs a decision?]

Clearly fictional example

From a vague request to a usable brief

Make references explain themselves

For every visual reference, add one sentence about the useful quality: hierarchy, pacing, density, photography, interaction, tone, or something else. Add a second sentence when a visible element should not be copied. That keeps a reference from becoming an accidental instruction to reproduce another brand.

Ready-to-send checklist

• The request names a specific deliverable and why it is needed.
• The audience and the situation in which they encounter the design are clear.
• The desired outcome describes a decision, understanding, or action—not a layout.
• Quantities, sizes, channels, states, and file formats are listed.
• Final and missing content or assets are separated, with an owner for each gap.
• Accessibility, language, device, and production requirements are visible.
• The timing includes the event or dependency that makes the date matter.
• One person owns combined feedback and one person owns final approval.
• Non-goals and open questions are written down.