Write a Brief That Actually Gets You a Better Website
Most website projects go sideways before a single line of code gets written. Not because the designer is bad, or the client is difficult, but because the brief was vague. 'Something clean and modern' tells a developer almost nothing. A good brief cuts revision rounds, keeps costs predictable, and means the site you get actually matches what you pictured. Here is how to write one that does all three.
On this page
Start With the Outcome, Not the Design
The single biggest mistake in a website brief is describing how you want the site to look before explaining what it needs to do. A developer can suggest colours and layouts. What they cannot guess is your business goal.
So open your brief with a plain sentence about the outcome. ‘We want visitors to book a free consultation’ is a brief. ‘We want a nice homepage’ is not. Every decision that follows, from navigation to page structure to call-to-action placement, flows from that one clear objective.
Describe Your Audience With Specifics
Saying your audience is ‘everyone’ is the second most common brief problem. It forces a designer to make assumptions, and assumptions cost you revision time later.
Think about who actually buys from you. Are they browsing on a phone during a lunch break, or sitting at a desktop comparing suppliers? Do they arrive already knowing what they want, or do they need convincing first? Even a rough sketch of that person, their situation, their question, their hesitation, shapes a better site than a mood board ever will.
If you serve more than one type of visitor, name them separately. A designer can build navigation paths that serve both. They cannot do that if both are bundled into one vague description.
List Your Pages and What Each One Must Do
A sitemap does not need to be a polished document. A numbered list in a plain text email works fine. What matters is that it exists.
For each page, write one sentence about its job. The About page builds trust. The Services page explains the offer. The Contact page removes every reason not to get in touch. When a developer knows the purpose of a page, they can structure it to serve that purpose rather than guessing from the title alone.
One thing worth flagging here, if you have existing content, say so. If you need content written, say that too. Content is often the single biggest delay in a web project, and a brief that ignores it will run over time almost every time. You can find more on this when thinking about how copy and page structure interact at the ranking level.
Include Reference Sites, and Say Why You Like Them
Three to five websites you admire are worth more than a paragraph of adjectives. But a link alone is not quite enough. Note what you actually like about each one.
Is it the speed? The layout? The way the navigation is organised? ‘I like how this one loads instantly and the menu stays out of the way’ tells a developer something real. ‘I like this one’ tells them nothing except that you have seen it.
The same logic applies to sites you dislike. If there is a style you actively want to avoid, say so. Designers are not mind readers, and ruling out a direction early is far cheaper than reversing it after build.
Be Honest About Budget and Timeline
Many clients hold back on budget because they worry it anchors the price upward. In practice, the opposite is more common. A developer who does not know the budget either scopes something too large and shocks you with the quote, or scopes something too small and leaves you disappointed with what arrives. If you want to know what a realistic budget actually covers, our UK website cost breakdown is a useful starting point before you write the brief.
On timeline, be realistic. A properly built, well-optimised site takes time. Anyone promising a full site in 48 hours is either templating heavily or cutting corners you will notice later. Give a rough launch window and flag any hard deadlines, such as a product launch or an event. That context helps a developer plan the build in a way that actually hits the date.
The One Thing Most Briefs Forget
Technical requirements. These are almost always missing, and they matter more than most clients realise.
- Do you need the site to connect to a booking system, a CRM, or a payment processor?
- Do you need multilingual support?
- Will you be updating the content yourself, or does someone else manage that?
- Are there accessibility standards you need to meet?
These questions change the build significantly. A site that needs to talk to an external system is a different project to one that does not. The sooner a developer knows, the more accurately they can scope the work, and the fewer surprises appear mid-build. For anything involving automation or integrations, it is worth understanding what sits underneath the surface before you commit to a spec.
Keep It Short and Send It Early
A good brief does not need to be long. Two pages of clear, specific information beats a ten-page document full of padding. The goal is to give a developer enough context to ask the right follow-up questions, not to pre-answer every possible one.
Send it before the first call if you can. Developers who arrive at a discovery meeting having already read a clear brief ask sharper questions, and you both leave the call with a much clearer shared picture of what gets built.