Plan a website redesign from current-site evidence rather than visual preference alone. This guide gives a practical sequence for documenting audiences, journeys, content and URL decisions, defining scope and acceptance checks, preparing a controlled launch, and establishing measurement before build. It includes an evidence-to-decision worksheet for a decision-ready redesign brief.
- Use current-site evidence to decide what the redesign must change.
- Map content and pages to priority user journeys, not just menu labels.
- Turn findings into owned scope items and acceptance checks.
- Prepare URL mapping, launch QA and measurement definitions before release.
Decide what must change before designing it
A website redesign is worth planning when the current site no longer helps people complete an important task, no longer represents the business accurately, or cannot support a needed content, technical or measurement change. Start with proof from the existing site, then define the future experience. Starting with visual references alone can preserve the same unclear journeys, weak content or unmeasured outcomes.
Treat the project as a set of decisions: which audiences and tasks matter, what content earns a place, what must remain findable, what integrations are required, and how launch will be checked. This guide is about pre-project planning, rather than responsive implementation or a provider service description.
Build a small current-site evidence pack
Collect enough evidence to explain why a change is needed. The aim is not a long audit. It is a shared record of what people try to do, where the current experience creates friction, and which assets or URLs cannot be lost. Separate observations from assumptions so decisions can be revisited honestly.
- Business goal: state the change the site should support, such as qualified enquiries, product discovery or self-service.
- Priority audiences and tasks: write what each audience arrives to do and the shortest useful path.
- Current evidence: capture analytics, search queries, customer questions, support feedback and observed dead ends.
- Content and URL inventory: mark pages, downloads, forms and media as keep, improve, combine, retire or redirect.
- Dependencies: record CMS, forms, consent, CRM, payment, booking, language and hosting requirements.
- Accessibility observations: note keyboard access, focus states, headings, alternative text and form feedback.
Use accessibility as a review lens
The Web Content Accessibility Guidelines are a technical standard for making web content more accessible to people with disabilities. W3C groups WCAG 2.2 around content being perceivable, operable, understandable and robust. Use those principles to make testable design and content requirements, then agree a conformance target appropriate to the organisation and applicable obligations.
Map content to journeys, not navigation labels
For every priority task, sketch the entry point, information needed to proceed, action, confirmation and next step. A journey may begin in search, an ad, an email or a bookmarked URL rather than on the home page. This exposes missing reassurance before a form, repeated content, an unclear page purpose or an integration that belongs in scope.
Use an evidence-to-decision worksheet
Add a worksheet row only when evidence changes a design, content, technical or launch decision. A blank owner or acceptance check is a sign that the item is not ready to scope.
| Current signal | Decision | Scope impact | Owner | Acceptance check |
|---|---|---|---|---|
| Visitor question or observed obstacle | Keep, change or add information or a step | Content, UX or integration work | Named business owner | A representative user can complete the task |
| Existing URL with a continuing purpose | Keep the URL, replace it or redirect it | Content migration and redirect mapping | Content and technical owners | The destination is relevant and tested |
| Desired outcome | Define the action or event to record | Measurement implementation and QA | Measurement owner | The event is visible and has agreed meaning |
Fictional example: visitors repeatedly ask what happens after an enquiry. The decision is to add a concise process explanation beside the enquiry action, assign its content owner, and check that it appears on every relevant entry page before launch. That creates a testable scope item, unlike a vague request to make the site more trustworthy.
Turn decisions into an honest scope
A useful scope names deliverables and boundaries. Separate work required for launch from possible follow-on work. For each page template, integration, migration item and measurement event, specify who supplies inputs, who approves it and what proves it is complete. This makes it easier to compare proposals against the same work rather than an ambiguous feature list.
- Which content is supplied, edited or newly created, and who signs it off?
- Which existing URLs, forms, integrations and tracking rules are included?
- Which devices, browsers, user roles and critical journeys will be tested?
- What is handed over for CMS access, source files, documentation and account ownership?
- How is a request handled when it adds work after scope is agreed?
A plan cannot remove every uncertainty. Legacy integrations, data quality, approval delays and third-party platforms can change the work. Record these as assumptions, dependencies or decisions to be made, rather than promises. A redesign brief should clarify what is known and make unknowns visible early.
Prepare a controlled launch
A redesign can preserve URLs, change some paths or move to a new domain. When URLs change, create an old-to-new map before launch. Google recommends server-side permanent redirects where possible, direct destinations rather than chains, updated internal links and a new sitemap. Test representative redirects before switching traffic, then monitor indexing and crawl errors.
- Check the redirect map against important old URLs and confirm each destination is relevant.
- Review page status, canonical signals, internal links, sitemap and index controls on the live environment.
- Test forms, confirmations, CRM or email handoff, consent choices and payments or bookings with safe test data.
- Walk critical journeys on representative screen sizes and with keyboard-only navigation.
- Assign owners for errors, form delivery, search visibility and key events after release, with a rollback decision path.
Define measurement before build
Decide which actions indicate that a priority journey worked, then define each action in plain language. Google Analytics documents optional recommended and custom events for behaviours not collected automatically. Measurement therefore belongs in the brief: the page, form and confirmation state should support a clear event and a meaningful review of it.
- Business question: what decision will this signal inform?
- Event and trigger: what completed action should create it?
- Context: which page, content type or enquiry category is needed to interpret it without collecting unnecessary data?
- Validation: who checks that the event fires once, has expected context and is visible in reporting?
Make the brief decision-ready
Before asking a team or provider to estimate the work, assemble the evidence pack, priority journeys, page and URL decisions, scope boundaries, acceptance checks, measurement definitions and launch responsibilities. Ask prospective partners to identify assumptions, content dependencies, testing approach, ownership at handover and exclusions. Those answers are more comparable than generic assurances because each responds to the same decision record.
This is not a fixed recipe or a promise of search, conversion or accessibility results. It is a practical record of why the redesign exists, what must be true at launch and how the organisation will learn from the new site.
This guide was prepared with AI-assisted, source-linked research. Examples are illustrative; confirm current platform settings and policies for your own business.
Fresh thinking from Technogital.
Let’s put it into action.
