Navigation design for Onto
I worked at Onto, an electric car subscription company, where I was tasked with redesigning the primary navigation on the website.
This redesign aimed to accomplish two goals: the business goal of improving Onto’s organic SEO ranking; and a customer-facing goal, of making content on the website easier to discover for visitors.
My contribution
High-fidelity design
Prototyping
DS component creation
Research and testing
The team (Web team)
1 × product designer
1 × product manager
3 × FE devs
Project length
2 months
The problem
Onto's main website had a very crowded navigation bar. As the company scaled up, teams across the business used it as a place to cram in more information.
At the same time, Onto was not doing well in organic search comparative to its results in paid search.
So the problem we were trying to solve was two-fold:
End-user problem: content on the site is hard to discover
Business problem: Onto’s organic SEO ranking is too low
Onto's marketing team had devised a new tree structure of content that would improve Onto's SEO rankings. My job was to solve the end-user problem, and work out how to fit all this new content into the navigation bar, without it becoming overwhelmed.
My design process
I researched how direct and indirect competitors structured their navigation.
Based on this and Onto's existing design language, I created a few options for the navigation bar, and refined it into a high-fidelity design and clickable prototype.
I handed over the designs to the frontend team, who built it to be fully CMS-editable in Prismic. They released it behind a feature flag, meaning we could fine-tune the actual content in the CMS.
One stakeholder was nervous about having a click interaction to open the mega menu, instead of a hover interaction. Their reasoning was that a hover interaction would aid discoverability.
However, after I researched best practices for navigation, and created a prototype for both options, I defended my decision that clicking to open the menu was better for both usability and accessibility.
Tree testing
To measure whether we were solving the customer-facing problem of helping a site visitor find the content they were looking for, I conducted a series of tree tests using Optimal Workshop.
Tree testing strips away all the UI, just focusing on the tree structure. Each task asks users to navigate to a given target, like so:
Each test had six tasks, that became progressively harder:
Where would you find the Audi e-tron car information?
Where would you find all the electric cars we offer?
Where would you find information on how car subscriptions work?
Where would you find information about how tracking mileage works?
Where would you find out about company cars?
Where would you would find information on leasing?
We started with the following hypothesis for the tree structure:
Cars, Subscription and Blog would have dropdown submenus
Business, Community and Help would not have submenus
After performing this test with ~60 participants, task 4 had a low success rate. Information about mileage was featured in an explainer blogpost.
From testing, we realised that a lot of help content was split between legacy blog articles, the help centre and the community forum. Therefore, we combined these sections under one parent (Help).
We repeated the test with this new design, and a few other small changes, and saw am increase in success across not only task 4, but across all the tasks.
Impact
Conducting detailed tree testing gave Onto confidence in launching the new navigation structure. Without tree testing, the new navigation would still have been launched, but the testing ensured we had the best usability going forward. Moreover, testing and iterating can continue to happen as the navigation structure is fully CMS editable and lives behind a feature flag.
Measuring metrics such as bounce rate and pageviews, once the new tree went live, was important to make sure there are no further usability issues, and to confirm that the new content is having a positive impact on organic search.