WEB / TEMPLATE · 12 min

Website Redesign Brief Template

Updated October 15, 2026

Plan a brand-led website redesign with an editable brief, scope and migration worksheets, evidence requirements and clear launch acceptance criteria.

A useful brief reduces uncertainty—not creativity.

A website brief should not prescribe every layout before the project begins. It should make the business problem, audience, evidence, constraints and definition of success clear enough that a capable team can propose the right system.

Without that shared baseline, one proposal may include positioning, copy, analytics and migration while another prices only visual design and page assembly. The totals look comparable, but the products are not.

For an established hotel, architecture practice, design studio or specialist brand, the website must represent the business accurately as well as make the next step easy. A strong brief explains what deserves a distinctive treatment, what buyers need to verify, and which existing search and operational assets must survive the redesign. It does not assume that a more expensive-looking website alone creates demand.

• Open the editable redesign brief and worksheets (.txt; no signup)

Copy this one-page website redesign brief.

• Business: What do you sell, to whom, in which markets, and what makes the business commercially different?
• Reason for redesign: What is failing now—positioning, trust, lead quality, mobile experience, editing, speed, search visibility or technical reliability?
• Primary audience: Who must immediately recognize that the site is relevant? Include location, company type, urgency and purchase context.
• Primary conversion: What is the single most valuable next step—qualified form, booked call, estimate request, purchase, application or account creation?
• Qualification: What information is truly required before the team can respond usefully? What should disqualify an inquiry?
• Evidence: Which reviews, case studies, credentials, guarantees, customer data and first-party examples can be verified and published?
• Required pages: List only the routes already known to be necessary. Let the proposed information architecture solve the rest.
• Required functionality: Forms, booking, CRM, payments, accounts, search, multilingual content, calculators, uploads or internal workflows.
• Content ownership: Who researches, writes, approves, translates and migrates the copy, images, video and downloadable material?
• Brand inputs: Which identity assets exist, what must remain, and where is a new direction allowed?
• Technical constraints: Domain, hosting, CMS, analytics, consent, accessibility, security, integrations and internal maintenance requirements.
• Measurement: Name the events and commercial outcomes that must be observable after launch.
• Timeline: State the real deadline, why it matters, who approves work and how quickly feedback can be returned.
• Budget context: Give a planning range or ask for clearly separated scope options instead of forcing teams to guess.

Translate premium positioning into evidence and a buyer journey.

The following are hypothetical briefing situations, not client projects, live offers or measured outcomes. They show why the same premium label can require very different content and functionality. Choose the journey your business actually supports; do not combine every feature into one scope.

• Give each image, testimonial and project claim an owner, permission status and approval date. A placeholder is not approved evidence.
• Explain what a design reference demonstrates: image direction, typography, pace or navigation. Do not ask the team to copy another brand's identity.
• Specify where motion improves understanding and the still/reduced-motion alternative. Important information and enquiry actions must remain available without watching a film.
• Describe a suitable enquiry through actual project fit and capacity, not luxury vocabulary or the visitor's country alone.

• See our real websites and applications, with concepts clearly labelled

Add the numbers that shape the conversion system.

The design team does not need confidential financial statements, but it does need enough commercial context to avoid optimizing for the wrong action. A company selling a $250 service has a different qualification threshold and follow-up path from one selling a $25,000 engagement.

Make scope decisions visible before comparing fees.

Turn each requirement into a decision row: outcome, existing evidence, proposed deliverable, acceptance test, owner and scope status. Mark unknowns explicitly. Ask agencies to price the same launch baseline and separate optional work, third-party subscriptions, content production and ongoing support.

For example, a hotel might retain its existing booking engine while replacing the marketing website. The brief should name who controls booking configuration, how the transition is tested and what can actually be measured across domains. A new booking engine is a separate product decision, not an assumed part of visual redesign.

• Decide whether the existing system needs a redesign or a rebuild

Attach a search and migration inventory, not a promise of preserved rankings.

Before changing URLs, inventory the current pages and identify valuable search entry points, linked resources and essential customer journeys. Record an explicit keep, improve, consolidate, redirect or retire decision for each affected URL, with the proposed destination and an accountable owner. Do not redirect unrelated retired content to the homepage merely to avoid a missing-page response.

If URLs change, include relevant permanent redirects, updated internal links and sitemap entries in launch scope. Verify canonical and indexing directives on the final pages, and make sure staging restrictions do not accidentally reach production. Google's site-move guidance explains why recrawling and ranking changes can take time; no brief or launch checklist can guarantee unchanged positions.

Growth Scan can supply a starting list of technical findings. It is not a complete crawl, a Search Console index report, an accessibility certification or a substitute for testing booking and lead delivery. Combine it with the business's actual search, content and operational evidence.

• Use Growth Scan as a starting diagnostic

Define launch acceptance before design begins.

Acceptance criteria prevent the final week from becoming a debate about whether the project is finished. They should describe observable behavior, ownership and testing—not subjective promises such as “modern,” “premium” or “high converting.”

• Every agreed route renders correctly on current mobile and desktop browsers.
• Primary forms are submitted end to end and received in the correct inbox or CRM.
• Required analytics events appear in the live measurement property.
• Page titles, descriptions, canonical URLs, robots rules and sitemap entries are present.
• Old URLs have an approved redirect or removal decision.
• Content owners have approved the final claims, legal text, images and credentials.
• Keyboard navigation, labels, contrast and motion preferences have been reviewed.
• Domain, hosting, source files, analytics and third-party accounts are owned by the business.
• The team receives a launch record covering known limitations and post-launch responsibilities.

Keep launch scope separate from the growth backlog.

Not every useful idea belongs in version one. Mark each requirement as launch-critical, post-launch experiment or future capability. This protects the deadline without silently deleting valuable work.

A launch-critical item is necessary for the offer to be understood, trusted, submitted, delivered or measured. A growth experiment needs live traffic or sales feedback before it can be judged. A future capability depends on a later operational decision, data source or budget.

Compare proposals with the same five questions.

The strongest proposal is not necessarily the one with the most pages or the lowest total. It is the one that demonstrates a credible route from the documented business problem to a usable, measurable launch—and makes its assumptions visible before work begins.

• What assumptions does this proposal make about strategy, copy, content and approvals?
• Which deliverables and integrations are explicitly included?
• What is excluded or billed separately?
• Who owns implementation, launch QA and post-launch defects?
• How will the business verify that forms, analytics and search foundations work?

Sources

• Google Search Central — Site moves with URL changes