Rarely have I been blessed with a truly ‘greenfield’ project—a product so new that the only conventions to adhere to are those of the target users and good product design principles. More often, my job involves improving established systems with established user bases, who have invested time and effort into working with a system and its… quirks. How do you make changes to a product—sometimes significant changes—without frustrating your existing user base?
Option I: Softly softly
“The man who moves a mountain begins by carrying away small stones.” —Confucius
There’s a lovely analogy I once heard to describe making small, incremental, but meaningful changes to an existing system. Imagine you’re standing in your kitchen. You’ve been using it for months now and have learnt where everything is. Now imagine I’ve come in overnight, reorganised everything to the most logical, ergonomic locations, and removed the least-used equipment. Any new person that comes into the kitchen will stand a much better chance of guessing where to find what they need, but you need to spend time and effort re-learning everything you knew about how to use that kitchen—you’d be frustrated even if the design of the kitchen was demonstrably better. The same is true for software redesigns. Whether it’s a pre-formed mental model not fitting new data structures, or muscle memory causing users to click on the wrong option, any change can cause pain to existing users.
The solution is small, well-labelled changes made on a regular basis. To continue our analogy, rearrange the spice rack to make it alphabetical, and tell the users you’ve done so. Or with UI design, re-order the contents of a page to one that your research has shown works better for your users, and inform your legacy users of this change the next time they visit. Through regular small changes, you can quickly redesign an entire system and bring your existing client base along with you.
Option II: Launch, Coexist, Phase-out, Retire
“Change is the law of life. And those who look only to the past or present are certain to miss the future.” — John F. Kennedy
This option involves building a completely separate version of your product that will run alongside your existing offering. This fantastic new version of your product will be launched with the understanding that existing users can, for a time, continue to use the older version, but that all the fantastic new features will only be available in the new version. The two versions coexist for a time, before the old is phased out and any laggards remaining on the old system must migrate to the new. This was Microsoft’s approach with moving users from Internet Explorer to Edge: Launch; Coexist; Phase-out; and Retire.
Which option to use? It depends.
Which option I’ve opted for has depended on a number of factors such as the scale of the product and the resources available to build an entirely new offering alongside an existing one. But in the end, these have always proven to be the best two options.