Write a website brief people can build from.
Editorial illustration · Dan LorisA practical website brief connects the visitor's task, the business goal, the evidence, and the first release.
TLDR
The short versionStart with what the visitor needs to accomplish. Define the next action, the evidence that supports your offer, the systems behind the site, and the boundary of the first release. Use that brief to make design decisions.
A website project can begin with a folder full of references and still leave everyone unsure what to build. The colors are there. The menu is there. The reason someone would use the site is harder to find.
A useful website brief gives the designer, writer, and developer a shared decision to work toward. It should help you choose what belongs on the page and what can wait. You can write the first version before you know your platform or have a finished brand book.
Start with the visitor's unfinished task
Describe the person arriving and the thing they need to accomplish. “Small business owners” gives you an audience. “An owner comparing help for a website that no longer reflects the business” gives you a situation to design around.
That visitor may need to understand your services, see relevant work, and decide whether a conversation is worth having. Those tasks suggest a different page from one serving an existing customer who needs to download a document.
Write a sentence in this form, using ordinary language. The visitor arrives because something needs to happen. After visiting, they should be able to take a specific next step. If that sentence is difficult to finish, interview a few people before adding pages to the plan.
Give the business goal a visible action
“Generate more business” is a reasonable ambition, but it gives the build team little to work with. A more useful brief might ask the site to help suitable prospects submit an inquiry that includes enough detail for a helpful response.
Now you can make decisions. The service page needs to explain the work. The portfolio needs to show relevant capability. The form needs to collect useful context without asking someone to write a proposal before meeting you.
Decide what you will observe after launch. Completed inquiries, the services people ask about, and the questions they still send by email can reveal different things. A visit count alone cannot tell you whether the site explained the offer.
Put the evidence beside the promise
For each important claim, identify what you can actually show. A product screenshot can explain what was built. A short account of your role can distinguish your contribution from the team's work. A sample deliverable can show how you think when a client project is confidential.
Keep unsupported claims out of the brief. If there is no approved testimonial or measured result, use an honest description of the work. The site will be stronger when its details survive a follow-up conversation.
For a hypothetical consulting business, the brief could pair “We organize complex operations” with an anonymized process map and a clear explanation of the decisions it supports. That is a concrete content requirement the team can plan for.
Write down the constraints that change the build
Name who will update the site, what they need to edit, and which systems receive information from it. A contact form connected to a CRM has different requirements from a form that sends a single notification.
Include accessibility needs, existing URLs that must keep working, ownership of domain and hosting accounts, and anything the team is not allowed to publish. Assign someone to provide the source content and someone to approve it. These decisions affect scope long before the first visual design.
The GOV.UK discovery guidance offers a useful principle here: understand the problem, users, and constraints before committing to a solution. A commercial website benefits from the same discipline.
End with a small first release
Separate what the visitor needs on launch day from what would be useful later. An appointment request can be enough while a more complex booking integration is being evaluated. An accurate portfolio with a few strong examples can be more useful than a large library of unfinished case studies.
Your first brief can fit on a page. Describe the visitor, their task, the next action, the evidence, the operational requirements, and the release boundary. Add unresolved questions at the bottom with an owner beside each one.
Then use the brief when reviewing the design. A beautiful section should earn its place by helping someone understand or do something.
If you want help turning that brief into a website people can use, Work with me.



