How to write a useful website design brief
A practical website brief covering goals, users, content, scope and acceptance criteria, with examples that reduce avoidable rework.
Updated: · AI-generated editorial illustration
A website design brief gives the business owner and implementation team a shared problem to solve. It does not need elaborate language. It needs enough specificity to decide which pages matter, what visitors must understand and what an acceptable handover looks like. A request to make something modern like a competitor leaves the team guessing about structure, content and success.
This guide uses an illustrative service studio seeking consultation enquiries. The example is a planning exercise, not a client case study or a revenue promise. Adapt the decisions to your own shop, consultancy or service business before treating them as requirements.
1. Define the problem and the primary action
Describe the current problem through observable evidence: visitors repeatedly ask about price, a service page omits scope or the enquiry form is difficult on phones. Choose one primary action, such as submitting a consultation request. Brand awareness, search visibility, sales and recruitment can coexist, but they need an explicit order of importance.
For example: visitors should understand the landing-page service, review the deliverables and send their existing website for discussion. That sentence already suggests three useful content blocks. A valid enquiry can be an outcome measure, provided the brief explains how validity is confirmed. A button click alone is not a new customer.
2. Describe users through real questions
An audience description such as adults aged 25–45 does little to determine page content. Record questions from calls, emails and messages: can the existing platform be retained, who writes the copy, how are revisions handled and who maintains the website after launch? Separate observations from assumptions that still need checking.
When evidence is limited, hold short conversations with people who resemble the intended audience. Ask how they previously found a similar service, which information was missing and what prevented an enquiry. Avoid leading questions about whether they like attractive websites. Translate the findings into content and tasks rather than a decorative demographic profile.
3. Map pages and content ownership
Create a table with proposed URL, purpose, required material, content owner and readiness. A service page needs scope, conditions and a next step; an article needs an answer, evidence and relevant reading links. Add a page only when it performs a distinct task. Use the website content checklist to identify missing inputs.
Document permission to use images, logos and customer quotations. Without verified assets, use honestly described illustrations rather than invented testimonials. For an existing site, preserve an inventory of current URLs and identify redirect requirements before changing the architecture. The brief should expose dependencies early, especially content that only the business can approve.
4. Turn visual preferences into usable requirements
Choose two or three references and explain the particular feature worth learning from: heading hierarchy, spacing, navigation or interaction. Do not request a wholesale copy. Separate brand elements that must remain, such as colours, logo and voice, from patterns that can change.
Write responsive requirements as behaviour: keyboard-operable menus, readable buttons at enlarged text sizes, labelled forms with understandable errors and images that reserve space. The W3C WAI accessibility introduction explains why different users need different ways to perceive and operate a site. Motion should have a purpose and a reduced-motion alternative, rather than becoming an unchecked aesthetic requirement.
5. Agree scope, dependencies and acceptance
Separate launch essentials, later improvements and exclusions. Specify the platform, integrations, page or template count, bilingual requirements, approver and change process. A polished budget estimate is less useful than knowing who can approve additional work and which dependencies can delay delivery.
Acceptance criteria should be observable: important URLs return the right content, enquiries arrive at the agreed destination, English translations contain all required fields, images are appropriately sized and small screens have no horizontal overflow. Performance requirements need a measurement method, device class and network context. Google's page-experience guidance places usability in a broader context than a single test score.
The handover should include business-owned accounts, update instructions, integration inventory, backups and a support contact. Agree these items before development so a visually successful launch does not leave the business unable to maintain its own website.
Frequently asked questions
How long should the brief be?
There is no fixed page count. A short brief covering goals, pages, content, constraints and acceptance is more useful than a long collection of references. Put technical detail in appendices when necessary, while keeping decisions and ownership easy to find.
Can the same brief be used for multiple estimates?
Yes. Ask each provider to state included work and remaining assumptions. Compare scope, dependencies and handover before comparing price. Estimates covering different template counts or content responsibilities are not directly equivalent.
References and further reading
To apply this to your current website, explore the website service or contact Dean Vu to define a scope around your existing site and actual evidence.