A website redesign brief should help agencies solve the right problem and price the same scope. Most briefs do neither.
They list pages and visual preferences, but leave out the commercial goal, evidence, content ownership, technical constraints and launch tests. The result is a set of proposals that look comparable while describing different projects.
This guide gives UK businesses a practical website redesign brief that fits on one working page. Complete the first pass in under an hour, then attach the supporting evidence an agency needs.
What the brief needs to achieve
Your brief is not a finished specification. It should create a fair starting point for discovery and make uncertainty visible.
A useful brief answers five questions:
- What business result must change?
- Who must the website help?
- What evidence explains the current problem?
- What must be delivered or protected?
- How will everyone decide the redesign succeeded?
Keep those questions at the centre. A redesign is not successful because stakeholders prefer the new homepage. It succeeds when customers can complete important tasks more easily and the business can measure the difference.
The one-page website redesign brief
Copy this structure into a document and keep the summary to one page. Put analytics exports, content inventories, brand files and technical notes in appendices.
1. Business objective
Write one primary outcome and no more than three supporting outcomes.
We need the redesigned website to help [audience] complete [action], so the business can improve [measurable outcome].
Examples include generating more qualified enquiries, increasing ecommerce conversion, reducing support demand or making a complex service easier to understand.
Avoid “modernise the website” as the main objective. Modernisation may be part of the solution, but it is not a measurable business result.
2. Audience and priority journeys
Name the people the site must serve and what they are trying to do. You do not need fictional persona biographies. You need evidence-backed tasks.
For each priority audience, list:
- the problem or question bringing them to the site;
- the information they need before acting;
- their primary task;
- likely concerns or blockers;
- device, language or accessibility needs;
- what a successful journey produces for the business.
Rank the top three journeys. If everything is a priority, design decisions become stakeholder negotiations instead of customer decisions.
3. Current evidence
Give agencies enough evidence to diagnose rather than guess.
Include:
- analytics for the last 12 months, with obvious anomalies noted;
- Search Console queries, landing pages and indexing issues;
- conversion or lead-quality data;
- common sales and support questions;
- user research, surveys or recorded usability problems;
- pages that attract valuable links or organic traffic;
- technical, accessibility and performance audits;
- known CMS frustrations for editors.
Record a baseline for each important outcome. The GOV.UK Service Manual notes that a measured baseline is useful when evaluating success. Without one, the post-launch review becomes opinion.
4. Scope and deliverables
State what you expect the agency to provide and what your team will provide.
| Area | Questions to answer in the brief |
|---|---|
| Strategy | Is research or discovery included? Who approves the direction? |
| Information architecture | Is the agency restructuring navigation and URLs? |
| Content | Who audits, writes, edits, migrates and signs off each page? |
| Design | Which templates, components and responsive states are required? |
| Development | What CMS, integrations, environments and browser support apply? |
| SEO | Who maps redirects, metadata, canonicals and structured data? |
| Accessibility | What conformance target and testing method are expected? |
| Analytics | Who designs, implements and validates the measurement plan? |
| Launch | Who owns migration, quality assurance, rollback and monitoring? |
| Handover | What training, documentation, warranty and support are required? |
List anything explicitly out of scope. That protects both sides and gives agencies a place to price options separately.
5. Constraints and dependencies
Constraints help an agency design a realistic route, but unexplained preferences can prematurely close off better options.
Include:
- target launch date and why it matters;
- realistic budget range;
- procurement or legal requirements;
- required technology and the reason it is required;
- brand work that is fixed or still changing;
- internal systems and third-party integrations;
- available subject-matter experts;
- decision-makers and expected sign-off time;
- other projects that could affect content, data or launch.
If your budget is not fixed, give a planning range and ask agencies to show what changes across it. Our 2026 guide to website costs in Manchester explains the work that typically changes the price more than the number of pages alone.
6. Success measures
Choose a small set of measures tied to the business objective and user journeys.
Good measures might include:
- qualified enquiries rather than total form submissions;
- completed purchases and revenue rather than traffic alone;
- successful use of a key tool or account journey;
- fewer support contacts for a documented problem;
- organic visibility retained through migration;
- task success and error rate in usability tests;
- Core Web Vitals and accessibility acceptance checks;
- editor time to publish or update priority content.
Separate launch acceptance from longer-term growth. A redirect can be verified on launch day. Organic growth or lead quality needs a review period and context.
7. Definition of done
End the brief with tests, not adjectives.
Instead of “the site should be fast and accessible”, say which pages, devices, metrics and test methods will be used.
Google’s current “good” Core Web Vitals thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, assessed at the 75th percentile. These are useful reference points, but your team and agency should agree the complete performance budget and how it will be measured.
For accessibility, use the W3C WCAG 2.2 standard as the reference and agree the target level, representative journeys, assistive-technology checks and responsibility for remediation. An automated score alone does not prove conformance.
Protect SEO during the redesign
A redesign can change navigation, content, templates, internal links and URLs at once. Treat SEO migration as a deliverable, not a post-launch check.
Your brief should require:
- an inventory of indexable URLs before launch;
- a decision for every valuable page: retain, improve, consolidate or remove;
- a one-to-one redirect map for changed URLs;
- preserved or improved titles, headings, copy and internal links;
- canonical, robots and sitemap validation;
- analytics and Search Console checks;
- monitoring after launch for crawl errors, indexation and traffic changes.
Google’s site-move documentation says to configure server-side permanent redirects from old URLs to new ones and to avoid redirecting many old pages to an irrelevant destination such as the homepage. Put redirect ownership and testing into the schedule before development finishes.
Make content ownership explicit
Content is the most common invisible dependency in a redesign.
For every planned page, assign an owner, source material, writer, reviewer and approval date. Decide whether existing copy will be kept, improved, combined or removed. Include image rights, case-study permissions, legal review and translations where relevant.
Do not approve empty templates and assume the content will fit later. Test priority templates with realistic copy, error messages, tables, long headings and real images. This exposes layout and workflow problems while they are still cheap to solve.
How to compare agency proposals
Ask every agency to respond to the same brief structure:
- their understanding of the problem;
- assumptions and exclusions;
- proposed phases and decision points;
- named deliverables for each phase;
- team roles and senior involvement;
- dependencies on your staff;
- risks and how they will be reduced;
- price by phase, with optional work separated;
- evidence from relevant projects;
- support and ownership after launch.
Do not score proposals on visual polish alone. A strong response may challenge part of the brief, but it should explain why and show how the alternative better protects the outcome.
Website redesign brief checklist
Before sending the document, confirm that it includes:
- one primary business outcome;
- three ranked customer journeys;
- current evidence and baselines;
- deliverables and exclusions;
- content ownership;
- integrations and technical constraints;
- SEO migration ownership;
- accessibility and performance targets;
- analytics and post-launch review;
- budget range, timeline and decision-makers;
- a testable definition of done.
If several boxes remain empty, do not disguise the uncertainty. Ask agencies to price a focused discovery phase that resolves the important unknowns before committing to the full redesign.
A better brief creates a better working relationship
The best website redesign brief is short enough to read, specific enough to price and honest about what is not yet known.
It gives your agency context without pretending you have already designed the answer. It also protects your team from the most expensive redesign failure: launching a nicer-looking website that has not improved the customer journey or the commercial result.
If you want a second pair of eyes before asking for proposals, send DreamWeb your draft brief. We will identify the missing decisions, migration risks and scope assumptions that are likely to distort the quotes.