How to Brief a Designer
By CodexierPublished 5 min read
A designer can only be as good as the brief. Hand over a Pinterest board and a request to make it look modern, and you get something modern-looking that solves nothing. Hand over a clear problem, an audience, the real constraints and a definition of done, and you get work you can evaluate honestly. This is the one-page brief we ask clients for before a design sprint, and it takes an hour to write.
The problem, not the solution
The most common brief is a solution in disguise: move the button up, add a hero video, make the menu like a competitor's. A designer who follows it delivers exactly what you asked and no better. Write the problem instead. Visitors leave the pricing page without contacting us. New users do not finish onboarding. Sales reps cannot explain the product from the website. State where you see the problem, how you know, and what an improvement would look like in numbers you actually track. The designer's job is to find the solution; yours is to make the problem impossible to misunderstand.
Audience and context
Design decisions depend on who is looking and what they are doing at the time. A form filled in by a facility manager on a phone in a basement needs different choices from one filled in by an accountant at a desk. Give the designer the person, the moment and the intent, in a few sentences each.
- Who they are: role, experience with products like yours, and what they already know when they arrive.
- Where and when: device, environment, how much time and attention they have.
- What they want to achieve, in their words, and what would make them give up.
- Who else is involved: a colleague who approves, a customer they serve, a boss who reads the report.
If you have real material such as support tickets, sales-call notes or search terms, attach it. Two real quotes from customers are worth more than a page of invented personas.
Constraints and must-haves
Constraints are not obstacles to creativity; they are what makes the result usable. A constraint that surfaces after the first review costs a round of work, so list them all now, including the awkward ones.
| Constraint | What to state | Why it matters early |
|---|---|---|
| Brand | Existing guidelines, logo files, colours that cannot change | Avoids a beautiful concept that cannot be used |
| Platform | Website builder, CMS, app framework, design system in use | Some layouts cannot be built where you are |
| Legal and accessibility | Consumer price rules, GDPR consent, WCAG level required | Retrofitting compliance is expensive |
| Budget and deadline | Fixed price or hours, launch date, review rounds | Sets how many concepts are realistic |
| Content | What copy and images exist, who writes the rest | Design without real content is decoration |
Separate must-haves from nice-to-haves explicitly. Everything marked must-have will be delivered; everything else is a conversation.
Examples you like and why
References are useful when they come with reasons. A link to a site you admire says little; a link with the note that you like how it explains pricing without a table, or how calm the forms feel, tells the designer what quality you are reaching for. Add examples you dislike too, with the same discipline. Three of each is plenty. Include competitors, but say whether you want to look like them or clearly unlike them, because both are legitimate goals and they lead to opposite designs.
What done looks like
The brief ends with the acceptance criteria. Not the things you will feel when you see it, but the things you can check: the page works on the phone sizes your analytics show, a new visitor can find the price in one click, the form can be completed with a keyboard alone, the copy fits the components without truncation, the files are delivered in Figma with named components. Add the deliverables list: how many concepts, how many revision rounds, what the developer receives. When done is written down, the final review becomes a checklist instead of a negotiation about taste, which protects both sides.
- Problem and how you will measure improvement.
- Audience, context and the one action wanted.
- Constraints and must-haves, with the nice-to-haves separated.
- Three liked and three disliked examples, each with a reason.
- Acceptance criteria and deliverables.
When you do not need a designer at all: a small change to an existing page that follows your current design system can be done by a developer from a sketch. When the problem is real and the answer is unknown, this brief is the input to a product design sprint, and we will review your draft on a free call before you commit to anything. Pricing is on the pricing page.
Frequently asked questions
Should I include my own layout ideas in the brief?
Include them in a clearly separate section labelled as ideas, not requirements. They tell the designer how you think about the problem and often contain useful constraints in disguise. Just do not let them replace the problem statement.
How much detail is too much?
If the brief exceeds a page or two, you are probably specifying the solution. Move detailed material such as brand guidelines, analytics exports and customer quotes into attachments and keep the brief itself to the structure above.
What if we do not know the problem yet?
Then the first purchase is discovery, not design: interviews, a UX audit or a short workshop that produces the problem statement. Briefing a designer before you know the problem is how budgets get spent on the wrong page.
Have a brief drafted and want a second pair of eyes?
Send it over before the call. In fifteen minutes we can tell you where a designer would still have to guess, what constraints are missing and whether a sprint or a smaller piece of work fits the problem.
Book a free 15-minute call