A useful website brief describes the job your website must do, the people it must help and the decisions a supplier needs to price the work. It does not need to prescribe every screen. It needs to make the important uncertainties visible before those uncertainties become extra work.
For a South African business comparing design proposals, this distinction matters. Two suppliers can quote for a "ten-page website" while assuming completely different responsibilities for copywriting, forms, photography, hosting and ongoing support. A clearer brief gives you a better basis for comparing those proposals.
Start with a short working document. Add detail where it changes the scope, and mark unanswered questions honestly rather than filling them with guesses.
Describe the business problem before the visual style
"Our website looks old" is a starting observation, not a project objective. Ask what the current site prevents customers or staff from doing.
Perhaps visitors cannot tell which service suits them. Perhaps sales staff repeatedly explain information that should be easy to find. Perhaps mobile enquiries are difficult because the contact form is awkward. These are different problems, even if they all lead to a redesign.
Write one primary outcome in plain language. For example: "Help facilities managers understand our maintenance offering and send an enquiry with the correct site information." This is a hypothetical brief, not a claim about any particular business.
Then record the evidence you already have: repeated customer questions, support emails, feedback from sales or a page that confuses visitors. If you do not have analytics, say so. A brief can start from observations without pretending they are measured conversion data.
Choose the audience and its most important task
A website can serve several audiences, but the homepage cannot prioritise every visitor equally. Identify the person most likely to take the action your business needs.
Describe that person's situation rather than inventing a detailed fictional biography. Useful questions include:
Are they researching a supplier or ready to request a quote?
Do they understand your terminology?
Are they comparing technical specifications, visual quality or delivery arrangements?
What information would make them hesitate?
Are they likely to browse on a phone while away from a desk?
For each priority audience, write one task. A prospective customer might need to compare services. A returning customer might need documentation. A recruitment candidate might need a careers page. These tasks help determine the navigation and content hierarchy.
Avoid treating "everyone" as an audience definition. It makes almost every design decision harder to evaluate.
Map journeys, not just page names
A page list is useful, but a journey explains how those pages work together. Try describing three realistic routes through the proposed site.
One route might begin on a service page found through search, continue to a relevant example and finish at a contact form. Another might start on the homepage and lead to a product specification. A third might involve someone checking your location and telephone number.
For each journey, identify the next useful action. The answer is not always another large button. It could be a clear comparison, a downloadable document or a visible explanation of what happens after an enquiry.
List the pages needed to support those routes. Separate essential launch pages from later additions. This keeps an interesting future idea from quietly becoming a launch requirement.
Separate visual references from functional requirements
It helps to share websites you like, but explain what you like about them. "The service navigation is easy to scan" is more useful than "make ours like this".
You might appreciate the typography of one site, the photography of another and the product filtering of a third. Those references can guide discussion without requiring an imitation of an unrelated brand.
Also list what must remain consistent: your logo, approved colours, language, image style or existing brand guidelines. If these assets need updating, make that a separate task.
The web design services at 360 Design provide a relevant starting point for discussing visual presentation alongside the practical structure of a business website.
Make content responsibilities explicit
Content is often the least clearly assigned part of a website project. A supplier may assume that final copy and images will arrive before development. The business may assume that writing and image selection are included.
Create a simple content register with one row per page. Record the purpose, existing material, person responsible and approval status. Note whether the copy needs editing, rewriting or creating from scratch.
Include image rights and source files in this conversation. A small image copied from an old PDF may not be suitable for a wide homepage banner. A stock photograph may be available for one use but not another. The person providing assets should confirm that the intended use is permitted.
Do not forget practical content such as error messages, confirmation emails, form labels and document names. These details affect the experience even though they rarely appear in a mood board.
Specify features through observable behaviour
Instead of writing "we need search", describe what people should be able to search and what a useful result looks like. Does search cover articles, products, downloadable PDFs or all three? Should unpublished content be excluded? What should happen when there are no matches?
The same approach works for forms. State the required fields, recipient, confirmation message and expected handling of attachments. Explain whether enquiries must also be stored in the admin area.
For each feature, separate the user requirement from an implementation preference. "Editors must be able to schedule articles" is a requirement. A particular plugin is a proposed implementation. Keeping them separate gives the supplier room to recommend an appropriate solution.
Accessibility should also be discussed as an acceptance requirement, not a final cosmetic check. Include keyboard use, clear labels and readable content in the review plan.
Agree on decisions, dependencies and acceptance
Identify who can approve design, content and launch. If several people need to review a page, nominate one person to consolidate their feedback. Contradictory instructions delivered separately create avoidable rework.
List dependencies that could affect delivery: access to the existing domain, hosting, analytics, mailbox settings, content exports and external integrations. Do not place passwords inside the brief; describe the access required and agree on a secure handover method.
Define acceptance through tasks the finished site must pass. Examples include submitting a contact enquiry, finding a service on mobile, editing an article and reaching an important document from its intended page.
The W3C's initial accessibility checks are useful for beginning a review, but an initial check is not a complete accessibility evaluation. State what level of testing the project actually includes.
Use a short brief structure that suppliers can answer
A practical brief can use these headings:
Business background and the problem to solve.
Primary audience and desired action.
Essential page journeys and launch pages.
Content and asset responsibilities.
Functional requirements and integrations.
Brand references and constraints.
Budget range, timing and dependencies.
Review process, acceptance and ongoing support.
Give suppliers room to state assumptions, exclusions and alternative approaches. Ask them to separate one-off project work from recurring services. A lower initial figure may not cover the same responsibilities as a higher one.
Where you do not know the budget, describe the priority order instead. A useful supplier conversation can identify what should be delivered first and what can be deferred.
Finish with the questions you still need answered
A brief does not have to eliminate uncertainty. It should organise it. Mark questions such as whether you need a customer portal, whether product data can be exported or whether existing photography is usable.
This allows a discovery phase to have a defined purpose rather than becoming an open-ended meeting. You can then compare proposals on how they address the same decisions.
Before requesting proposals, ask a colleague unfamiliar with the project to read the brief. Can they explain who the site is for, what visitors should do and what the supplier is expected to deliver? If not, revise those parts first.
When you are ready to discuss the project, contact 360 Design with your audience, essential journeys and available content. Those details provide a more useful starting point than a page count alone.
Elisha Roodt
Founder and Digital Pioneer at 360Design.org. Leading groundbreaking innovations across Web Development, Virtual Reality, Augmented Reality, 3D Renders, and AI since 1998.
