.png)
Challenges with existing UI
1) Due to an unorganized and sometimes illogical work flow, many users could not complete the configuration step on their own. They had to solicit help from Customer Success Managers.
Solution for Problem 1
Place the ‘Upload a file’ or ‘add integration’ step at the top of the page, so the user can complete it first, so user knows what data they are configuring.
Solution for problem 2
Only display Journeys that the user has paid for, and in the event they want to buy others direct them to a journey packages page
Additional challenges with existing UI
One of the core products of the company could not be accessed within the product platform since it was connected to another domain and designed completely differently both in terms of user flows and branding.
Solution for problem 5
Change the side navigation bar from “Product Based” to “Activity Based.” Following conversations with CSMs and customers, I asked both if they thought in terms of products or activities when first logging in to the platform. Everyone answered “activities”, so this was an easy win convincing my team to switch to an activity based sidenav. As a result, 'Intelligence' and 'Guardian' were replaced with 'Queries', 'Reports'. These navigation options also display menu options of related activities.
Solution for problem 6
Eliminate the “review” option and move forward with only Yes/No options.nLeads were frequently getting flagged as “review” which in practice turned into a limbo, “I’ll get to it later” category. After talking with customer I learned that they never really dealt with leads flagged as “review” and they believed it was a useless option.Unfortunately due to technical limitations surrounding the API, the “review” option remained, thus my solution was never implemented. I wanted to include this example to show that although everyone may be on board, including engineering, the amount of work required may make the juice not worth the squeeze.
Situation and Approach
The task was clear, design a new nav bar and user flows for three existing products. Although this seemed like a straightforward approach -> clear labeling and illustrative icons leading to associated tasks, after conducting internal usability testing, the end user experience revealed some larger, more strategic problems.
Problem
Since two products share overlapping activities such as “view query profile” the nav menu had redundant menu options. This ugly consequence of this design when the user uses both products, then navigation would be somewhat confusing when seeing similar activities in two different products. Questions would arise, such as: “Is this the same query profile, or a separate query profile tied to this product?” Thinking through this issue sparked a broader product conversation around the question of “Does the nav bar need to adhere to product names or can users navigate via activities such as “Queries?” Given the fact that our sales were based on selling products to customers it might be a little strange or confusing at worst when not seeing that product name in the nav menu after purchase.
Adaptation
Move from a product-based nav menu to a task-based one. After running usability tests with several customers and asking them if they thought about their workflows while in the app in terms of “products” or “tasks”, they unsurprisingly all responded: “tasks”. Instead of “I need to use Guardian”, they think “I want to edit my disclosures.” This is pretty common sense stuff, but there was tension and resistance when telling product, sales, and marketing it would be better for the user if our flagship app delivered value via tasks/features instead of through these well known product names.
Result
As a result, the nav menu became free of redundant options that created a confusing navigation experience. Additionally, not using product names and displaying a core activity meant we could remove one step in the user flow. Lastly, it was challenging going against the grain and mindset of my coworkers of whom many had been working with the legacy product-based application for 3-5 years. For me this challenge was less about adapting and problem solving and more about educating your colleagues on the reality of the problem that they had been living with for a long time. In retrospect, educating and winning over the product manager and one customer success manager really served as a good foundation for pitching this change to the rest of the teams because it added additional credibility in addition to the user feedback.
