The menu icon has a long and storied history that long predates mobile devices. Designers have used menu icons, in one form or another, since long before touchscreen smartphones gained dominance. Plus, there are hardware menu buttons—often with iconic representations of menus similar to that shown in Figure 1.
The symbol that is now in most common use for representing a menu—the three lines that supposedly look like a bun and patty and which some refer to as the hamburger icon—even has a Unicode character (U+2630) that you can type to insert a simple glyphicon on your Web site. On mobile devices, we most often see a menu icon in the upper-left or upper-right corner of the screen, as shown in Figure 2.
But as much as I love history, in this column, I want to talk about the use of menu icons today, how they have become ubiquitous on mobile devices, and how some of the current thinking about them is wrong.
You Should Never Use a Menu Icon?
It’s easy to find articles that expound on someone’s reasoning on how the whole concept of an expanding menu is just wrong, and you are a bad person for even considering it. There is a bit of truth in these. One key contention is that such menus are bad because they don’t work for people trying to find product categories or navigate around a Web site.
The thinking is that, if we replace the reliable navigation bar on our desktop Web site with a menu of links, people will be disappointed because it’s hidden away behind a single icon or word. As one article says, “out of sight, out of mind.” Which is totally true. So, don’t do that. Of course. What else can we do?
Don’t Hide the Menu
When you are trying to find your way around a strange, new building, your sense of place and ability to navigate do not rely entirely on signage, but also the shapes of hallways, your position relative to places you’ve been, exterior cues such as things you see by looking out of windows and the direction of the sunlight, types of doors and doorknobs, and simply following where everyone else is going.
Now, think back to the last time you got lost in a designed space. It was probably something like a parking garage, where everything looks the same, and you had to rely on signs, your memory, and the internal jargon for the garage to get around. You might remember that you parked on Level B, but is a sign for B2 the same thing?
Web sites that rely on navigation bars of any sort are the digital equivalent of the parking garage. Your car is in there somewhere, but how do you find it without already knowing the garage’s internal language and structure?
Reliance on almost any strict navigation structure is flawed. When we discard all other cues in favor of trying to make users read road signs in passing, in the dark, the content seems irrelevant.
Center Important Information
Not too long ago, I was observing a test in which the subject was a mechanic in a truck repair shop. He didn’t have a computer at home, had no access to a smartphone, so had no base of knowledge. But we gave him a smartphone and an app to try out. He did fine with the big, obvious bits on the screen and performed every task. Then, we got to the tricky part. We asked him to reconnect the phone to the IoT (Internet of Things) device we were testing, then refresh the display on the screen.
“Hmm… I don’t see it. Maybe in here?” he said, tapping Menu, where he found the Refresh button. He said, “Ah, there it is,” as he tapped it.
I’ve experienced this sort of observation over and over again. Why? Well, first because of a fundamental behavior of mobile-device users, who do not scan a page top to bottom and left to right, but always gravitate toward the center. In Figure 3, you can see a chart showing where users tapped when presented with a scrolling list of selectable items.
The same preference for the center applies to tap accuracy, speed, and comprehension. When designing, I assume users view and read the center, then move outward if they do not find the information they need.
This is actually starting to become a design principle of mine. Assume that users focus on and interact with things at the center of a page, and make sure that you can live with their missing or ignoring things at the top and bottom edges.
Emphasize Information, Not Navigation
This leads to the next principle of interaction design that I try to follow: if your process relies on users reading, then selecting, you are doing it wrong. Whether it’s a navigation bar across the top of a page on a desktop computer, a product hierarchy hidden in a menu, or a list of the functions that your application performs on a landing page, this reliance on deliberate selection burdens users with discovery and choice.
What to do? First, give them information—front and center. Most of the apps and sites we use lead with the key information, then put secondary functions off to the side. For example, both Twitter and your email client show the most recent messages, and a single icon at the top or bottom edge of the screen lets you compose your own.
Icons or links on title bars or at the bottom of a screen and small sets of tabs are the most common ways of providing secondary functions on Web sites for mobile devices and in mobile apps.
The Weather.com mobile Web site organizes information by importance, as shown in Figure 4. The most important information to which the user has navigated is in the center of the screen. Secondary functions are along the edges. Plus, there’s a button at the end of the list to load additional times and a search function to change locations at the top of the page.
Android Material Design apps, such as those shown in Figure 5, use a new, even more robust method of making secondary functions more visible, while they’re still to the side, so clearly secondary.
I consider functions that people use even more rarely to be tertiary. These can reside on a menu, where getting to them takes one more level of difficulty, but the likelihood that the user will deliberately seek the functions is also reduced, so it’s fine.
YouTube is filled with information—people add 300 hours of new video each minute. With categories, channels, ads, and more, YouTube clearly is a very, very complex product. But you wouldn’t know it by how focused and simple the core user experience is. As Figure 6 shows, its primary function is to present a recommendations list on the home page.
Since I don’t work for YouTube, I don’t know for sure what their business model is, but I think it’s safe to assume that most viewing is from casual use and recommendations. Look around the edges. There’s a Music link for a new service they’re pushing, then search, and some menus on the title bar.
This layout should be familiar to anyone who designs apps or Web sites—or even optimizes them or manages projects. Search is important. We can assume that YouTube’s second highest rate of discovery is via search, can’t we?
Architect Your Solutions
That last principle of mine could be better stated as: design from the center outward. Decide on a hierarchy of tasks, then stick to it. And make the user interface reflect the hierarchy.
As Figure 7 shows, it’s best to place one primary task or function in the middle of the page, make two or three secondary tasks immediately available along the edges, and stack all of the tertiary functions in a menu of some sort.
Most importantly, design for actual devices and users. Don’t hold onto old assumptions or standard practices from other computing environments. Don’t try to turn your Web site into something mobile friendly simply by changing its navigation bar into a menu. Instead, re-architect them, and design solutions that work for users experiencing the unique user interfaces of tablets and mobile handsets.
For all of his 15-year design career, Steven has been documenting design process. He started designing for mobile full time in 2007 when he joined Little Springs Design. Steven’s work includes Designing by Drawing: A Practical Guide to Creating Usable Interactive Design, the O’Reilly book Designing Mobile Interfaces, and an extensive Web site providing mobile design resources to support his book. Steven has led projects on security, account management, content distribution, and communications services for numerous products, in domains ranging from construction supplies to hospital record-keeping. His mobile work has included the design of browsers, ereaders, search, Near Field Communication (NFC), mobile banking, data communications, location services, and operating system overlays. Steven spent eight years with the US mobile operator Sprint and has also worked with AT&T, Qualcomm, Samsung, Skyfire, Bitstream, VivoTech, The Weather Channel, Bank Midwest, IGLTA, Lowe’s, and Hallmark Cards. He is currently User Experience Architect with diesel engine maker Cummins, in addition to running his own interactive design studio at 4ourth Mobile. Read More