San Francisco, California
Interaction Design, User Research, Navigation Design
Summer Internship [Individual]
June, 2019 - Sept, 2019 [3 Months]
1. Problem Statement
Helping users navigate should always be the top priority for every website and application. More than just navigation, it should also indicate the system status at all times so that the user never feels lost when navigating across interfaces. The following project was about:
How can we re-design a navigation system that aims to solve not just the user pain points, but addresses business goals as well?
The project was prioritized for a number of reasons–there was a desire to move towards something that derives learnings from current user research and analytics and problems that other team members were facing in scaling and maintaining the current system. It was also essential to not get carried away with the stakeholder goals at the cost of user end goals.
The list of objectives was pretty exhaustive, and going in I was aware I wouldn’t be able to tackle each one of them individually in a span of 3 months. Therefore, it was pivotal to prioritize the objectives and move in with a clear picture of how would you measure the same. Moreover, I decided to tackle business and user goals that were interrelated, simultaneously.
- Engineering and finding the use-cases went hand-in-hand since the different code bases were due to the navigation bar changing based on different contexts.
- SEO and Interaction design went together since during this step we would be creating the new site map, which can also help us ensure how to handle links that boost SEO
- Partnerships accessibility was party related with the usability of the navigation, where we can check if the users are able to access different pages using tree testing
- Finally, visual inconsistencies and co-branding came in the very end
As a starting point, I decided to lay down all the current visual/usability inconsistencies in our existing navigation. This indirectly helped in formulating the different use-cases where the structure of the navigation changes.
4.1 Current inconsistencies
Upon doing a quick audit of our current system, I found out we had 8 different iterations of the navigation, which changed based what page the user was on:
4.2 Site map
While we did have an XML sitemap in our code, we didn't have a visual sitemap that could be used by other designers/managers as well. I felt a visual sitemap could help understand the taxonomy, map user flows that we might think of in future, and more importantly unearth dead-ends in those user flows.Link to visual sitemap
4.3 Potential scenarios of changeTherefore, as the next step, I decided to enumerate what could be the possible scenarios where the header changed on navigation from one interface to the other, and listed the pages where there was an inconsistency:
4.4 Competitive Analysis
Seeing what the competitors are doing out there helped me gauge what can be spectrum of explorations to permutate across–therefore, I did a quick competitive analysis to have starting point of explorations
5.1 Initial Explorations
For the first set of iterations, I wanted to focus more on the skeleton and the overal structure of the navigation and get some internal feedback from the weekly design and product syncs. As a direct result of the competitive analysis, I came with a set of permuations across the range of 'everything' and 'barely anything'. In addition, I asked the SEO team what all link they envision in the new system to be surfaced.
5.2 Iterating, constantly
For a while I kept iterating based on internal feedback from managers, designers. SEO teams to the point it was ready for usability testing on real users. Every iteration included:
- A better UX copy
- A better clarity on SEO goals with the team
- Design system feedback from the design team
No matter what design we picked, the biggest challenge was to gauge how much the extraneous links clouded the user decision-making in taking the action.
It all boiled-down to either show everything at once and let the user decide, or do the heavy-lifting for them–specifically fighting between active and passive actions. Should we show resources alongside actions? Does that interfere with what the user has to pick? How many times they got confused? And there was only one way to find out:
6.1 Test results
To carry out the test, I used usabilitytesting.com, and for creating a shareable prototype, I created them in inVision. For a test to be a fair test and eliminate confirmation bias, 'Design A' was shown first in first test, and 'Design B' was shown first in the other.
6.2 Pick and refine
Based on the test results, we decided to go forward with 'Design A' due to the following reasons:
- Scalability: With more products and services, the extended height of the navigation in active state can become too large
- Usability: Users found it easier to drag their mouse down directly from top-to-bottom instead of left-to-right
- Time: Since there was also mobile design to cover, time was always a constraint and we felt the above metrics justified picking 'Design A'
7. The final countdown
Upon incorporating the above usability feedback, and a better grip on the copy for list items alongside minor visual changs, we arrived at the following desktop designs:
For mobile designs, the level of nesting was maintained and everything was squeezed inside the hamburger to the left. The motivation behind this was two-fold:
- Consistency: Keeping it consistent from a usability standpoint [Levels 1, 2, and 3]
- Functionality: In case when the navigation changes, the menu affordance wouldn't change and would not create any new design patterns
There were a lot of things I achieved in a span of 3 months, but there also a few things that I was unable to address:
- Tree-jack testing and Click testing: While the initial test plan comprised of doing the former as well, due to time constraint, a more in-depth knowledge about which links are completely ignore, and which are focussed more could've helped decide on the level of cognitive load inside the navigation
- Re-using design components: Throughout the project, there could've been instances where the need for a new component could've been obviated, therefore reducing the load on the design system side.
- I was pretty happy with how thorough my initial research was and how much it helped shape the foundation of the navigation system, for both desktop and mobile
- Finally, the idea of a functional web-prototype, though sounded practical on paper, but didn't render itself as useful in testing as it would be in handing-off the design to developers, which was totally unexpected.