How to Brief a Web Designer

When a website project goes wrong, the post-mortem almost always blames the designer: they didn't listen, they didn't get the brand, the third round of revisions still missed the point. Sometimes that's true. More often, the project was doomed in the first meeting, when the client said some version of 'I'll know it when I see it' and the designer nodded and started guessing. Every revision round after that is paid guessing.

A good brief is not a longer brief. Designers regularly receive 40-page brand documents that contain no usable information and two-line emails that contain everything they need. The difference is whether the brief answers the questions a designer actually has to answer to do the work. This post walks through those questions, in the order a designer needs them answered, plus the classic briefing mistakes that generate revision cycles.

Start with the business problem, not the website

The first section of your brief should not mention colors, pages, or competitors' sites you like. It should answer: what has to be different about your business six months after this site launches? Real examples of good answers:

• 'We get a steady stream of phone inquiries and want more, because they convert better than any other channel for us.'
• 'We're launching a second service line and the current site makes us look like we only do the first one.'
• 'Most of the people we sell to are now corporate procurement teams, and the site needs to survive being forwarded to a CFO.'
• 'We lose deals to a competitor whose site makes them look three times our size.'

Notice these are measurable or at least checkable. 'We want a fresh, modern look' is not a business problem; it's a mood. A designer given a mood will produce something fresh and modern that may do nothing for your actual situation. A designer given a business problem will make a hundred small decisions correctly without asking you — because now they can evaluate their own choices against something concrete.

Describe the visitor, specifically

The second question a designer needs answered: who arrives at this site, and what do they already know? Be concrete to the point of feeling silly. Instead of 'homeowners aged 30–60', write:

• 'A homeowner who just discovered water in their basement, on their phone, stressed, comparing three companies from a search. They will decide within ten minutes.'
• 'An office manager told by her boss to find a caterer for a 50-person event. She needs pricing signals and photos she can paste into an email to look competent.'

The difference matters enormously for design decisions. The stressed homeowner needs a phone number visible without scrolling and proof of fast response times. The office manager needs a gallery and a downloadable menu. Same industry vagueness ('we serve residential and commercial customers'), completely different websites.

If you have multiple visitor types, rank them. A site that treats four audiences equally serves none of them well, and forcing yourself to declare a primary audience is one of the most valuable things a brief can do — it settles arguments before they start.

Give content before design starts, or admit you can't

Here is the single most common cause of blown timelines: the design is done, and the client hasn't written the text. The designer built a homepage around a punchy three-line value proposition; the client eventually delivers four paragraphs of history starting with the founder's grandfather. Now the design doesn't fit the content, and reconciling them is nobody's favorite work.

Three workable approaches, in order of preference:

1. Content first. Draft the actual text — even rough — for the top five pages before design begins. Real headlines, real service descriptions, the actual number of testimonials you have (not the number you wish you had).
2. Content and design together, with a writer involved. Costs more, works well.
3. Admit content will be late and ask the designer to design around realistic placeholder content that you approve. 'Realistic' means matching your actual verbosity — if your service descriptions run 200 words, the mockup shouldn't be designed around 20.

What doesn't work is 'we'll write it once we see the design.' You will not. Nobody ever has.

Reference sites: show three, and say why

Reference sites are useful when annotated and dangerous when bare. 'Here are ten sites I like' forces the designer to reverse-engineer what you like about them — and they'll guess wrong, because what you actually liked about that architecture firm's site was that it felt expensive, not the specific gray palette the designer will now dutifully copy.

The fix is a constraint: pick three sites maximum, and for each, write one sentence about what specifically works. 'I like how their pricing page makes the middle option obvious.' 'The photography here feels candid, not stocky — that's the feeling I want.' 'Their navigation has five items and I can always find things; ours has eleven and nobody can.'

Equally useful, and almost nobody does it: name one or two sites you dislike, with reasons. 'This competitor's site feels cluttered and salesy; we'd rather look quieter and more confident even if it's less flashy.' Negative space in a brief prevents entire categories of wrong drafts.

State your constraints like an adult

Designers can work within almost any constraint they know about. Constraints discovered in week six cause the expensive kind of rework. Your brief should plainly state:

• Budget range. Yes, actually state it. The fear is that naming a number means paying that number; the reality is that a designer scopes the approach to the budget. A small project and a large one are different processes, not the same process at different prices. Hiding the budget just means getting a proposal scoped for the wrong one.
• Hard deadline and the reason. 'Before our trade show on March 12' lets the designer plan phases — maybe the core pages launch by the show and the blog comes after. 'ASAP' means nothing and everyone knows it.
• Brand non-negotiables. Existing logo staying or open for discussion? Brand colors fixed by a franchise agreement? Legal or regulatory requirements (health claims, financial disclaimers, accessibility standards)?
• Platform requirements. If you need to edit the site yourself afterward, say so now — it shapes the entire technical approach. If it must be WordPress because your team knows WordPress, that's a legitimate constraint; state it.
• What already exists and must survive. The booking system that integrates with your calendar. The 80 blog posts that bring search traffic. The email signup flow tied to your newsletter tool. List these explicitly.

Decide who decides

More projects die from decision-making structure than from design quality. Before the project starts, answer in writing:

• Who gives feedback? If it's you, your business partner, and your spouse, say so — the designer will plan for consolidated feedback rather than three contradictory email threads.
• Who has the final call? One name. When feedback conflicts, this person breaks the tie. Projects with committees and no tiebreaker average roughly twice the revision rounds, and the result usually pleases nobody — consensus design converges on beige.
• How will feedback be delivered? One consolidated document per revision round beats forty scattered comments. Agree on this rhythm up front.

How to give feedback that improves the next draft

Feedback is briefing, continued. The unhelpful version prescribes solutions: 'make the logo bigger', 'try it in blue'. The helpful version describes problems: 'I worry the company name isn't the first thing you notice', 'this feels colder than how people describe us'. Prescribed solutions get you exactly what you asked for, which is often not what you wanted. Described problems let the designer solve them with tools you don't know exist — maybe the logo doesn't need to be bigger; maybe it needs more empty space around it.

What to leave out of the brief

A brief can be too controlling, and over-specified briefs produce websites that look like the client's guesses instead of the designer's expertise — which raises the question of why you hired one. Leave to the designer:

• Fonts and specific colors (beyond fixed brand assets). Specify the feeling — 'trustworthy, established, not stuffy' — and judge the result.
• Layout specifics. 'Testimonials must be in a carousel' is a solution; 'social proof needs to be prominent' is the requirement. State requirements.
• Trends by name. Asking for 'parallax scrolling' or whatever is currently fashionable dates your site to the month it launched. Describe outcomes, not techniques.

The one-page brief template

Everything above fits on a page. Section by section:

A designer receiving this document will tell you — usually with visible relief — that it's better than what they get from clients ten times your size.

The honest conclusion

You cannot brief your way to a guaranteed great website; design still requires judgment, and judgment is what you're paying for. But you can brief your way out of the two failure modes that account for most disappointing projects: the designer solving the wrong problem, and the revision spiral where nobody can articulate what's wrong. One page, six sections, written before the first meeting. It's the cheapest hour you'll spend on the entire project, and it's the one that determines whether the expensive hours are spent designing or guessing.

Photo: Daniil Komov on Pexels