How to Push for UI Transformation?
You just joined a new company as a product manager and the product you are working on is complex and interesting. The only thing that bothers is the outdated UI. The first thing that comes in mind is “Let’s do uplift of the UI”.
In many companies, UI uplift is hard to justify. Why should we invest in it if we have paying customers? We have more important stuff to do that will reduce costs, acquire new customers and so on.
As product managers, if we believe the transformation will create a good impact, it is up to us to convince different stakeholders that indeed it’s needed and we will be the ones that measure the value and the success.
We need to prepare a strong case. So how to do that?
Is it really needed?
In some cases, the UI transformation will gain a minor value, so I came up with the following guidelines that will help in understanding the direction:
Type of change
In many cases, outdated UI is also a symptom of usability issues. It needs to be clear what type of change we want to do. Start with user tests (it can be by using tools or even just observations of users working with the product). Do you have a UX Issue or just UI? In which flows the UI should be improved? Is there any consistency issues?
Type of product
The type of product also impacts our decision to change and the magnitude of it. Is the product internal used by operations or an external one? How many users are exposed to it? Is it a work-related product (i.e. users are using it to do their job)? What is the standard in the industry? what the competitors are doing?
Type of user/customer
Important to understand your users’ habits. Are they technological? What is the relationship with them? Are they open to changes? How they are using the product?
One of the UI uplifts I initiated did not involve any UX changes intentionally. My product was a work-related product with a non-technological type of users and customers. In such a situation, the users were very sensitive to every change as they felt it cause them to spend more time in the app. This ecosystem impacted the way I planned the changes. At first minor UI improvements with no major UX changes. In a later stage, I introduced UX improvements as well.
Technology
what is the underlying technology? If the application is built using an old JS framework it is a good sign to transform. Maintenance of application written in an old framework can be a hard task to do(for example hiring developers that will work on an old framework can be difficult).
Technical retrofits
In many cases, products with long-running UI creates patchy code with many bugs. In such a case, it is good to know how many bugs are related to the product UI and see if any transformation (for example moving to new frameworks) can ease the maintenance and development of future features. Once there is a technical retrofit it is a good opportunity to change the UI as well.
In one of the companies I worked at, the product was transforming in the backend. The backend was a monolith that was broken into microservices. Even though the change is in the backend, it was a good opportunity to transform the UI for several reasons:
A. Cost — changing the UI in such a case will cost less than doing it later.
B. Positioning — when introducing such a change in the backend without changing the UI, it’s missing the WOW effect. Usually, such retrofits cause large investments as it is pretty much new product. the UI can help with the product positioning.
C. Functional changes — In such a big change, it was a good opportunity to do functionality changes as well. In such a case it is easier to justify UI changes in case of functional enhancements.
Roadmap
In many cases, future developments impact UX and UI significantly. If the UI transformation can be tied to a major development, it will cost less and the decision will be easier to take.
In one of the UI transformations I lead, I had a feature that impacted most of the pages in the mobile app. I took this feature as an opportunity and together with the product designer we introduced a new UI concept.
How to measure value?
In many cases when defining a new feature, we can build a hypothesis as for the result. For example — creating a wizard that will increase conversion by X%. Adding automation to a certain flow will reduce operation costs by X%. For pure UI changes, sometimes it is hard to put a $ value on it. When preparing the case, think about both internal and external stakeholders.
An approach that has been working for me:
A. External Improvements — Look for the concrete improvements that you will gain from this change from the Users point of view — reduce steps in the flow, reduce time spent, decrease learning curve (i.e. how many times it take to master the operation)
B. Internal Improvements — Describe any internal benefits coming from this change — Support benefits (i.e. expecting to reduce bugs in this module by %), Operational benefits (i.e. usability improvements that will reduce the training needed per customer), R&D benefits (i.e. moving to new technology with a strong community)
C. Qualitative data — Try to gather qualitative information — send a survey to customers, get feedback on a mockup, try to obtain competition examples
Action plan
Once the initial analysis was done and you feel this change will provide major value to the users, I recommend doing to following:
1. Provide market and industry overview — what the competition is doing? What technology they are using? what are the technology trends?
2. Know what you want to improve in details — be prepared to answer what type of change is needed, why you want to change it, what will be the impact on the user/customer, what will the impact on operations.
3. Create a mockup — can be clickable demo if you have the budget for it or in some cases even simple presentation can do the job.
4. Get T-shirt Size — Meet Development to get the T-shirt size of the effort it will require.
5. Make the business case — describe in detail the value vs. the costs with all the considerations mentioned above. In some cases, this step can lead to a no-go decision. The more detailed information you will provide, the better chances you will be able to convince of the need. Try to have a gradual plan — describe the end state but provide also a gradual way to achieve it. Can you start with one module and continue to rest in a later stage? This approach sometimes helps the decision-maker take action.
6. Meet different stakeholders and get their feedback — this step has 2 main purposes: 1 — get feedback that will help you to validate your hypothesis 2- preparing the ground for this plan. It will make the decision step much easier.
7. Measure success & Iterate — Once approved and developed, always validate your hypothesis and make sure the value is indeed in the direction indented. This is extremely important in such cases as the value of it can be hidden.
That’s it, hope you enjoyed reading and I hope to get your feedback!
