Insight • Briefing

How to brief a designer

Published: 29 December 2025

The fastest way to slow down design work is to start without a brief. When the brief is missing, teams fill the gaps with assumptions: what the audience cares about, what needs to ship, how success is measured. The result is avoidable churn: multiple rounds of revision, misaligned feedback, and last-minute requests that blow up timelines.

A good brief doesn’t need to be long. It needs to be specific and testable. This article gives you a template you can use for web pages, campaign creative, or brand assets.

The briefing template

1) The job to be done

In one sentence: what should the work help someone do? Avoid vague statements like “make it modern”. Instead: “Help visitors understand what we offer and take the next step within 30 seconds.”

2) Audience and context

Who is this for?
What do they already know?
What are they anxious about or sceptical of?
What device are they likely using (mobile, desktop, mixed)?

3) Success criteria

Define how you’ll judge the outcome. Examples: increased enquiries, higher completion rate, clearer navigation paths, reduced support questions. These don’t need to be numeric in the brief, but they do need to be clear.

4) Constraints and non-negotiables

Constraints are helpful. They reduce decision fatigue. Write down what must be true at the end: accessibility baseline, performance expectations, required sections, words that can’t be used, brand rules.

5) Content and structure

Designers can’t invent content at the last minute. Provide the rough content blocks (headlines, key points, proof, CTA). If content is missing, say so and assign an owner.

Required headings and sections
Primary call to action
Supporting proof (testimonials, examples, process)
FAQs or objections to address

6) References (with intent)

References are useful when you explain why they matter. Don’t just drop links. Instead: “We like this because the hierarchy is clear on mobile” or “we like the calm spacing and short paragraphs.” If you don’t know what you like yet, say so.

7) Definition of done

“Done” should include real-world constraints: responsive behaviour, states, accessibility basics, handover artifacts, and what gets reviewed.

Responsive layouts for mobile, tablet, desktop
Keyboard navigation and visible focus
Copy and content reviewed and approved
Assets delivered in agreed formats

How to run feedback without chaos

A brief is only half the work. The other half is feedback. One pattern that helps is to separate feedback into two categories:

Correctness feedback

Is information wrong or missing?
Does the structure match what we agreed?
Does it meet accessibility and mobile requirements?

Preference feedback

Do we like the tone?
Do we want the brand to feel more calm, bold, technical, playful?
Are we choosing a direction intentionally?

Mixing these creates confusion. Correctness is non-negotiable. Preference needs a decision maker.

Common questions designers will ask (answer them upfront)

If you want speed, answer the predictable questions before they’re asked. This prevents the “waiting for answers” gaps that stretch timelines.

What are we making? A landing page, a set of ads, a brand template pack, a multi-page site?
What’s the deadline? What date is fixed, and what can slide?
Who approves? One decision maker or a committee? How will disagreements be resolved?
What must be true on mobile? Navigation, readability, tap targets, content order.
What content is ready today? What is missing and who owns it?

Specify deliverables and formats

“A design” is ambiguous. Be specific about what you want to receive at the end. This helps designers scope properly and avoids last-minute “Oh, we also need…” surprises.

Examples

Web: page layout(s), component states, mobile/tablet/desktop breakpoints, and a content-ready structure.
Campaign: a key visual plus a defined set of variants (formats and sizes).
Brand kit: templates, guidelines, and example usage.

If you have constraints (for example, “no heavy JS”, “must load fast”, “must be accessible”), write them down in the brief rather than hoping they appear later.

Make the brief easy to scan

Briefs are read quickly. Use headings, bullets, and short paragraphs. If you write a wall of text, the team will miss critical information and you’ll end up answering the same questions repeatedly.

Include a rough timeline (even if it’s a guess)

Designers can work with uncertainty, but they can’t work with no constraints. A simple timeline helps the team choose an appropriate level of fidelity and avoid over-investing in parts that won’t ship.

Kickoff: when you want to start
First review: when stakeholders will see an initial direction
Final sign-off: when decisions must be locked
Launch date: what is fixed, and what has flexibility

Provide assets and references as a pack

A common source of delay is “asset scavenger hunts”. If you have a logo, product screenshots, photography, copy docs, or existing templates, bundle them in one place and link it from the brief. Even if assets are incomplete, list what’s missing and who will provide it.

Asset checklist

Logo files and usage rules (if any)
Product images or screenshots
Brand colours and typography (current or aspirational)
Existing content that must be reused
Examples of previous campaigns or pages that performed well

Briefing for web work: include states

Websites aren’t just static screens. If the work involves forms, navigation, or content cards, call out the states that matter. This prevents the classic “We didn’t think about errors until launch week” moment.

Empty states (what happens when there’s no content?)
Error states (what should the message say?)
Loading states (if applicable)
Focus and keyboard behaviour (especially for menus)

What to do next

If you want support shaping a brief or running delivery end-to-end, see our services or contact us. A clear brief is often the difference between a two-week sprint and a two-month slog.