A redesign brief should help a delivery team make decisions, not prescribe a new coat of paint. This structure captures outcomes, audiences, content, constraints, integrations, governance, migration and acceptance in one working document.
A useful redesign brief creates a shared starting point for marketing, leadership, IT, legal, procurement and the delivery partner. It explains why change is needed, what success means and which decisions are already fixed. It does not need to solve the design in advance. Copy the headings below into your working document and replace the prompts with evidence.
1. Organisation and decision context
- What does the organisation do, for whom and in which markets?
- Why is the redesign being considered now?
- Which decisions have already been approved?
- Who sponsors the work, manages it and signs off each discipline?
- Which dates are real constraints, and what creates them?
2. Outcomes and measures
State three to five outcomes in observable terms. Examples include more qualified enquiries, more completed applications, fewer support calls about routine information, faster publishing, stronger recruitment conversion or lower mobile abandonment. Record the current baseline, target, data source, review period and owner. Do not make page count the primary measure of success.
3. Priority audiences and tasks
For each audience, name the situation that brings them to the site, the questions they need answered, the action they should be able to complete and the evidence that builds confidence. Prioritise. A website that treats investors, buyers, applicants, partners, journalists and existing customers as equally important on every page usually serves none of them clearly.
4. Current-state evidence
- Analytics by device, geography, entry page and meaningful action.
- Search queries and pages with impressions but weak engagement.
- Form completion, validation and delivery failures.
- Customer-service questions that content should answer.
- Publishing delays and editor pain points.
- Accessibility, performance, security and content audit findings.
- Stakeholder feedback labelled as evidence, assumption or preference.
5. Content scope and governance
List content types, languages, owners and approval routes. Decide what will be retained, rewritten, consolidated, archived or created. Name the subject expert and final approver for each area. Include legal pages, metadata, media alternatives, downloads, navigation and error messages. Set a content freeze and migration review process.
6. Functional and integration requirements
Describe the user outcome for forms, search, applications, payments, maps, newsletters, CRM handoff, authentication and other integrations. For each, note the system of record, required fields, consent, failure behaviour, owner and test account. Avoid writing only the vendor name because that does not define the workflow.
7. Quality constraints
| Area | State in the brief |
|---|---|
| Accessibility | Target, such as WCAG 2.2 AA, and testing responsibility |
| Performance | Representative pages, devices and measurable budgets |
| Privacy | Data collected, lawful basis, retention and request handling |
| Security | Authentication, authorisation, uploads, dependencies and verification |
| Responsive design | Priority devices, content behaviour and touch requirements |
| Browser support | Named support policy based on audience evidence |
| Editing | Roles, content types, preview, workflow and audit needs |
8. URL and search migration
Inventory existing URLs, valuable search pages, backlinks, canonical tags and structured data. Map every retained or consolidated URL to its intended destination and test redirects before launch. Preserve content meaning where it still serves users. Google's site move guidance is a useful reference for URL changes, redirects, sitemaps and monitoring.
9. Delivery, acceptance and launch
- Phases, decision gates and named deliverables.
- Client and supplier dependencies with due dates.
- How scope changes are proposed and approved.
- Acceptance criteria for every important workflow.
- Content, accessibility, performance and security verification.
- Redirect, analytics, form and integration checks.
- Launch authority, rollback conditions and incident contacts.
- Warranty, maintenance, training and final handover.
10. Commercial and ownership terms
State the budget authority or approved range if your procurement process permits it. Separate build, licences, hosting, content, maintenance and optional work. Require clarity on intellectual property, third-party components, domain and account ownership, source access, data export, recurring costs and exit assistance.
Avidni's business website service can turn this brief into a validated information architecture, content plan and delivery scope.
Review a Redesign Brief