Visible navigation
Getting people to related info isn’t difficult, when you put the right work into figuring out how.
This is a project story about the importance of visual web site navigation and the techniques I used to empathize with my audience, find the problems, and design solutions.
- A company wonders why high traffic pages have such a high bounce rate when there are valuable related pages available on the site.
- I investigate the underlying problems and test solutions.
- Even a simple design change creates a 358% increase in traffic to related pages. Further designs address remaining problems.
High traffic but also high bounce
At this company the highest traffic web pages are a type called Question and Answer (QA), which thousands of people a day will see. Like much of the site, it has a high rate of people leave the site or “bounce” without interacting with or visiting any other pages. The pages were already quite full with other kinds of content, hoping to lure people into these other pages—so a lot of people at the company were at an impasse for what to try next.
I was on a team to try to address these “top of funnel” issues, so I was asked to look into this.
Understand the problem
The first thing I did is to see if we’re assuming the right problem and asking the right questions about them. I can usually do this best when I have access to:
- usage data (google analytics)
- interaction data (click and scroll tracking)
- survey data
- user testing
- the product as the audience experiences it
- a/b testing
and I did for this project. From usage data I found that most of the existing links we had on the page were not being used. After gathering results from click tracking and a quick user test, I found that all the “official” navigation on the page was not even being noticed by the majority of people. When it was pointed out or eventually found, it was not understood. Most of the other links on the page were either never seen or thought of as unwanted noise.
Additionally, many people were likely confused as to what the context of the page was: “What is this site for?” and “What kind of page is this?” were things I heard in user testing. I also found a split between male and female audience members. Men were the only ones to notice and use the top of page header elements that contained the main three kinds of navigation—and the only ones to think tapping the “join” button could be worthwhile. Like most of the site, traffic to these pages was 80% mobile and mostly on woman-centric topics. Looking at these pages on my own phone and test devices, I found that most of what we were hoping people would tap on wasn’t really being presented in a way our audience could clearly see or act upon.
In short, there were a lot more problems than just bounce rate.
On the majority of mobile devices, the header area took up most of the first screen and yet the most important navigational items were either hard to notice in this block or completely hidden. Global navigation was taken up by the logo, search, a join button, and a hamburger menu. The second level navigation was hidden inside the hamburger menu. A third level of navigation was a verbose set of breadcrumbs. The fourth level navigation of related pages only displayed 1 or 2 items out of 7 to 8 total. A giant “ask a question” button came next, followed finally by the question of the page. Understandably, our audience would scroll down as soon as they were able—seeking the content they came for—and forget the top of the page existed.
Once they saw the primary content of the page, the page was populated with several components that both ended up signaling the end of the page for people and appearing to be like advertisements. The linking within these units was avoided for those reasons.
To summarize, the navigation for most people was:
- Invisible
- Unnoticed
- Unhelpful
- Untrusted
- Complex
Address with solutions
With some clear problems identified I had an easier task of designing solutions to them. The company had adopted a test-first working style so I utilized my 2 Timeline Design method to start small and iterate to more complex solutions to test and implement.
Make it noticeable
From testing I could see that people were really pretty good at getting to the core content of the question being asked and the first couple of answers provided. This happened in part because previous to this project, I’d been able to get the question and answers fonts formatted to create a clearer hierarchy for the page. It was noticeable and indicated what the point of the page was. That was working and I didn’t want to disrupt it.
Beyond that, the audience would loiter a bit to see if there was anything else worth seeing on the page before deciding to leave. It was there, after the answers and before the “other” content that people wanted to look for something more. I knew inline navigation would be seen here.
Make it visible
Any kind of collapsing display would suffer the same fate as the existing links, so my answer was to make an expanded inline block of navigation. Anything we wanted to show would need to be plainly visible.
Make it helpful
It was clear that what the link options page had been presenting were not helpful, so I looked again at usage data and also survey data that gets periodically updated. There I found that in general, the traffic and respondents indicated that people want to see related pages in the following priority: photos, reviews, cost, questions, and so on.
I took that order and applied it to navigation items. My team was also charged with directing people to the providers (doctors and spas) who advertise on the site, so providers took the top spot. To increase the utility of the items, I added totals (and average price, for cost) beside them. Also one other detail: I noticed through many tests that people called photos “photos” yet the site had always called photos “pictures”, so I made sure to call them photos.
It was also clear that visitors to these pages didn’t know they were within the context of a fairly complex site structure, on a site that could offer more than a Q&A page for a particular question. I created that context to ease people into the navigation block, using elements used on other pages.
Make it trustworthy
This navigation unit needed to look like it was part of the site and not look like it was going to send them off to somewhere they didn’t want to go. Otherwise it wouldn’t be trusted enough to be tapped. I put most of this energy into the start of the nav block, making it into a mini-version of the main treatment page headers. Secondarily I knew from experience that using icons along with the text would make it more comforting for people to use.
Make it simple
Along with the above ideas that favored simplicity, I played around with several layouts—unsure how simple we could make it and where I should place the focus of the unit. One problem was that we just had too many related page types. Paradox of choice. Through discussing it with the team’s PM, we agreed to drop it down to 5 items on most pages. Another problem was the large “worth it” percentage being confusing to most new visitors. They simply didn’t understand what it represented, no matter how large it appeared. I was able to convince my coworkers of a design that shrinks it down into something simpler and self-explanitory.
These negotiated details made simplicity easier to lay out and easier to implement in code. I finally thought it was clear enough for the audience to use. The version I settled on also had the effect of making it even more noticeable on the page.
Testing the inline navigation block
We got an A/B test coded up and running fairly quickly after that. The results were in the direction I was expecting but the lifts in percentage were higher than I’d thought it would accomplish so soon. The nav block was creating a 358% increase in total navigation to the related page types, compared to the legacy links. It was also for the most part, generating those numbers in the same order I’d placed the links (photos, reviews, etc.)
358% increase in engaged traffic! Win.
When sharing the test results across the product division I basically explained it in similar terms as some early link tests I’d designed specifically to the provider directory:
“…if you give people links to the things they want to see, they’ll use them.”
This doesn’t speak to the research work I did seeking actionable empathy for the audience or the complexity I worked to turn simple—but it does outline the basic premise for what I was trying to accomplish and why the first test in this direction was such a rudimentary design. It’s not a sophisticated or particularly elegant solution but it works and the basis it establishes could be grown into something that is.
After concluding the test and rolling the change out 100% across the site, that increase in engaged traffic continued on. The nav block was then started to get placed on other page types and a static version of it (that didn’t have the dynamic numbers based on the person’s location) was made to appear in weblog articles.
Next, more sophistication…
2 Timeline Design wouldn’t be complete without the upper, visionary timeline, so the next thing I did was outline a couple of follow up ideas that would lead to related projects.
With the precedent of this new navigation was in place and proven, I was able to set concepts in motion that were going to be more difficult to code but would build upon the same success goals of the nav block to improve the page header:
- Sticky treatment navigation
- Evolving the global navigation
Both moved forward through testing and both gained positive reception.
Sticky treatment navigation
The 4th level navigation at the top of the page needed the same treatment, if it was going to be kept around. With most of my research on this already concluded, I set to work on design very soon. Right away I favored utilizing a pattern I’d established on a previous page: sticky subnavigation on the provider profile page.
The context and the usage here, however, would be different in a couple of ways. That subnav was for in-page navigation while this would be across multiple pages and sub-pages. That subnav had no other header styles to match but these new pages did.
What I ended up designing was a unit that established:
- a treatment type title (make it useful)
- a swipe-able horizontal list of links (make it simple)
- the ability for the current page type to be shown and selected (make it useful)
- a style related to the main treatment page (make it trustworthy)
- appearing at the top of the page (make it visible)
- disappearing when scrolling down but re-appearing when scrolling up (make it visible and noticeable)
Tested on the QA page
When the implementation became a smooth enough, quality interaction, we ran an A/B test just on this page type. The results were similar to the nav block, though not as high of a lift with the nav block still on those same pages. That gave us a clear signal to continue.
Tested across all treatment pages
Again, similar results with the highest lifts on pages that didn’t also have the inline nav block on them. All clear to roll out 100%.
Launched
I don’t have the traffic data at the time of writing this but the sticky nav also enabled a steady increase in related page traffic across the site. Across the board, a significantly higher portion of site visitors saw pages the company most wanted them to see.
Evolved global navigation
This next phase had the challenges of greater visibility within the company and more legacy of politics attached to the items it contained. It also had some bigger unknowns that needed to be addressed with research.
Building on the findings I’d derived so far about how people were using and especially not using the global navigation, I started a series of user tests with the goal of narrowing down what was going to be the most useful focus for this feature.
Several new methods of organizing the site were being discussed throughout the company, so that was on my mind. The company also had many new goals they were trying to achieve that were very different from the goals that existed when the global nav was created and last changed, several years before. As mentioned before, the device usage had also changed—essentially flipping from desktops to smartphones.
I recorded these details in presentation slides, which I updated through the course of this project to reflect the overall reasons for what I was trying to accomplish.
Simple. Wins.
I started with what’s called a tree test. It’s a way to quickly test hierarchical categorization of menus or pages to see if for example, people can find the Help pages if you put them inside the Support page vs the Resources page. The answer of course is always 1) neither, don’t hide pages if possible and 2) never create a page called Resources. It’s infinitely worse than Misc.
Seriously though, the tests I ran came with similar conclusions about simplicity. Speed, comfort, and accuracy increased when navigation options were:
- Fewer in number, especially at higher levels
- Flatter in structure (fewer levels)
- Phrased with shorter words
- Clearly separate concepts
- Easily understood words
I also found from testing between groups that had and didn’t have prior experience with the site’s industry that these rules applied to everyone equally. Jargon and complexity were barriers regardless of their knowledge.
On page beats menus
The second round of information architecture testing took the form of very basic wireframes built into an interactive prototype. I made these to depict options for how the simple winners from the tree tests could manifest on the web site; either focusing more of the selection in menus or across pages. More than just hierarchy was being tested in this phase but the core was still about that.
Similar to the inline nav block, ‘on page’ won but for a different reason: testers were more likely to explore further into the site. With the structure already simple, the speed and accuracy were already very close—so it came down to comfort and context.
Layout test options
With the basic information vetted, the question then became about display and especially so for 1st time visitors. This went back to the recently shifting goals of the company and aspects of the audience. The new global nav could either be slightly different or vastly different.
Elements from earlier testing I focused on were:
- Simplifying to the 2 main items of Treatments and Providers. Everything else made more sense to people when within one of those two areas.
- Keeping the total items low
- Visually differentiating the items
- Folding in “what the site is”
- Making more of a show of tone and transparency for 1st time visitors
I intentionally made each direction significant departures from one another so that testing results might be clearer to differentiate and people from different parts of the company could see how open the new choices could be. I favored a pairing of the more radical designs because I think they expressed the new goals with the greatest clarity.
More stories of how I work are available on my portfolio site.
