How to Approach a Website Redesign: The Process from Requirements to Launch, with Checklists
Shusaku Yosa
A website redesign is usually discussed as a visual refresh, but in practice the outcome is largely decided before production starts, in the requirements phase. Projects that proceed with vague objectives may launch on time yet fail to move the numbers, and a few years later the same discussion begins again. This article lays out the full process from current-state analysis through post-launch operation, the items to settle during requirements definition, and checklists you can use at each phase.
A Redesign Is Decided in the Requirements Phase
Requirements definition is the process of putting in writing what this site is for, who it serves, and what it must be able to do. If that remains vague when design work begins, revisions start coming back for reasons no stronger than personal taste, and both the timeline and the budget expand.
Requirements definition is also not something you can hand off wholesale to an agency. The business goals, the internal operating model, and the constraints of existing systems are all knowledge held by the buyer. An external partner is an expert in execution, not an expert in your objectives.
The Full Process in Seven Phases
The granularity varies with scale, but a redesign generally moves through these seven phases.
Phase 1: Current-state analysis
Use analytics, organic search terms, page-level conversion, the content of inbound inquiries, and interviews with the sales floor to understand where the current site is strong and where it is weak. This is also the point to identify the assets worth protecting, meaning high-traffic pages and URLs with inbound links, which feeds directly into migration planning later.
Phase 2: Objectives and KPIs
It looks dated is not an objective. Translate it into something measurable, such as growing job applications from 200 to 300 a year, or lifting the download conversion rate from 1.2 percent to 2 percent. This KPI becomes the reference point for every decision that follows.
Phase 3: Requirements definition
Settle the structure, content, features, and system requirements needed to reach the objective. The specific items are covered in the next section. If you cannot finalize everything internally, bringing in a consultant or agency to support this phase is a legitimate option.
Phase 4: Selecting a production partner
Turn the requirements into an RFP and invite proposals from roughly three to five firms. Fixing your evaluation criteria and weighting in advance lets you compare proposals on equal terms and makes internal agreement much smoother.
Phase 5: Design (information architecture and visual design)
Set the overall structure with a site map, fix the content and user flow of each page with wireframes, and only then move to visual design. Review designs against the objective set in phase two rather than against personal preference.
Phase 6: Build and testing
Alongside development, CMS setup, and the delivery of copy and images, run rendering checks, form testing, and performance measurement. Copy production tends to become the buyer-side bottleneck, so decide who owns it early.
Phase 7: Launch and ongoing improvement
Apply redirects, verify tracking tags, submit the sitemap to Search Console, and then review your KPIs at one, three, and six months. A redesign is not finished at launch. Launch is where the improvement cycle starts.
Seven Items to Settle During Requirements Definition
1. Purpose and audience
Define who you want to do what. Where several audiences exist, such as prospects, existing customers, job seekers, and business partners, rank them. A site optimized for everyone ends up resonating with no one.
2. Site structure and information architecture
Inventory every page on the current site and sort each into keep, merge, retire, or create new. The work is tedious, but it becomes the basis for estimating content volume and effort, and it carries straight over into redirect planning at migration.
3. Content requirements
Decide how much new copy, photography, and illustration is needed and who will produce it. Assign ownership explicitly, such as photography arranged in-house and copy handled by a contract writer, and build the delivery deadlines into the schedule. Waiting on copy is the single largest cause of redesign delays.
4. Functional requirements
List forms, site search, member areas, multilingual support, case study listings and filtering, and third-party integrations, and mark each as required, preferred, or optional. Having those tiers in place makes it much faster to decide what to cut if the budget is exceeded.
5. Non-functional requirements
Set expectations for page speed, supported browsers and devices, the accessibility standard you will conform to, SSL and vulnerability handling, backup arrangements, and server capacity against expected traffic. Precisely because this area is invisible, it needs to be written down during requirements definition.
6. CMS and operational requirements
Decide up front who will update what after launch. In many cases it is enough to make only the frequently updated areas editable, whereas making every page editable through an admin interface drives build cost up sharply. Sort out permission levels and approval workflow here as well.
7. SEO and migration requirements
Specify how existing URLs will be handled, the 301 redirect mapping, the approach to titles and meta descriptions, heading structure, structured data, and how the sitemap will be generated. Leaving this entirely to the agency risks it falling outside the contracted scope, so treat it as an explicit requirement.
Three Common Ways Redesigns Fail
Organic traffic collapses after launch
The most frequent failure is missing redirects when URLs change. Build a mapping table of old to new URLs and set a 301 for every entry. Sending everything to the homepage is unhelpful to users and to search engines alike, and it will not carry the existing signals across.
The look changed but the results did not
This happens when the objective was simply that the site looked dated. If organic traffic is low the content is thin, and if inquiries are low the issue is in the user flow or the offer. Follow the numbers to identify the cause before deciding what to fix.
Only the launch date was decided first
When the launch is pinned to an anniversary or a trade show and the plan is built backwards from it, the pressure always lands on testing and copy production. If the date genuinely cannot move, consider releasing in stages by priority rather than insisting on redesigning every page at once.
Website Redesign Checklists
Requirements phase
Before launch
At and after launch
Typical Timeline
This depends on page count and feature scope, but for a mid-sized corporate site of roughly several dozen to a hundred pages, the rough guide is as follows.
- Current-state analysis and objective setting: 1 to 2 months
- Requirements definition: 1 to 2 months
- Partner selection: 1 to 2 months
- Design (IA and visual): 2 to 3 months
- Build and testing: 2 to 4 months
In total, six months to a year is realistic. Requirements definition and partner selection in particular are heavily affected by internal coordination and are the hardest phases to compress.
Frequently Asked Questions
Should we handle requirements definition ourselves or leave it to the agency?
Objectives, audience, KPIs, and the operating model have to be decided in-house. Information architecture and technology choices, on the other hand, are specialized enough that outside support makes sense. In practice, most teams organize objectives, problems, and priorities themselves and fill in the rest with a partner.
Is it better not to change URLs?
If you can avoid changing them, that is safer. But a substantial restructuring makes URL changes unavoidable. What matters is less whether you change them and more that, when you do, you build a mapping table, redirect every entry, and keep monitoring after launch.
What should we do if rankings drop right after launch?
Some fluctuation is normal after a large structural change. First check the technical causes: missing redirects, 404s appearing, a leftover noindex, or a reduction in content volume. If none of those apply, watching the trend for a few weeks is the standard response.
Summary
A website redesign moves through seven phases: current-state analysis, objective setting, requirements definition, partner selection, design, build, and launch with ongoing operation. Of these, the two that deserve the most buyer-side effort are objective setting and requirements definition.
Put the seven items in writing, meaning purpose and audience, structure, content, functional, non-functional, CMS and operations, and SEO and migration, and you can compare proposals, make decisions during production, and review results after launch all against the same standard. Start by building a page inventory of your current site.