Rare is the time I’ve been blessed with a truly ‘greenfield’ project, a product so new that the only conventions that need to be adhered to are those that come with the target users (see Jakob’s Law) and those of good product design. More often than not it’s been my job to improve 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 userbase?
Option I: Softly softly
“The man who moves a mountain begins by carrying away small stones.” —Confucius
These’s a lovely analogy I once heard to describe making small, incremental, but meaningful changes to an existing system. Imagine you’re standing in a kitchen. You’ve been using it for months now and have learned where everything is. Now imagine I’ve come in overnight and reorganised everything to the most logical, most ergonomic locations, and removed the least-used equipment. Any new person that comes in to the kitchen will stand a much better chance of guessing where to find what they need, but you need to spend tine 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.
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 told you works better for your users, and tell your legacy users that this change has been made next time they visit it. 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 coming out 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 across to the new. This was Microsoft’s approach with moving users from Explorer to Edge: Launch; Co-exits; Phase-out; and Retire.
Which option I’ve opted for has depended upon 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.