My company’s product looks a bit dated, and I’m trying to push towards improving its UI.
My hypothesis is that since a lot of our growth is product lead, having a more visually appealing product would improve the overall conversion rate.
I’m having trouble justifying my desire to shift dev resources from developing new features to improving the product’s look and feel (and of course, getting pushback on it). My main problem is that because this is a process that requires a lot of small incremental changes, in the short term I can’t really measure the success of what I’m doing.
Any thoughts on how I can validate my assumption and get the management’s buy-in to this initiative?
3 Likes
Assuming that your more foundational hypothesis is that a refreshed UI will have a greater impact on conversion than the allure of new features that solve your customers’ problems.
Pitching a batch of incremental, short-term improvements will probably make it impossible to make a rational case. Instead, work ahead to what an ideal end state looks like for your product and articulate how (and more importantly why) that end state could affect performance in a very real sense.
Of course, you may through some diligence discover that your case doesn’t hold up to scrutiny. That’s okay. Your job is not to advocate for refreshing the UI but rather to help your team arrive at the right decision about investing in refreshing the UI.
It’s challenging to offer more concrete advice without knowing your audience (“management”), your product, or what “conversion” means for you.
3 Likes
Something else to consider is that your speculation might be off-base: the execution of an “improved” UI may really hurt execution for reasons that aren’t self-evident. I’ve seen direct superficial updates to an item that appeared to be more present-day really corrupt execution, so in the event that you do get the green light for this, be careful with accidental and creepy connection impacts!
2 Likes
Here’s how I did it.
I built a case that our UI was so dated. The quantitative data also came from the fact that in addition to dated UI, there were serious performance implications due to years of neglect and “adding feature sets”. I used click-tracking to prove that for a specific page, the clicks, page depth, and conversion. I brought in industry data to call out the importance and case studies of how latency improvements directly correlated to site conversion and revenue implications. I also predicted (conservative estimate) that improving our page performance by adapting newer designs could improve our site conversion.
For the qualitative data, we quickly ran some user tests on the site and observed users’ behaviors. Recorded it. We also interviewed a few users and got their feedback.
I was taking laps within the org and starting random convos with influential people on how slow our website is and how much we need to improve. I also number-dropped some data I was working on to really subconsciously influence the stakeholders.
Finally, did not pitch as incremental changes as Derek mentions, coz I would never have been able to justify the changes. Pitched as a quarterly project. Had strong support from Engineering and design. Finally, got approval to proceed and launched. Took a lot longer than expected.
1 Like
Most occasions I’ve seen that UI enhancements are only a side effect, coz we haven’t invested energy refreshing our item to the market. Along these lines, normally they will be slow.
1 Like
This is all great feedback. We did something similar and definitely, two factors came into play, amongst conversion improvements and trust. Performance improvement was a massive point and this redesign was the first big step down the path to getting full green on Web Vitals. The second was using this as a process optimization, where we overhauled the design system at the same time, making our code more efficient by removing redundancy, but also standing up a design system.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.