A website redesign brief helps stakeholders agree on what needs to change and how success will be judged. Without a shared brief, teams can spend time debating visuals while important requirements such as content migration, lead tracking, accessibility or integrations remain unclear.
1. Define the reason for the redesign
Describe the business problem and the evidence behind it. The trigger may be a confusing user journey, outdated content, poor mobile usability, difficult publishing workflows or a change in services. State the intended outcome rather than relying on a vague goal such as making the website look more modern.
Reviewing project requirements and website layout (Pexels)
2. Identify audiences and key tasks
List the main audiences and what each needs to accomplish. Examples include comparing services, reviewing evidence, finding support or completing a purchase. Prioritize a small number of important journeys so the design and development team can test them end to end.
3. Define scope and constraints
List page types, features, integrations, languages, content needs and technical dependencies. Separate must-have requirements from optional enhancements. Record constraints such as the existing CMS, hosting environment, product catalog size, accessibility expectations, launch deadline and available content resources.
4. Document content and migration needs
Inventory current URLs and decide which pages to retain, improve, consolidate, redirect or retire. Identify high-value landing pages, important backlinks and content that must remain accurate. Define who supplies copy, product data, images and approvals. Include redirect mapping and post-launch indexing checks when URLs or templates change.
5. Set design and functionality requirements
Provide brand assets and examples that explain the qualities you want, such as clearer navigation, better product imagery or simpler forms. Describe functionality in testable terms. For example, a filter should update the product set, preserve understandable state and remain usable on mobile, not merely “work like a modern store.”
6. Agree on measurable acceptance criteria
Specify how the team will confirm completion. Criteria can cover page templates, responsive behavior, form delivery, analytics events, accessibility checks, redirects, performance testing and content approval. Avoid treating a single performance score or design screenshot as proof that the whole site is ready.
7. Clarify roles and decisions
Identify the project owner, content approver, technical contact and final decision-maker. Agree on how feedback is collected and how scope changes are assessed. A clear approval process prevents conflicting instructions and makes timeline trade-offs easier to resolve.
8. Plan launch and support
Include staging, backups, launch checks, rollback criteria, training and post-launch monitoring. Decide who can approve the release and who responds if a critical form, payment flow or page template fails. Confirm ownership of accounts, code, content and documentation.
Brief section
Deliverable
Goals
Business problem and success measures
Audience
Priority users and tasks
Scope
Page types, features and exclusions
Migration
URL inventory, content decisions and redirects
Acceptance
Testable requirements and sign-off process
Launch
Backup, rollback and monitoring plan
Frequently asked questions
Do we need final designs before writing the brief?
No. The brief defines goals and requirements. Detailed design can be developed later if it is part of the agreed project scope.
Who should own the brief?
A business-side project owner should coordinate it with marketing, content and technical stakeholders so requirements are not decided in isolation.
Start with a shared definition of success
A clear brief makes design decisions easier to evaluate and gives the team a common reference through launch. Feed Flow’s web development services can help translate business goals into project requirements and implementation steps.
