A website redesign becomes manageable when you separate the decision about what must improve from the mechanics of rebuilding every page. Start by naming one release outcome, such as making the service easier to navigate or making the main contact path work better. Treat other ideas as a later backlog unless they are required for safety, legality, accessibility, or basic operation.
Freeze the starting point
Make a page inventory with the current URL, purpose, owner, evidence of use, and planned action: keep, revise, merge, redirect, or retire. Save the current analytics definitions, forms, integrations, domain and hosting details, and a small set of representative screenshots. This creates a baseline and prevents the project from becoming an argument about memory.
Work in one thin slice
Choose a representative journey and prototype only the pages needed to complete it. Use shared components for repeated elements such as buttons, navigation, fields, and alerts. The GOV.UK Design System describes components as reusable interface parts and says its examples should be tested with user research before being adopted for a specific service. That is a useful operating rule even when you use a different design system: reuse patterns, but verify them with the people who must use the site.
Test the thin slice for content clarity, keyboard operation, small-screen behavior, form completion, error handling, and the business handoff that follows a submission. Record findings as changes to make, not as open-ended discussion. Assign each accepted change an owner and a release.
Separate a redesign from a site move
If URLs, domains, hosting, or the content-management system will also change, make that work explicit. Google Search Central recommends changing one major thing at a time when possible, preparing and testing the new site, mapping old URLs to their new destinations, implementing server-side permanent redirects, and monitoring both old and new URLs. A redesign board should therefore have a distinct migration checklist rather than hiding redirects and indexing work inside design tickets.
Use a short release gate
Before launch, require the owner to confirm the page inventory, redirect map, form destinations, analytics definitions, accessibility checks, rollback owner, and monitoring window. Launch the smallest coherent release, check important journeys and redirects from outside the editing environment, then review real errors before expanding the scope.
This workflow is intentionally plain: one outcome, one inventory, one prototype slice, one migration plan, and one release gate. Complexity that does not help those five artifacts should be deferred, documented, or removed.
Sources used
Sources
- Site Moves and Migrations — Google Search Central
- Prototyping — GOV.UK Design System