Prepare a business website brief around audience needs, content readiness and decision ownership. Includes a practical table for your first agency meeting.
A useful website brief explains the company while making the project's decision boundaries visible. A collection of reference links can communicate visual preferences without explaining what visitors need to understand. The brief should not settle every design choice in advance. It should give the team enough shared context to ask the right questions.
Centre the brief on the visitor's job
Describe the company concisely, then identify the priority audiences and the information they seek. A procurement lead may need technical evidence, a job candidate may want to understand the workplace, and an existing customer may need support. Those needs do not have to receive equal weight in the opening message.
State which visitor task matters most for the first release. For example: “Help manufacturing companies find the relevant service, understand its scope and request a quote.” That direction gives the team a criterion for page order and content without prescribing a fixed visual layout.
Show what is ready and what still needs work
List existing copy, product data, photography, logos, brand guidance and documents. Mark each as ready to use, needing revision or requiring new production. If a folder labelled “website content” contains outdated presentations, writing and editorial work should remain visible in the scope.
Imagine a hypothetical consultancy using different names for the same services across sales decks. Agreeing shared service names and boundaries provides clearer material for the website. The brief should reveal that unresolved content decision instead of asking a designer to transfer every existing slide without question.
Use fields that lead to decisions
Complete the following table as a starting document. Mark unknowns for discovery rather than supplying a confident guess. This helps the agency distinguish a settled preference from a problem it is expected to investigate.
| Brief field | Information to provide | Question to resolve |
|---|---|---|
| Business objective | Priority commercial or organisational need | Which task should the site make easier? |
| Audience | The visitor group to address first | What informs its decision? |
| Content | Ready assets and missing material | Who approves factual accuracy? |
| Design direction | Preferred qualities and the reason | Is the reference about type, imagery or storytelling? |
| Functionality | The action visitors should complete | Where does submitted information go? |
| Governance | Approval, budget and schedule owners | Who resolves conflicting feedback? |
Discuss creative direction and release conditions together
Explain what you value in references: strong typography, detailed product presentation, restrained transitions or expressive motion. Leave room to discuss how those qualities support your own message. Mobile readability and core user journeys should form part of the design conversation.
W3C's accessibility-planning resources can help establish responsibilities within the project. Include the accessibility objective and verification owner in the brief. If a launch date is fixed, explain why: an event, commitment or operational need may affect priorities. End the briefing process with open questions and named people who can answer them.