Designing a navigation bar step-by-step
When we’re thinking about how to increase user satisfaction, it can often be more tempting to devise a new and exciting feature than to cast our eyes back over the basics of our product.
However, as UX designers we’re well aware that few things have a bigger overall impact on a digital product than navigation. Why is that?
It is a transversal element present throughout the product.
It is the GPS you put at users’ disposal to make sure they know where they are and can get to where they want to go.
It helps facilitate the achievement of business objectives since it allows you to highlight features aligned with them.
With Milanuncios, we knew we had a UX debt in this regard so we sat down to see how we could prioritize this project and improve the navigation experience of our users.
Want to know how we did it? Keep reading!
Research Phase
The first step was to update our Inventory so we could estimate the extent of this user experience debt.
This exercise allowed us to analyze the features of the 7 different navigation bars and side menus we had on desktop. We also collected all pages where the user could have felt trapped by the lack of these navigation elements.
On mobile, however, we had a single navigation bar that used icons that did not match up with the rest of the platform, which added confusion. This, coupled with the interface failing to observe the required safety distances between actionable elements on mobile, resulted in a high rebound rate. In other words, we saw a bunch of people ending up hitting feature X despite intending to make use of feature Y.
So, it was clear our first objective would have to be unifying the browsing experience and getting rid of the dead ends detected in the inventory.
This exercise also served to highlight the fact we would need to work with three different technologies to change our navigation bar across the platform: React, Twig, and our PHP monolith. This magnified the level of ambition and forced us to split the project into phases to achieve our goal.
The next step was to analyze the scope of the problem from a range of approaches that included different stakeholders in order to provide a 360° view. So, we organized the problems to be resolved into 4 layers:
- Business strategy and objectives
- Technological framework
- Usage data
- Usability
From a strategy perspective, the current navigation bar did not entice users to log in or register. This meant we were missing the opportunity to show them the benefits this could provide.
On the other hand, from a business point of view, the need arose to publicize our door-to-door shipping service.
As part of this strategic layer, we also sat down with our SEO expert to assess the implications of changing our navigation bar. Despite this being an “invisible” element, we must remember we should always pay attention to it if we want our product to succeed.
As for the technology framework, now we knew we would be working with React, Twig, and PHP, our greatest concern was understanding how each of the possible solutions could affect performance.
But we also had to figure out whether there were any limitations in propagating data from one technology to another and how much logic we would be able to incorporate into the early iterations of our navigation bar. For instance, were we going to be able to send message notifications or alerts directly to the navigation bar?
To resolve these concerns and bring the project to fruition, it was vital to work hand in hand with the front-end team throughout the process.
In terms of usage data, the first step was to review our tagging plan with the data team and check to see if any key elements were not being measured. Once we had all the necessary quantitative information, we analyzed how users were moving from one page to another, taking each page’s total traffic into account. We were able to trace the journey users made when browsing Milanuncios and understand which features were more relevant and which were too concealed in the current system.
Finally, in usability terms, we started asking questions about improvements we could make to accessibility in the navigation bar or how it would change the relationship between the ad management area and the user profile.
The user profile had long been part of a second-level menu within the ad management area. However, with the addition of improvements like a profile photo and email verification, now was time to give it greater importance. This implied a change of hierarchy in our future navigation bar menu.
Alongside this four-layer research, we also made sure to look outward.
We conducted competitive benchmarking that ranged from our most direct competition to industry giants such as Amazon and eBay, to specialists in different fields. A total of over 30 websites through which to study users’ expectations and understand the mental model among our user segment when browsing any website.
- Which are the most repeated elements?
- Which are present when the user is logged in?
- Which ones disappear if you don’t have an account?
- What adaptations are made for responsive design?
In addition to resolving these questions, we were able to start making design decisions. For instance, we found that the Milanuncios logo was far larger than the market average.
Its presence in the navigation bar may well be vital from a branding perspective, but we know screen space is extremely valuable. So we reduced its width to an optimal size on desktop and chose to make use of our avatar on mobile to gain space for the functional elements.
Design Phase
Now it was time to start building.
The navigation bar of our dreams?
No, just one that would allow us to continue learning. So, we performed an a/b/c test on the mobile web intending to validate hypotheses and collect real data about our users’ learning curve.
We choose to pit the current 3 icons against two variants of menus with a single level of options.
This experiment allowed us to confirm the hypothesis that it was possible to add another step to our navigation flow without leading to a fall in access.
Our theory about mistaken access was also reinforced, given we obtained a greater number of total accesses in both variants than with the original, but with percentages clearly redistributed.
As for the burger menu and the “Menu” button, we didn’t get a clear winner, so we were encouraged to continue exploring design solutions.
At last, we could design a navigation bar closer to our optimum concept and begin testing it.
We organized a usability test and selected two profile types: Milanuncios users and non-users. This meant not only would we be able to check whether those who already knew the platform could adapt to the new navigation bar without any issues, but we could also see if someone using the platform for the first time would understand it.
The test revolved around 5 tasks ranging from posting an ad to deleting an account, all of which forced the participants to navigate the comprehensively prototyped two-tier menu.
The insights gained helped us to make decisions like simplifying our menu onto a single level. The elements we had placed in the sub-menu weren’t given enough importance by the participants to justify adding complexity to the code, tracking, and user.
We also discovered the best place to place the logout button. In our prototype, we had chosen to test one of the more unusual locations among the patterns that had appeared during the benchmarking. However, the end position on the top tier stood out as the ideal place to locate it. This was the first place the test participants went looking for it.
Going live
Once the usability test results had been shared with the entire team, we were able to draw up a roadmap and plan the roll-out of the new navigation bar.
We decided to phase the launch into two iterations.
First, we integrated the navigation bar and allowed it to coexist with the old side menu, even if that meant some accesses were duplicated. This meant we could carry out a technical sanity check with lower risk in the event something went wrong and begin to observe whether the user accesses moved to our navigation bar.
Once we had also confirmed that all metrics were stable, we launched the next iteration. We removed duplicate menus on both desktop and mobile web and relocated options previously only available on that menu inside the ad management area.
Analyzing the results
Two weeks after this second iteration we began to see the ROI of our work:
We saw five times as many accesses to the user profile in general without reducing the accesses to the ad management area.
We increased unique users logged in on mobile by 15%.
We kept our number of new ads posted health metric stable.
This data showed us we should carry on with our work. Our roadmap contained at least 2 further improvements which we were still eager to make:
- Let the user log in on the page they are on instead of sending them to another.
- Display the profile photo instead of a placeholder.
If you want to see how this story develops, make sure to follow us!
We’ll keep iterating!
