A better website starts with a better brief
The questions that turn a vague redesign request into a useful plan.
Start with the decision, not the page count
A request for a new website often begins with a list of pages. That list is useful, but it does not explain why the site should exist. Before deciding how many pages to build, write down the decision you want a visitor to make. Do they need to understand a service, compare products, book a conversation or manage an existing account? Each of those goals creates a different reading and interaction journey.
Be specific about the audience as well. “Everyone who needs our service” is difficult to design for. A first-time buyer may need explanation and reassurance, while an existing customer may want a quick route to a practical task. Separate those needs before trying to fit them into the same homepage.
Describe the current friction
Gather a few concrete examples of what is not working. Perhaps customers ask the same question because the answer is difficult to find. Perhaps editors avoid updating the site because every small change needs help. Perhaps an enquiry form collects too little information to be useful. Describe the behavior and its consequence, rather than jumping straight to a preferred feature.
A good brief can say, “Visitors cannot tell which service fits their situation,” without assuming that the solution must be a new quiz. That leaves room to compare simpler options, such as clearer service descriptions or a better navigation structure.
Put content on the critical path
Content is part of the product, not a finishing layer. A beautifully designed service page cannot explain an offer that has not been defined. List which information already exists, what needs rewriting and who can confirm its accuracy. Include real photography, policies, contact details and case-study permissions in that inventory.
Assign a content owner and review point for each major section. If several people need to approve the same page, gather their feedback together. Conflicting late changes are easier to prevent than to resolve after the page has been implemented.
Make constraints visible
Document the tools the website needs to connect to, the people who will update it and any requirements for data handling. Include the launch reason: a product announcement creates different scheduling pressure from an open-ended refresh. A useful brief distinguishes a real deadline from a preferred date.
Also identify what belongs outside the first release. A customer portal, an extensive resource library or a complex integration may be valuable later. Keeping those ideas visible without treating all of them as immediate requirements makes the initial plan easier to assess.
Define what a good result looks like
Choose outcomes you can actually evaluate. A clearer enquiry route might be assessed through the relevance of enquiries and the completion of key tasks. An editor-friendly site might be assessed by whether the content team can publish a routine update without developer help. Avoid turning a design brief into a promise of a particular revenue increase.
The brief does not need to answer every implementation question. Its job is to establish a shared starting point: audience, tasks, content, constraints and success criteria. From there, a sitemap, scope and prototype can become concrete decisions rather than guesses.
Write the first brief around five things: audience, useful action, current friction, available content and constraints.