How do you revise a product without taking away what users loved about it in the first place?
O
ne of the great things about software is that it’s easy to change. One of the risky things about software is that it’s easy to change. So how do product managers, technical CTOs or designers oversee a redesign where they won’t be fielding feedback from angry users because their beloved tool changed for the worse? Here’s my proposal for how to strike the right balance with a redesign, avoiding wasted effort and negative user experience.Firstly, let’s acknowledge that everyone starts a project with good intentions to make something better, not to unintentionally undermine what users already love about it. That’s why it’s important to be conscious of the biases we all bring to the table. As the saying goes, when all you have is a hammer, then every problem looks like a nail.
Before embarking on a redesign or refit, start with some key questions: why are we redesigning it? How do we know what to redesign? How will it make the product better?
Data is a great way to answer those questions effectively – and it avoids the risk of unconscious bias. Fortunately, software and web apps are great candidates for a data-informed approach to redesign because they naturally lend themselves well to quantitative analysis – but as I’ll explain, they’re not the only tools in our arsenal.
Before making any changes, it’s critical to understand where the value lies in your existing product. Recently, we’ve been working with a client that has an established one-page application with a devoted user base. Users speak highly of it, but we don’t currently have the data to precisely pinpoint what aspects of the experience they value most (I’ll get to that part in a moment).
To move forward with the redesign in a considered way and address the gap in knowing what users like and want, we recommend two activities:
In this workshop, the product team collaborates to create hypotheses about where they believe users are deriving the most value. We focus on specific features that, anecdotally, users seem to love. After developing these hypotheses, we create a tracking plan to gather data that will either validate or challenge our assumptions about these features.
The team knows its users, so we ask them: what parts of this UI are valuable? That leads us to figuring out how to measure usage, or find another metric to tell us that a particular feature is actually solving a problem.
Ideally, the user base needs to be large enough that the information we get from them will be statistically significant. The number of people using the tool, and how frequently they do so, will dictate how long this research needs to take.
What we’re looking to do with any design project is minimise bias as much as possible, challenge preconceptions and get to an agreed truth of what needs to change. This way, the expert perspective should complement rather than dominate your insights.
Introducing change can be fraught with friction and acrimony: that’s going to be inevitable. Product leaders need to factor this into their thinking about whether this update is worth pursuing. People typically don’t want to change; don’t underestimate the power of inertia. Sometimes, change is necessary because adding new features and functionality is important, but it’s important to introduce the right amount of change at the right time.
Now that you have a confident understanding of what works and what doesn’t, you can start redesigning. This process is built on quantitative data, qualitative insights, and expert analysis – all of which may challenge your original assumptions. This is an opportunity to create an even more valuable product for your users.
Throughout this process, your hypotheses will evolve as you learn more. You should only deploy once you’ve proven your hypothesis by observing user interactions that align with your expectations. If you haven’t validated your hypotheses, it’s not time to deploy yet. (Deployment, in this context, means doing all the necessary engineering work to ensure the new design is stable and ready for release.)
For balance, here’s a cautionary tale about introducing new features: in 2016, the US Navy replaced mechanical controls on its destroyers with touchscreens that allowed any sailor to access any set of controls, from any station, just by changing the touchscreen panels. However, just a year later, a collision between two ships claimed 10 lives and injured more than 50 others.
A report into the accident from the National Transportation Safety Board found that elements of the touchscreen system were “unnecessarily complex” for operators. It also found that most sailors preferred to control ships with wheels and throttles, rather than touchscreens. Rear admiral Bill Galinis said the decision to use touchscreens was a classic case of “just because you can doesn’t mean you should.”
Wise words to guide any change project.
When it’s easy to introduce change, the risk increases. The goal of data-informed redesign is simple: better outcomes by making change in the right way – intentionally and thoughtfully.
When we understand existing value, gather and analyse data, test hypotheses, and deploy only when confident, you can ensure a redesign that improves the product without diminishing what users already value.