Start with the change behind the project
Explain why the project exists now. Describe changes in services, customers, markets, sales process or internal ownership. Name the primary commercial outcome and how a qualified enquiry differs from an unsuitable one.
Include the current URL and what should be preserved. Existing content, rankings, integrations and familiar customer journeys are assets or constraints that a supplier cannot infer from a mood board.
- Business change and deadline
- Priority service and buyer
- Current strengths and failures
- Observable outcome after launch
Describe content by buyer task
List required pages and the question each page must answer. For every important claim, name the available evidence: process detail, credentials, approved testimonial, project photography, specification or primary source. Mark missing material and its owner.
Separate mandatory language versions from possible later phases. Translation affects review capacity, navigation, forms, metadata and ongoing governance, not just word count.
- Proposed page and purpose
- Source material and proof owner
- Required language versions
- Content approval responsibility
Record integrations, governance and constraints
Identify forms, booking tools, CRM destinations, analytics, consent requirements, hosting, domains and access constraints. State who will maintain the site and which changes that person must be able to make without development support.
Describe requirements as outcomes where possible. ‘Send accepted enquiries to the sales owner with service and language context’ is more useful than demanding a plugin before the workflow has been discussed.
- Form and follow-up workflow
- Analytics and consent setup
- Domain, hosting and access
- Editing roles and handover needs
Make proposals comparable
Ask respondents to state assumptions, exclusions, stages, client inputs, approval points and launch responsibilities. Request an explanation of how redirects, mobile checks, forms, metadata and measurement will be verified.
Set evaluation criteria before proposals arrive. Weight understanding of the problem, quality of the proposed process and maintainability alongside price and schedule. A polished mock-up does not answer who will produce content or protect existing URLs.
- Deliverables and exclusions
- Milestones and review windows
- Acceptance and launch checks
- Ownership after handover
Frequently asked questions
Frequently asked questions
How detailed should a redesign brief be?
Detailed enough to explain the problem, scope boundaries, required inputs and decision process. Leave room for a qualified provider to recommend the information architecture and implementation approach.
Do we need final copy before requesting a proposal?
No, but identify who will create and approve it, which source material exists, and which languages are required. Content uncertainty should be visible in the scope.
What should we provide about the existing site?
Provide the URL, analytics where available, valuable pages, known technical constraints, integrations, access ownership and anything that must be retained for legal or operational reasons.