A useful website brief does not need to be a long document. It needs to make the important decisions visible. A folder of reference sites helps explain taste, but it cannot tell a designer what your company needs the website to do. Start with the business, the audience, and the material you can support.
Explain who the site is for
Name the main audience as precisely as you can. A procurement team checking capability needs a different route through the site from a technical hire assessing a potential employer. Your website can serve both, but it needs a clear priority.
For each audience, list the question they arrive with and the action you want to make easier. Avoid treating every possible visitor as equally important on the homepage.
Show what is working and what is missing
Include the current website, any useful enquiry patterns, and examples of questions your team answers repeatedly. Mark pages that still do their job. A redesign does not have to discard material simply because it already exists.
When sharing a reference, explain the specific thing you like: the reading order, photography, navigation, or way technical information is presented. “Make it like this” leaves too much room for interpretation.
Gather the source material
Send what you have before trying to make it look polished. Existing brochures, slide decks, equipment sheets, and team biographies can be valuable inputs. Note which files are current and who can resolve conflicts between versions.
- A vector logo and any established brand guidance.
- Current service descriptions and equipment information.
- Approved project examples and photography with usage permission.
- Locations, team details, and contact routes.
- Existing documents that customers already find useful.
Separate approved facts from open questions
Mark claims, figures, qualifications, and project references that need a subject-matter review. Identify the person who can approve each area. This keeps design feedback from becoming an accidental review of technical accuracy.
Also record practical constraints: required languages, systems the website must connect to, who controls the domain, and who will maintain content after launch. These affect the work even when they do not appear on a page.
Define what a successful launch means
Agree on a small set of useful checks. Can visitors find the main services? Can the team receive and handle enquiries? Are the important pages usable on a phone? Are essential documents current?
Include accessibility in the review. Keyboard access, meaningful page titles, clear headings, readable contrast, and image descriptions are useful starting points. A quick check can identify obvious barriers, but it is not a complete accessibility assessment.
A starting point for the review: W3C’s introductory accessibility checks.
Keep the first brief short enough to use
One clear page plus a well-labelled source folder can start a productive conversation. Include the decision-maker, any real deadline, and what is still unknown. The first job is to establish scope together, not to pretend every answer is already settled.