A website redesign is a project hypothesis: changing a page or journey should help people complete a defined task without damaging what already works. New colors and components may be part of the answer, but they do not tell you whether visitors can find delivery terms, complete a form, or navigate on a phone.
The practical work starts before a designer opens a canvas. Define the problem, capture a baseline, choose the smallest change that can test your idea, and plan how to protect existing URLs and data. This guide walks through the decisions and the measurements.
Start with the user task
Replace a vague objective such as "make the site modern" with a description of a job someone needs to complete. For a service page, that could be understanding the conditions and sending an inquiry. For a shop, it might be choosing the right product variant and completing checkout. For a publication, it might be finding and reading a relevant article.
Write down the business objective, the user task, a primary measure, and a guardrail. A shorter form, for example, may increase submissions while removing information the team needs to help the customer. Track the quality of inquiries alongside the submission rate.
Also decide who owns the decision, how long the team will observe the result, and what would trigger a rollback. That makes the project easier to evaluate when opinions differ after launch.
Audit the existing experience
Make an inventory of important landing pages, navigation routes, forms, search, product pages, contact information, and integrations. For each important page, record its purpose, current URL, relevant traffic sources, and the action it supports. Include content that people already rely on, not only the elements you intend to replace.
Then inspect real journeys on both mobile and desktop. Test with long headings, empty search results, error messages, unavailable products, and slower connections. Try keyboard navigation and check whether the focused control remains visible. Verify that images with a meaningful role have appropriate text alternatives.
Ask a few people who resemble your intended audience to complete specific tasks without coaching. Record where they hesitate, what they expect, and whether they succeed. A small qualitative study is useful for finding problems; it does not estimate how often every visitor experiences them. Avoid collecting unnecessary personal data and use agreed test accounts.
Support tickets, sales questions, and internal feedback can add useful clues. Treat each clue as a starting point for investigation rather than proof that one design change will fix the issue.
Capture a baseline before changing anything
Save the definitions of your analytics events and the values for a comparable period. Check that a form success event represents a successful submission rather than a button click, and compare it with processed inquiries where possible. Record the denominator you plan to use: sessions, users, or another clearly defined population.
Segment the baseline by device, important landing pages, and major traffic sources. Document relevant context such as campaigns, prices, stock availability, or changes in the team. If several of these change at launch, a shift in conversion cannot automatically be attributed to the design.
Make a note of any known measurement gaps. If a consent choice, integration, or duplicate event affects the data, investigate it before treating the chart as an exact description of customer behavior.
Prioritize changes as testable hypotheses
For every issue, write four short statements:
- Observation: what did people do, or what did the team see?
- Possible explanation: why might that be happening?
- Proposed change: what will you alter?
- Check: what evidence would support or challenge the idea?
For instance: mobile test participants did not find the delivery conditions. The team suspects the link is too far from the price. Move a relevant link closer and check task completion and related support questions. The explanation remains a hypothesis until you have evidence.
Prioritize by impact on a key task, frequency or strength of the evidence, implementation risk, and the cost of checking the idea. A broken order form usually deserves attention before a decorative detail. If the evidence is weak, test a focused prototype before rebuilding the entire site.
Changes may involve clearer labels, more useful content, navigation, responsive layouts, form validation, or a consistent visual system. Test components with realistic copy and edge cases rather than only with ideal demonstration content.
Protect content, URLs, and recovery
A redesign can accidentally remove a useful page, break an internal link, or change a URL that people have bookmarked or found in search. Before launch, map important existing addresses to their intended destinations. Preserve the current URLs where practical; when an address must change, plan relevant redirects and verify them after deployment.
Do not redirect every old page to the homepage merely to avoid an error. A relevant destination is more useful to visitors. Check internal links, indexability settings, and key pages in your search tools after launch. Search data may take time to reflect a change, so record the launch context and keep monitoring.
Prepare backups of data, files, and configuration according to the project's process. Test the recovery procedure and agree on rollback criteria before deployment. Check forms, notifications, payment flows, and integrations in an agreed test environment without exposing real payment details.
Measure outcomes without overclaiming
Choose metrics that reflect the goal, keep their definitions stable, and pair them with guardrails. A form project might track successful submissions per eligible session, processed inquiry quality, and errors. A shop might look at completed orders alongside cancellations and average order value. Technical performance is also worth monitoring, but a faster page alone does not prove that sales improved.
Consider a hypothetical example. Before the redesign, 100 successful inquiries came from 2,000 comparable sessions: a 5% rate. In a later sample, 120 successful inquiries came from 2,000 sessions: 6%. The difference is one percentage point, or a 20% relative increase from the original rate.
That arithmetic describes the observed samples; it does not prove that the redesign caused the difference. A new ad campaign, a change in the visitor mix, duplicate tracking, seasonality, or ordinary variation could contribute. Check the data quality, segment the results, and avoid drawing a confident conclusion from a small number of events.
Choose an evaluation method
A before-and-after comparison can be useful when an experiment is impractical. Compare similar periods and segments, and document other changes that could explain the result. Looking at mobile and desktop, or major traffic sources, separately can reveal patterns hidden by an overall average.
Where feasible, a controlled A/B test compares versions with visitors allocated during the same period. Define the main metric, allocation, stopping rules, and evaluation approach in advance. Check that exposure and success events are recorded correctly. A short test or a small sample may not support a reliable conclusion, so report uncertainty instead of declaring a winner at the first favorable movement.
For either method, investigate guardrails: did more inquiries translate into useful conversations? Did errors rise for a particular device? Did an important search landing page disappear? A measured improvement in one number can coexist with a problem elsewhere.
A launch checklist
Before launch, review the goal, baseline, prototype findings, important URLs, redirects, event definitions, backups, and rollback owner. Test key journeys across devices, keyboard navigation, form feedback, notifications, and integration responses.
After launch, repeat those checks on the live site using agreed test data. Confirm that analytics events fire once, old addresses lead to relevant pages, and important content remains accessible. Record issues and assign owners. During the observation period, review outcomes and context together, then decide whether to keep, refine, or revert each major change.
A good redesign produces evidence that a defined task is easier to complete while preserving the functions and information people depend on.
Read the original Russian article.
Top comments (0)