There has been a disappointing trend for some time now where sites rely on a hamburger menu to hide the primary navigation when viewed at desktop screen resolutions.
As a user of a reasonably large display, I find it frustrating to have to grab my mouse and click just to see a menu of what the site has to offer. Personal preferences aside, we already know hiding navigation tends to make it more difficult for the average user, but compounding it with an interface element that is familiar only to those who use mobile sites is tantamount to thumbing your nose at a large segment of users.
There are lots of opinion pieces already out there. Instead of adding yet more rant, I’ve opted to point you to some readings grounded in research, user studies, and experience:
From Nielsen Norman Group: For desktop sites, demoting your main content categories into a drop-down menu makes it harder for users to discover your offerings.
Also from Nielsen Norman Group: On a large screen, hiding the chrome significantly affects discoverability and interaction cost, with virtually no improvement to the content-to-chrome ratio.
Citing a Paralysis of Choice argument is usually a false equivalency, especially since research that is cited is typically based on purchasing physical goods (like different flavors of jam), and not on exploring a navigation menu.
Not only do all the documented usability issues with hamburger menus on mobile apply, most pre-built hamburger menu scripts fail to support keyboards well, and usually not at all. This alone makes a hamburger menu on desktop an even greater accessibility failure than on a non-keyboard-controlled device.
Sometimes it’s hard to help people to understand where a pattern or concept fails unless you can demonstrate it in action. All screen shots were captured at 3,000 × 1,750 pixels.
The first two example sites are targeted at the general public, namely tourists and recreational visitors. As such, there is no guarantee that these users have much, if any, experience with the hamburger menu prevalent on mobile sites. Neither page has a singular call-to-action, and the Visit California page even uses the text Scroll to discover (which is not a very good call-to-action). Further, the Visit California page doesn’t even support keyboard navigation, something usually not even coded into pre-built hamburger menus targeted at mobile users.
These next two sites are not necessarily targeted at the broadest range of the general public, but they also suffer from a lack of a clear call-to-action on the home page. The Design Museum has three calls-to-action, each one taking its own screen which can only be seen when scrolling. Illusion Magazine leads with a full-screen carousel before a grid of image links — with a keyboard-inaccessible menu.
The Lexus Performance site is a scroll-only novelty site. Normally I wouldn’t bother including it except it does two things I find amusingly out of touch. The first is that it has an additional hamburger menu below the primary hamburger, though it uses three dots instead of lines. The second is that the entire primary menu displays on page load, and then quickly collapses into a hamburger, teasing the user. This is amusing to me because it happens on every page load (with files cached) and it is clearly a mistake. You can see a screen shot of it in the third image below.
Essentially, if your argument in support of a hamburger menu on desktop is to help drive visitors to your singular call-to-action, then you have done nothing more than created a splash page. You are using the 1990s version of the modern pop-up, so good on you for reinventing the square wheel.
I encourage you to identify your objective (driving a user to a specific page is not an objective, a conversion is an objective) and then measure clicks and follow-on actions. Ideally try some A/B testing to help limit the likelihood that you are just building tests to support your preconceptions. Following these navigation UX tips from Nielsen Norman is probably a good step too.
In the post The Navigation Bar Is an Affordance, Stop Removing It, the author argues that making navigation blend into the hero image makes it harder to see and therefore harder to use. In my experience, that means a site is one step away from hiding it behind a hamburger altogether. If you see them in the wild, it may be your last chance to save them.
the Hamburger menu is part of an emergent design language that resulted from the rise of responsive design. It solves a difficult problem (how to represent a potentially large number of menu items on a small screen) in a relatively neat and tidy way.
First, he mentions small screen. Second, he said it addresses navigation in a neat and tidy way, which I think is still very much up for debate. I don’t argue that it is gaining traction simply from its constant use.
Update: January 24, 2016
In Hamburger, hamburger, hamburger, Jeremy Keith discusses the hamburger without defining desktop versus mobile. He does provide this simple approach to identifying if the hamburger is effective:
Representation: It depends. Is it representing a stacked list of menu items? If so, good. If not, reconsider.
Usage: it depends. Is it being used as an excuse to throw literally all your navigation behind it? If so, reconsider. Prioritise. Decide what needs to be visible, and what can be tucked away.
Clarity: it depends. Is the icon labelled? If so, good. If not, less good.
Great web design is about putting the customer in control of their journey, not controlling their journey. Great web design is functional and fast-downloading, not some carousel of organizational egos. The next time your customer wants a link, please don’t give them a hamburger.
Update: May 4, 2016
As we see more and more sites targeting desktop screen sizes using hamburger menus, mobile apps are recognizing the value in moving away from hamburgers. The latest is Spotify.
The company tested the tab bar on iOS to see how it impacted user engagement. It found that users with the tab bar ended up clicking 9% more in general and 30% more on actual menu items. The tests also revealed that reducing the number of options in the tab bar to five increased the reach of Spotify’s programmed content, the company says.
Our quantitative usability testing of hidden menus (such as hamburger icons) and visible menus (such as links across the top of pages) reveals that:
Hidden navigation is less discoverable than visible or partially visible navigation.
When navigation is hidden, users are less likely to use navigation.
If people use hidden navigation, they do so later in the task than if it were visible.
Hidden navigationprovides a worse user experience than visible or partially visible navigation does, in both mobile phones and desktop user interfaces. This finding holds true across multiple UX metrics including users’ assessment of task difficulty, time spent on task, and task success.
On desktops, hiding navigation degrades the experience and the navigation discoverability more than it does on the phones.
Hiding the navigation mostly affects content that is not directly accessible through an in-page link.
I’ve read your post and the supporting material you link, and I disagree on the whole.
You start by referencing a study that concludes that only 52% of users over age 45 understand the hamburger menu. That study only looks for an age correlation and makes no statement (nor asks the question) about participants’ prior experience with mobile devices. If you still consider this source to be a good one regardless, it also has an article against hamburger menus on desktop sites: http://www.catalystnyc.com/2014/06/hamburger_menu/
In your support of hamburgers, you state that designers like to keep things simple. Visual simplicity (or minimalism in this case) is not the same as a simple interface element. That same article you link also says “Provide More than One Navigation Menu” (http://usabilitygeek.com/10-guidelines-for-navigation-usability/), so I leave it to the reader to read it and decide which applies.
You then reference a study claiming that too many options confuse users, except the page you link is not the study, but an interpretation. The study itself can be found in the Internet Archive (https://web.archive.org/web/20080725070225/http://www.columbia.edu/~ss957/whenchoice.html) and is very clearly about buying physical goods in a brick-and-mortar store, not choosing where to click in a navigtion menu. The study watched shoppers as they chose from 24 jam flavors versus 6 jam flavors. Nothing in that study is analagous to web site navigation.
For best practices, you say that it is not a requirement to pair a hamburger with a label. In fact, it is. In order for the menu to satisfy accessibility tests, standards, and the law (such as Section 508), an author must provide some kind of accessible name — whether by a visually-clear label or something in the mark-up that assistive technology can use: http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html. Further, one study notes that the word “MENU” performs better than the three bars: http://exisweb.net/menu-eats-hamburger
As an aside, you do not define an age for “elderly” when you use it in this section. Earlier in your piece you identify the older half of the study participants as 45+. Since that study only has two age brackets, you’ve effectly called the first generation of web pros elderly.
You talk about pairing the menu with a strong call-to-action to be effective. I agree on this point. Your example is nothing but a splash page, so I can see why hiding the navigation is of interest here.
However, that same example claims increased click-throughs to the landing page, linked from the giant pink button. If your only goal was guiding users to click the only remaining obvious clickable element on the page, then I see how that would be successful. I’d be more interested to know if that increase of “hits” to your target page corresponds to some sort of increase in conversions (whether they be calls, sales, leads, etc). Otherwise I think you may be repeating the same mistake of the mid-90s splash page (something that elderly first generation of 45-year-old web developers has already learned).
I too really dislike the hamburger menu on larger screens. It’s just a sign of either laziness or lack of skill from the designer and/or developer.
The way I tend to do it is display the standard horizontal menu on larger screens, and below a given threshold display the burger burger icon with ‘menu’ and ‘close’ text next to it depending on the state.
Ideally though if there’s only a limited number of items I’d try to avoid the hamburger menu on all screens.