What we have designed + engineered: the story of our navigation model for Stanford Sites
Navigation is one of the most important functions of your website. Meant to organize your content into discernible sections, good navigation affords users intuitive pathways to discover or find content. Without good navigation, the effort you spend creating meaningful and compelling content is diminished if a user cannot find it.
Achieving good navigation is two-sided. There is the work of a content team, deciding what the navigation actually is, what the pages are called, and how to organize them—your sitemap. The other side of that content and architecture strategy is how the system actually functions technically. What are the interactions? How are they displayed? How does a user understand where they are on your site? How does the navigation work on desktop, and collapse down to mobile?
Stanford Web Services and University Communications have worked over the last several years (and will continue to) in persistent iteration on our navigation model. Our goal has been to refine multiple implementations into a single, robust, and fully tested model that would be available in our Decanter Framework, and WordPress and Drupal platforms.
That single model is now available. Designed and engineered based on secondary research findings from industry leaders, our own independent research, and conforms to the AA accessibility standards as defined by WCAG 2.1.
Where we started: secondary research
Our first step is always to look across the research from our industry leaders. What can we learn from the existing domain of knowledge in navigation design and engineering? What conventions have users become accustomed to on the internet that we want to take advantage of with our solution? What trends may we want to avoid that prove not to be user-friendly?
(Disclaimer: the age of the following research may degrade the findings over time.)
We find a great wealth of information from the prodigious work of the Nielson Norman Group. We looked at a many numbers of articles they’ve written on the topic of navigation, a number of them highlighted at the bottom of this article.
Based on that secondary research, here are some of the specific items we implemented:
Display a link to “home” in your main navigation
Display navigation when the screen size affords the space—as Nielson Norman states—“if you can show it, show it”. Specifically, on desktops, we deliberately display primary navigation in our header, which is visible on every page. A left sidebar of links is also visible on any page with subpages.
Include the word “menu” with the hamburger icon, to increase user understanding and recognition, that this is where to find navigation on mobile
Indicate with some visual differentiation, where the user is on the site
Where we went next: our own research
Accordion or split-button mobile navigation menus?
There was also research that left us with a pause. Specifically, how to engineer the interactions of our responsive and hover-menu navigation. For a time, we actively designed and developed two different mobile interactions for our navigation, accordion, and split-button, because we found it too difficult to decide without tests. The Nielson Norman Group had suggested we employ an accordion style, instead of split buttons, but in our own navigation model—used on various platforms, namely Drupal 7—we had used the accordion model but were unhappy with it.
What is the Accordion model?
The accordion model presents users with a type of interaction that would expand menus on-click, on both the text link and at the downward facing icon. The only way to see the menus below would be to click the text or icon and expand the menu. This implies that a user cannot click on the text itself to go to the top-level landing page, they first have to open the menu, then click on the text with some additional word like “Overview” or “Explore XYZ”. In this example, we’re forced to create a second menu item called “Explore Admissions & Academics” in order to afford the user the link to go directly to that landing page.
What is the split-button model?
The split button model allows a user to click on the text of a link at the landing page level to go directly to the page (no “Overview” or “Explore xyz” link needed), or click to expand the menu with the downward-facing arrow.
The goals for our users
- With either model, the business objective was the same. The business wants users to hit those top level pages as the content presented on these pages is enormously relevant to the end-user, providing them the contextual keys to their find or browse tasks.
- Confirm through usability testing that a user knows where and what to click or tap, and their expectations match the outcome of those interactions.
- The interactions are easy and user-centered.
Accordion navigation model
This approach to navigation forces a duplicate page to be made for a top level of navigation because when a user clicks the text link of a page, that click opens a menu, it does not take the user to that page.
This is problematic for any pages with pages below itself. Those pages will need a duplicate page with some additional term to help a user understand that they must make a second click to visit that page. As you could imagine, we had concerns about this, both from design and engineering perspectives. We didn’t want to make weird duplicate pages called, “Admissions & Academics Overview” or “Explore Admissions & Academics” when the text link itself should be the endpoint of task completion.
Split button model
A split-button model presents the user with a text link, that when selected will take that user directly to that page. But it also provides a second interaction with a down-facing-arrow, to expand the navigation items below.
p dir="ltr">Based on the Nielson Norman study, there are inherent issues with a split-button model.
“Although users will probably be able to achieve their goal whether they use the menu or the category landing page, they will be unpleasantly surprised when the site won’t behave as expected. When it comes to touch gestures, users are rarely precise or consistent: sometimes they will tap the arrow and sometimes tap the label, looking for the same result. If the interface does different things after two instances of (seemingly) the same user action, it will seem buggy and erratic.”
But we couldn’t ignore that through this model, a user would be able to drive directly to the link text without an additional click or through a weird secondary page that is needed in the accordion model.
So we needed our own research
Though we were presented with secondary research from industry leaders, internally, we just did not agree with their findings. We had hypotheses of our own, and details in our questions that were not covered in industry research.
What we found
We spent a series of five research studies on our navigation to date. The first two studies were deliberately divergent including a mix of questions directed at both visual design and usability. They gave us a place to start, but are not as relevant to this article. Round three focused in its attention to usability for accordion versus split-button, but it revealed test-flaws—not uncommon—so we moved into round four.
Round four revealed an interesting outcome to our question, “in which model are users more likely to select top-level landing pages”, a primary business goal”. Outcomes are described below.
Round five—which focused on the usability of mobile navigation functionality—found both accordion and split-button interactions to be sound.
The unexpected outcome of research study 4
Format: our study was specifically shaped for desktop interactions. That is, the user interacted with our navigation on screens over 1024px wide where the header was fully present and sub-navigation was displayed in the left sidebar of interior pages. No user used “tap” to interact with the test sites. Users were presented with hover-menus at the top-level navigation in the header, which revealed navigation below it where it existed.
Primary goal: do users visit landing pages more often through a split button or accordion?
Secondary goal: is the usability of the desktop navigation sound and intuitive?
Users did not make it to top-level pages more using either model, failure rates were comparable.
The usability of navigation on the desktop is sound. Users understood where navigation was displayed, how to find it, and how to interact with it.
Due to the presence of hover-menus for each of the top-level navigation links in both tests, users rarely hit landing pages at all.
Additionally, displaying these hover-menus puts a lot of pressure on the navigation structure—the sitemap/information architecture—to be really, really well designed and tested (lots of testing). That really, really good navigation, for all the levels that are visible (including that hover menu), would have to include the terms that users have in their own heads to get to the content they are looking for. For that really, really good navigation to be framed in that user-centric way, the team creating that navigation would have to be mind readers (for lots of different kinds of people) or, would have run their navigation through lots and lots of user tests to confirm that the terms they selected were the right ones. And even still, that leaves the potential for users to misunderstand a term under a certain section—as is true for all humans—without enough context, make assumptions, and go down the wrong path. And this is why we think that the removal of these hover-menus, forcing users to go directly to the top-level page, where the context of the subpages below it is clearly present on the page itself providing significant contextual information to help them understand what content is in fact nested in that section. Theoretically increasing the likelihood that a user will find the content they are looking for. Users will always go down unintended paths. The removal of a hover menu isn’t going to make task completion for a user perfect. But it may remove some of those wrong paths, increasing the usability of the site.
Research outcomes at work
Based on our research outcomes our default, out of the box Drupal 8 platform includes:
Split-button navigation model where users can go directly to the text-link of a page through navigation terms and expand/collapse pages below where the UI presents expand/collapse icon-buttons
By default (though it will continue to be available on the platform by request) the platform does not include hover-menus on the desktop primary navigation items in the header. Instead, users go directly to top-level pages.
With two research outcomes that were unexpected, many others confirmed, and many tests needing to be tested themselves, the effort put into creating a sound user-friendly, and accessible navigation model has proven invaluable. As navigation is one of the single most important functions of any website, we knew it deserved an immense amount of attention.
Like any other element of a digital product, we will continue to monitor the usability of our navigation model and continue to test it against web conventions, trends, best practices, and secondary research.
Below, you can learn more through the secondary research we used in our own work.
Our user experience and user interface practice actively seek secondary research from industry leaders to inform our positions and recommendations on work. Often, pre-existing studies inform us to the extent that conducting our own research would be a superfluous and poor use of resources. Where the research is limited, not conducted, or where we may disagree with industry findings is where we may choose to conduct our own independent research.
We wanted to share some of the research from industry leaders that we have used to learn about user behavior with respect to navigation, information architecture, finding information, responsive design, and more.
Summary: On a website, “navigation” doesn’t mean just links. Navigation is, like most elements of a website, about communicating with the user. Good navigation tells a story, and good stories have a beginning, middle, and end.
(Disclaimer: this article is still relevant, having been written during the prehistoric era of the web, 2006)
Summary: To decide whether to visit a page, people take into account how much relevant information they are likely to find on that page relative to the effort involved in extracting that info.
Summary: A site logo linking to the homepage is not enough. Logo design and placement, as well as the presence of a text link to the homepage, affect the success of navigation to the homepage.
Summary: Information can be organized in either flat or deep hierarchies; both have their advantages and pitfalls.
Summary: For desktop sites, demoting your main content categories into a drop-down menu makes it harder for users to discover your offerings.
Summary: A key question in information architecture (IA) is to decide the number of items in navigation menus (including global menus and local menus). 4 main factors determine the answer, but it's not 7, despite a common myth.
Summary: You-are-here navigation consists of signs that help orient website visitors as they explore the site. Many websites need stronger location indicators.
Summary: In both applications and websites, users rely on menus to find content and use features. Use this checklist to make sure your menus do their job.
Summary: There's a footer at the bottom of every web page, but the design of this utilitarian page element is often overlooked, making the website perform below its potential. In our usability studies, users often turn to page footers for important information and tasks, making them an integral part of the overall experience of a site.
Summary: While it is important to keep key information easily accessible, the 3-click rule is an arbitrary rule of thumb that is not backed by data.
Summary: Looking specifically at responsive navigation. We will first talk about information architecture, then the purpose of navigation, and finally we will look at three responsive navigation patterns that have served well over time.
Summary: As a general rule, most Web developers, especially usability enthusiasts, say it is bad practice to use drop-down menus because they are confusing, annoying, and oftentimes dysfunctional. From a design standpoint, however, drop-down menus are an excellent feature because they help clean up a busy layout. If structured correctly, drop-down menus can be a great navigation tool, while still being a usable and attractive design feature.