How to Write a Website Brief That Produces Better Work

The brief should align the problem, not imitate a specification

A website brief gives potential partners enough context to understand the work, expose uncertainty, and propose a responsible next step. It is not a list of fashionable features or a substitute for discovery.

The best briefs are specific about the business and users, honest about constraints, and open about what remains unknown.

Start with a one-paragraph project summary

Write four or five sentences covering:

1. who the organisation is;
2. what is changing;
3. why the current website is insufficient;
4. what the project must enable;
5. why it matters now.

Example:

> We are a specialist manufacturer selling through distributors in six European markets. The current website is organised around internal product codes, so buyers struggle to identify the right system and sales teams repeatedly answer questions the site should resolve. We need a multilingual website that reorganises the catalogue around buyer tasks, connects technical evidence to each product family, and gives regional teams a controlled publishing workflow before the new range launches in October.

That paragraph is more useful than twenty adjectives about how the new design should feel.

1. Background: what led here?

Give the team the history required to avoid repeating it.

Include:

• what the organisation sells or provides;
• how customers currently discover and choose it;
• the role the website plays in that journey;
• relevant changes to product, market, brand, or operations;
• what has already been tried;
• why the project has become a priority.

Keep general company history short. The agency needs context that changes a project decision.

2. The current problem

Describe observable problems rather than prescribing redesign features.

Useful evidence might be:

• visitors repeatedly contact sales for information that exists but is difficult to find;
• a high-value organic landing page has no path to the relevant service;
• editors build inconsistent layouts because the CMS has no structured content types;
• mobile form completion is materially weaker than desktop;
• updating product data requires changes in three disconnected systems;
• the brand has changed but the site still represents the previous offer.

Separate facts, informed observations, and assumptions. “Customers cannot understand our pricing” is a hypothesis until interviews, enquiries, behaviour, or testing support it.

3. Objectives and non-objectives

List three to five outcomes the project should influence.

Good objectives are directional and testable:

• make the relationship between three service lines understandable;
• help a qualified buyer reach relevant evidence within two navigation choices;
• let editors publish case studies without assembling layouts manually;
• preserve valuable organic landing pages during the migration;
• meet agreed performance and accessibility standards across core templates.

Then list what the project is not solving. For example, the website may not include a customer portal, rebrand, CRM replacement, translation service, or ongoing acquisition campaign.

Non-objectives protect the work from adjacent ambition.

4. Priority audiences and tasks

Name the audiences in priority order. For each one, state:

• the context bringing them to the site;
• the important question or task;
• the evidence they need;
• likely objections;
• a useful next action.

Avoid demographics that do not affect design. A procurement lead's approval constraints matter; their invented favourite coffee does not.

If internal users will operate the CMS, include them. Editorial workflows are part of the product.

5. Existing evidence

Summarise what is known and link to the source material:

• analytics and conversion data;
• Search Console queries and landing pages;
• customer interviews or usability tests;
• sales and support themes;
• content inventory;
• accessibility or performance audits;
• CRM outcomes;
• competitor or market research.

Do not paste an analytics export into the brief and call it insight. State what the team believes the evidence suggests and where interpretation remains uncertain.

6. Content and information architecture

Describe the content the site contains or needs, without finalising the sitemap prematurely.

Include:

• current URL or page count;
• likely content types such as services, products, cases, articles, people, locations, or reports;
• content that must be retained for search, legal, or operational reasons;
• known gaps;
• migration volume;
• languages and regional variation;
• who writes, reviews, approves, enters, and translates content.

If a draft sitemap exists, label it as a starting hypothesis. A qualified team may find a structure that better reflects user tasks.

7. Functionality and integrations

Describe the user need and business rule before naming a feature.

Instead of:

> Add an advanced filter.

Write:

> Buyers need to reduce roughly 400 products by application, environment, certification, and regional availability. The existing product database is the source of truth and exposes an API.

For each important function, note:

• who uses it;
• what starts the interaction;
• the successful outcome;
• data required;
• external systems involved;
• permissions or failure conditions;
• what can wait until a later release.

This gives teams room to propose the simplest responsible solution.

8. Brand and experience direction

Provide current brand assets and explain what is fixed, flexible, or missing.

Reference sites can help when each reference includes a reason:

• “This report library makes a large archive easy to scan.”
• “This product comparison exposes differences without forcing a sales call.”
• “This editorial system gives long technical articles a clear rhythm.”

“Make it look like Apple” communicates aspiration without usable criteria. Describe the quality you value and the problem it solves.

9. Technical and operational constraints

List decisions the project must respect:

• required or prohibited platforms;
• hosting and data-residency rules;
• security or procurement review;
• accessibility target;
• supported browsers and devices;
• privacy and consent requirements;
• integrations and sources of truth;
• internal engineering capability;
• deployment and approval processes;
• maintenance expectations.

Explain the reason where possible. An inherited preference can be reconsidered; a contractual or regulatory obligation cannot.

10. Scope priorities

Use three levels:

This is more useful than marking every requested item “high priority”. It also gives teams a way to protect the date or budget without cutting quality across everything.

11. Stakeholders and decision process

Identify:

• the accountable decision-maker;
• day-to-day project lead;
• content owner;
• technical owner;
• specialist reviewers such as legal, security, or regional teams;
• who approves each stage;
• how feedback will be consolidated;
• expected review turnaround.

An agency can manage tasks. It cannot resolve an internal authority problem the brief refuses to acknowledge.

12. Budget and commercial boundaries

Provide a realistic range, ceiling, or phased investment model. The budget tells teams which solution class is responsible.

If the budget is genuinely unknown, share the business constraint and ask for options: for example, a focused first release, a complete programme, and the trade-offs between them.

State whether the range must also cover copy, photography, translation, hosting, third-party licences, maintenance, taxes, and contingency.

13. Timeline and immovable dates

Explain the date, not just the date itself.

Include product launches, campaigns, events, expiring contracts, funding milestones, internal freezes, holidays, and approval windows. Separate a desired date from a deadline with real consequences.

If date and budget are fixed, make scope priorities explicit. The project needs somewhere responsible to absorb uncertainty.

14. Success and baseline

Choose measures connected to the stated problem:

• qualified enquiry completion;
• task completion in usability testing;
• movement between relevant content and service pages;
• organic visibility for a defined topic set;
• publishing time for editors;
• Core Web Vitals by template;
• accessibility defects;
• search usage and successful result selection.

Record the present baseline before the old site changes. Success measures guide decisions even when the website is not the only factor influencing the final number.

Copy-and-use website brief template

``text 1. Organisation and project summary 2. Why this project, and why now 3. Current problems and supporting evidence 4. Objectives 5. Non-objectives 6. Priority audiences, questions and tasks 7. Existing research and data 8. Content types, gaps, migration and ownership 9. Required functionality and integrations 10. Brand assets and experience principles 11. Technical, legal and operational constraints 12. Must launch / valuable next / explore first 13. Stakeholders, decision-maker and review process 14. Budget range and included costs 15. Timeline, dependencies and fixed dates 16. Success measures and current baseline 17. Links, access owners and supporting material 18. Open questions the selected team should resolve ``

Aim for five to ten useful pages, not a performance of completeness. Link to detailed evidence rather than burying it in the main document.

Common questions