The quality of a web project is set, in large part, by the quality of the brief. A vague brief produces a generic result — work that technically satisfies the ask but misses what the business actually needed. A precise brief produces something useful. Writing a good brief is a skill. Here is how to do it.
What a brief is not
A brief is not a list of features. “We need a homepage, an about page, a services page, and a contact form” is a sitemap, not a brief. It tells a developer what pages to build but gives them no basis for decisions about what goes on those pages, how they should feel, or what they should accomplish.
A brief is also not a description of what you like aesthetically. “We want something clean and modern with lots of white space” is a starting point but not a foundation. Clean and modern describes the aesthetic of roughly half the business websites on the internet.
What a good brief contains
A brief that produces good work answers six questions:
- What is the business? Not the elevator pitch — the honest description. What it does, who it serves, how it makes money, what makes it different from alternatives.
- Who is the primary visitor? A specific description of the person most likely to become a customer. What they know when they arrive, what they need to understand before they act, what would make them leave.
- What is the site supposed to accomplish? One primary goal, stated as a measurable outcome: generate enquiries, book appointments, explain the service well enough to close referrals. Not “look professional.”
- What is the tone? How the business should feel to a visitor. Supported by examples — other sites, brands, or communications that capture the register, even if the category is different.
- What are the constraints? Budget range, timeline, technology requirements, existing brand assets, integrations needed. Better to surface these early than to discover them mid-project.
- What does success look like? How will you know, three months after launch, whether the site is working? What metric, what outcome, what change in the business?
What to leave open
A good brief does not specify implementation. It does not prescribe design solutions or dictate technical approaches. Those are the developer’s job. A brief that specifies “hero section with a full-width video background and a centered headline” is a brief that has already made design decisions that should belong to the designer.
Leave the “how” open. Be specific and precise about the “why” and the “what for.” The work that results from that kind of brief is almost always better than work that followed a prescriptive specification.
The brief as a shared document
The best briefs are written collaboratively — the client and the developer working through the questions together, the developer asking follow-up questions, the client discovering in the process that some questions are harder to answer than expected.
That discovery is useful. A question you cannot answer before building the site is a question the site will also fail to answer for visitors.
Every project I take on starts with a structured brief conversation. If you have a project in mind and want to work through what a good brief would look like, get in touch.