A website brief is useful when it helps you make design decisions. A list of desired pages is too limited for that. It does not explain who visits the website, which question must be answered first or what makes a contact enquiry valuable. Start with choices that actually guide the project. Design and functionality then have a clear purpose.
Describe the visitor's situation
Do not describe your audience solely by sector and company size. Also describe the moment when someone starts searching. Is there a specific project, are they replacing a supplier, or are they gathering information for a colleague? The same business may need very different explanations in these situations. A technical adviser, for example, looks for capabilities and limitations; a client wants to know how collaboration and decision-making work.
Include three recognisable visitor tasks. For example: establish whether a service fits the need, view a relevant approach and request a substantive conversation. Link each task to the information needed to complete it. This reveals which pages are essential and which mainly reflect an internal preference.
Make the desired outcome verifiable
“A professional appearance” is understandable, but hard to assess. Translate that wish into observable behaviour. A visitor should be able to explain what the organisation does, who it suits and how initial contact works. An editor should be able to update a service independently without asking for help every time. These are different outcomes, and both belong in the brief.
Also distinguish between the website and the business process behind it. A good form can capture an enquiry clearly. Whether someone then receives a timely reply depends on the follow-up. Preparing a website or online store therefore also means deciding who receives and reviews new enquiries.
Record boundaries and decisions still to be made
In a fictional example, a consultancy wants to renew all its services and add a customer environment. During the briefing, it becomes clear that the service content is ready, but the customer process has not yet been defined. The first commission could then cover the public website, with a separate decision point for the customer environment. That is easier to budget for than combining both ideas under one unclear feature.
- What content is available, and who has authority to approve it?
- Which existing addresses and downloads must be retained?
- Which features are needed to complete the main visitor tasks?
- Who decides when stakeholders have different preferences?
- Which questions need investigation before a build decision can be made?
Use the brief throughout the project
A brief should not disappear after the quotation. For important design decisions, record which agreement they fulfil. If a new request arises, assess its impact on content, scheduling and management. This creates an honest conversation about priorities.
Keep the first version concise enough to review together. Add examples where words allow several interpretations, such as a desired overview or enquiry process. Also gather the material that supports decisions: existing copy, frequently asked questions and an overview of systems. An initial conversation becomes more concrete when this information is available. The best brief does not answer everything in advance, but makes clear what has been decided and what still needs a decision.