Website Design Brief: Start With Decisions

A website design brief starts with one decision

The fastest way to waste a website budget is to begin with "five pages, modern look, launch in June." That describes inventory, taste and a date. It does not tell a designer what a visitor must understand, trust or do.

Start with one visible decision. A prospective buyer may need to decide whether a service fits their problem, whether the team is credible, and how to start a conversation. Name the audience, the situation that brings them to the site, the evidence they need, and the action that completes the journey.

For example, a B2B software company might write: "An operations lead comparing three tools must understand which workflow we replace, see how implementation works, and book a technical review." That sentence gives strategy, content and design something testable. A list of Home, About and Solutions does not.

Write the job before the page list

Pages are containers. The brief should first map the user's questions in the order they arise. GOV.UK's service guidance recommends looking from the beginning to the end of a task, including the internal processes and other channels behind the screen. A commercial website deserves the same discipline even when its main outcome is a qualified enquiry rather than a transaction.

Imagine an architecture studio. The priority visitor may arrive with a location, a project type and a rough timeline. They need to see relevant work, understand the studio's role, learn what information is needed, and find a credible next step. Those needs might produce a project index, a filtered case page and a short enquiry flow. The structure follows the job instead of a competitor's navigation.

Bring proof, not brand adjectives

Design can make evidence easier to notice. It cannot manufacture the evidence. Collect approved facts before asking a studio to turn "trusted," "innovative" or "leading" into a visual system. Useful inputs include service details, product screenshots, process steps, named credentials, policies, locations, original research and client material you have permission to publish.

Take a consultancy that wants to look more authoritative. Three adjectives and a stock photograph leave the design team guessing. A clear explanation of the engagement process, two approved deliverables, an author with relevant experience and a documented point of view let the site show authority without pretending.

Google's people-first content guidance asks whether a page offers original information, clear sourcing and enough substance to help a visitor achieve a goal. Put that question in the brief. If the required proof does not exist, mark a content task or reduce the claim. Do not let visual polish write cheques the business cannot cash.

Name owners before asking for an estimate

A website estimate depends as much on decisions and inputs as on screens. The brief should name who approves scope, who owns copy, who supplies assets, who checks legal claims, who grants technical access, and who accepts the release. Unknown ownership becomes waiting, rework or a suspiciously optimistic quote.

Picture a multilingual launch. If nobody owns the translated copy, the design may be approved with short English placeholders and break when the real German headings arrive. Record languages, source language, translator, approval path and the longest likely labels before layouts are treated as final.

Add constraints that change the work: existing CMS, analytics, consent tools, CRM forms, authentication, data residency, browser support, migration volume, launch dependencies and internal security review. Separate a real constraint from a preference. "Must remain on this CMS because six editors use it daily" is useful. "Use the current CMS because we already have it" may still deserve a challenge.

Make acceptance observable

Replace "fast, accessible and SEO friendly" with checks somebody can run. Name the priority journeys, devices and content states to test. State the accessibility target and who verifies it. Require titles, descriptions, canonicals, crawl rules, structured data where appropriate, redirects and a sitemap as deliverables, not as a fog called SEO.

W3C's planning guidance treats accessibility as shared work across marketing, design, development, quality assurance and purchasing. A brief can make that real: the content owner writes descriptive links, design covers focus and error states, development uses semantic controls, and acceptance testing includes keyboard and screen-reader checks.

Measurement needs the same specificity. GOV.UK recommends combining performance metrics with user research rather than relying on analytics alone. For a lead-generation site, the release plan might verify form completion, error recovery, qualified enquiries and whether target users can find the right proof. A traffic graph cannot tell you whether the right person understood the offer.

Keep unknowns visible in the buying process

A serious objection is that a detailed brief can freeze the solution before discovery. That happens when the document prescribes layouts, technology and features while the problem is still uncertain. The answer is not a thinner brief. It is to label what is fixed, what is assumed and what the project must learn.

Suppose a team believes visitors need an interactive calculator. The business goal and audience may be fixed, while the calculator is only a proposed answer. The brief should say what decision it is meant to support and what evidence would justify building it. A prototype might show that a comparison table and a call with a specialist work better.

Ask studios to price the uncertainty honestly. One option may cover a short discovery and prototype before the build scope is fixed. Another may proceed directly because content, journeys and constraints are already proven. Compare suppliers on the questions they surface and the exclusions they state, not only on the confidence of the proposal. A website redesign strategy should decide why and when to change; this brief decides what the chosen project must resolve.

Website design brief checklist

• Name the business outcome, priority audience, triggering situation and main user decision.
• Describe the current journey, its evidence and the friction worth changing.
• List approved facts, proof, assets, content gaps and publication rights.
• Assign scope, copy, asset, legal, technical and release owners.
• Record integrations, migration, languages, security, privacy and operational constraints.
• Separate fixed decisions, assumptions to test, exclusions and later opportunities.
• Define observable checks for journeys, content, accessibility, search, performance and analytics.
• Agree the approval path, launch dependency, handover and post-launch review.

If evidence is missing, use a focused UX audit to find friction, a website accessibility audit to assign remediation, or a technical SEO audit to establish a baseline. When the decision, proof and constraints are ready, send Seuil the brief. We can turn it into the smallest credible scope instead of decorating uncertainty.