Most design briefs are either a list of sites the client likes, or a fifty-page requirements document nobody reads. Neither produces good work. Here is what actually helps.
Start with your content, not your inspiration
The most useful thing you can bring is an honest picture of what the site has to hold. Not the copy — just the shape of it.
- What types of thing exist? Services, products, locations, case studies, events, people?
- Roughly how many of each, now and in two years?
- What does each need to show?
- Which of them relate to each other?
This is the content model, and it should drive the design. A site designed before anyone asked what it holds ends up with everything forced into the wrong shape, and the workarounds become the architecture.
Bring real content, or realistic content
Designs built on three-word headlines and perfect square images look wonderful and then break on launch day, when the real product name is nine words long and half the entries have no photo.
If final copy is not ready, provide realistic samples: your longest actual headline, a genuinely long product description, an item with a missing image. Designing for the worst realistic case costs nothing during design and a great deal afterwards.
Decide who edits the site
This changes what should be designed more than almost anything else.
- A marketing team publishing weekly needs a component library with guardrails so the brand cannot drift.
- One person updating quarterly needs something simple and hard to break.
- Nobody internal means the design can be more bespoke, because changes will come through an agency anyway.
Say which of these you are. It is one sentence and it shapes the whole engagement.
Be specific about who it is for
“Our customers” is not a brief. Who is actually landing on the site, what do they already know, what are they trying to do, and what makes them leave?
If you have search data, support tickets or sales call notes, share them. The questions customers already ask are the best available guide to what the site should answer.
Define what “done” means
Agree upfront what you are receiving. A folder of page mockups, or a system?
A system means tokens for colour, type and spacing; components with defined states; patterns your team can assemble; and documentation for the edge cases. It costs more and it is the difference between a design that holds together in two years and one that has quietly become fourteen button styles.
Questions worth asking any agency
- How will this behave with content twice as long as the mockup?
- What happens when an image is missing, or a section is empty?
- What stops our team breaking the design after launch?
- What are the hover, focus, loading and error states?
- How is accessibility handled — contrast, focus order, target sizes?
- What exactly do we receive at handover?
The answers tell you quickly whether you are buying pictures or a system. A team that has not thought about empty states has not thought about your site being used.
What you can safely skip
- Prescribing layouts. Describe the problem; that is what you are paying for.
- A long list of sites you like. Two or three, with a sentence on why, is far more useful than twenty.
- Exhaustive feature lists written before anyone has looked at your content.
- Choosing the technology first. That decision follows the content model, not the other way round.
One last thing
Be honest about budget and deadline early. Not to be haggled with — so the proposal you get back is one that can actually succeed. A designer who knows the real constraints will tell you what is possible within them, or tell you it is not. Both answers are more useful than a proposal built on a number nobody believed.