Your Redesign Launched. How Do You Know It Worked?
Your Redesign Launched. How Do You Know It Worked?
When a Redesign Launches Without a Baseline
A redesign goes live, the leadership team looks at it on a big screen, somebody says it feels cleaner and more modern, and the project is declared a success. Nobody has checked whether a customer can still find the returns policy.
Most website redesigns do not fail loudly. Appearance is an unreliable judge. Nielsen Norman Group (NN/g) describes the aesthetic-usability effect, the documented tendency for people to assume attractive things work better. In the research that established it, the correlation between participants’ ratings of aesthetic appeal and perceived ease of use was stronger than the correlation between appeal and actual ease of use 1. A good-looking interface can mask problems during testing. This means the launch-day glance measures appearance rather than whether the task was completed.
Agreeing on What Better Means
Defining success starts well before anyone opens a design tool. Success criteria have to be defined at the outset, and defining them is a conversation between the people paying for the redesign and the people building it.
Google researchers published a structured method for exactly this in 2010 at the Association for Computing Machinery Conference on Human Factors in Computing Systems (ACM CHI). They called it the HEART framework, standing for Happiness, Engagement, Adoption, Retention, and Task success, and built it on a Goals-Signals-Metrics process. That process moves from business goals and user needs, to the signals that indicate progress toward them, to the specific metrics that track those signals 2.
In practice this means naming the outcomes that count before a wireframe exists. Fewer support calls. More completed applications. Faster checkout. Each one is something a stakeholder can agree to in plain language, and a researcher can turn into a number.
Capturing the Baseline
A redesign is meant to make something better, but most teams cannot say better than what, because they never wrote down where they started. NN/g makes benchmarking the answer: establish a clear reference point so that any improvement has something to be measured against 3.
Government digital teams treat baseline measurement as mandatory. The UK Government Digital Service (GDS) requires services to collect data on four key performance indicators: cost per transaction, user satisfaction, completion rate, and digital take-up 4.
The practical version is unglamorous. Pull the existing analytics. Run a round of usability testing on the current site, however dated it looks. Write the numbers down and date them. That record is what turns a post-launch review from an opinion poll into a comparison.
Three Measures That Show Real Use
Not all metrics reveal whether a site actually works for the people using it. Three in particular cut through surface impressions and reflect genuine user behavior.
Task completion rate is the percentage of people who finish what they came to do. GDS defines a service’s completion rate as the number of digital transactions users complete as a percentage of all digital transactions they start. Only genuine users are counted; internal testers and web robots are excluded 5. In usability testing, NN/g describes the same idea as task success: “a very simple binary metric” reported as the percentage of participants who completed the task 6. This is what the UX & Usability Toolkit, drawing on the ISO 9241-11 standard for usability, calls effectiveness: the accuracy and completeness with which users achieve their goals 7.
Findability asks whether people can locate the thing they need in the first place. NN/g puts the commercial stakes bluntly: “The first law of ecommerce is that if users cannot find the product, they cannot buy it either” 8.
Navigation efficiency covers the cost of getting there, in time, clicks, or dead ends. The UX & Usability Toolkit frames efficiency as the resources consumed relative to the goals achieved 7. A benchmarking example from NN/g shows the shape of the result: average time to make a purchase fell from 58 seconds before a redesign to 43 seconds after 3.
Two Launches Compared
Imagine two teams launching redesigns on the same Tuesday. The first recorded a completion rate of 61 percent on the old site, timed a set of core tasks, and ran a findability study, figures used here to illustrate what a measured baseline makes possible. Four weeks after launch it reports that completion has moved to 74 percent and that the average time to reach a product page has dropped. One task got slower and needs attention. The conversation is about which numbers moved and what to do next.
The second team has screenshots. Asked whether the redesign worked, it can offer traffic figures that nobody benchmarked against anything, and an argument about whether the new navigation feels cleaner. Without a reference point, there is no way to tell improvement from decline 3. The design work ends up being defended on taste because taste is the only evidence anyone brought.
Paying for Problems Early or Late
The financial argument for catching problems early is well established. User Experience Professionals Association International (UXPA), a nonprofit professional association, puts the cost-benefit ratio for usability at $1 to $10-$100. As a rule of thumb, correcting a problem once a system is in development costs ten times what it costs in design. Correcting it after release costs a hundred times as much. Citing Bias and Mayhew, UXPA International reports that American Airlines reduced the cost of fixes by 60 to 90 percent by correcting usability problems in the design phase 9.
One way to buy that early warning is to avoid launching everything at once. GOV.UK’s service manual formalises this through private and public beta phases. A private beta releases the service to a small, invited group of real users. Teams can then test, gather feedback, and measure performance before opening it more widely. A public beta then extends access incrementally while iteration continues 4. A staged release turns a single launch-day verdict into several smaller, cheaper ones.
Measurement also pays after launch. Benchmark numbers let a team calculate return on investment. They show stakeholders, in NN/g’s words, “exactly how much more they’re getting in return for what they paid.” Repeating the study on a regular cadence, after each major redesign or once a year, shows whether the gains held and where the next round of work belongs 3.
Define success before design begins, and the launch stops being a verdict delivered by eye.
2 The HEART framework is designed to be modular. Teams choose the dimensions most relevant to their product rather than measuring all five for every project.
Spruce DX is the digital experience division of Spruce Technology, helping organizations design and build accessible, human-centered digital products.