One 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. Unlike a physical product, which carries a high cost to make changes, software has even more potential for friction because code is infinitely malleable. That’s why it’s important to bring a sense of humility to look at a product dispassionately, whether as designers, developers, engineers or product owners. Change is about doing what needs to be done rather than what you’d like to do. 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. Step 1: Identify the value in your current product 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: Value hypothesis workshop 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. Expert analysis (at the right time) Expert analysis is a key part of understanding the user experience, but it comes with a caveat: it’s easy to give too much importance to certain findings when it’s the first thing you do. We recommend gathering data from stakeholders and users, conducting a discussion with them, and then doing the analysis. 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. Step 2: Keep what works, discard what doesn’t 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. Once you’ve gathered insights from your data, it’s time to make decisions about what stays and what goes. Another example of this mindset in action was the project we did with Flowforma where we had to reimagine its system from the ground up while still maintaining the value that the original product delivered to its users. Get to the why Sometimes, data will tell you that a feature is popular or underused, but not why. To get at the root cause, qualitative research like user interviews or usability testing is invaluable. (If you’re a regular reader of our blog, you’ll know we’re big believers in user interviews.) Understanding why users behave a certain way is key to making informed decisions about which features should evolve or be removed. Don’t guess; ask them. Design with insight 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. Step 3: Test with user prototypes and live data prototypes Marty Cagan’s concept of ‘user prototypes’ and ‘data prototypes’ is especially helpful here. For our client, we can quickly build a live data prototype by modifying the frontend and connecting it to existing data sources. When it’s time to introduce these prototypes to users, the key question is whether to run an A/B test or conduct a limited release. Each scenario requires tailoring your approach to fit the context. Step 4: Deploy thoughtfully 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.) (Side note: as designers at Each&Other, we use Miro a lot as a creative workspace for our projects. Over time, the developers have updated the UI, constantly tweaking the tool – but it’s evolving in an iterative way; the changes are slow and small. Functions move around the UI but they’re still findable relative to where they used to be. That’s a good example of redesign done thoughtfully, in my opinion.) 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.