How to reduce chances of failure in case of product redesign

Learnings from my experience of handling multiple feature re-designs

Vikram Goyal
Agile Insider

--

Photo by Neven Krcmarek on Unsplash

Product or feature redesigns is an initiative which most product managers undertake at some or the other stage of their career.

Product redesigns are undertaken usually due to the following reasons:

  • De-clutter the UI — which has become complex due to addition of too many features
  • Simplify the user experience — by improving discoverability of key functionalities and/or adopting standard design patterns.
  • Adapt to new industry trends or respond to competition

I have been a part of multiple redesigns over the past couple years. Some have been successful and some have received customer backlash.

Here are my leanings on improving chances of success while re-designing products or features

Design and Development Phase

  • Start with a clear “why” behind the re-design — Companies often initiate a re-design simply because there’s a new leader in charge. Re-designs without any kind of qualitative backing end up being a waste of time and resources. Screens where there is prior user feedback around complexity can be the initial candidates for redesign. For any redesign, you should be able to articulate— why do we need this re-design and why is it important to do this now?
  • Understand the user journey — As part of the re-design, one or more user facing screens change. Identify the key actions user expects to perform when they land on this screen.
  • Have a solid review process to evaluate the new designs — Get the designs reviewed with QA and support teams. They can highlight issues from a customer perspective. If something is flagged by multiple people, treat it as a red flag and try to incorporate the fix for that.
  • Build for the future — A common reason for redesigns is to reduce the clutter in the UI because all the features are not fitting in properly. Make sure you anticipate the features that are likely to come in the next 6–8 months, so that you don’t have to repeat the redesign exercise after a month.

Launch Phase

  • Dogfooding the changes before launch — Never release redesigns without letting internal teams test it first. This helps expose obvious gaps in the solution.
  • Limited rollout — In case of major redesigns, release the feature to a subset of customers before making it generally available to all customers. This helps gather user sentiment in a controlled environment and act on critical feedback.
  • Let users try out the new design — It can be useful to let users manually opt-in to the new design. For some time, users can be given the option to choose between the new design and old design.
  • Inform internal teams about upcoming changes so that they can handle customer queries and update the training material.
  • Advance Communication to customers before launch— Eventually, you will have to make the re-design live for all the customers. If the changes affect a core customer workflow or lead to significant user anxiety, its a good idea to inform customers of the upcoming changes. This way, they are not in for rude shock due to sudden rollout of the changes.
  • Use in-app messages and contextual tips to inform users about what’s changing and how will it benefit them — To soften the anxiety of learning something new, its useful to highlight the benefits of it.

Redesigns are a tough nut to crack.

From a customer perspective, a redesign is like being transported to a new house overnight. Everything around you suddenly changes. You now have to learn afresh how to perform those actions which had become part of your muscle memory.

As product managers and designers, its our job to make the entire process of adapting to the redesign as seamless as possible for the end user.

References

--

--

Vikram Goyal
Agile Insider

Currently PM@Airmeet — building a kick-ass product for conducting remote events and conferences.