Mobile Navigation Starts with the User

mobile navigation user on the go

On Mobile Devices, finding your way on apps or websites of any significant size can be frustrating. You’re faced with one of three options: limited navigation items that fit on the side or top, truncated to save room with a link to “view full site”; navigation options buried under difficult to click sub-menus (if you can even see them); or solutions that feel too smart for their own good that end up causing far more confusion.

It’s rare to find innovative mobile navigation solutions, and that’s not a bad thing. Now that we’ve had several years to get our heads around mobile devices and responsive layouts, we’re starting to see what works and what doesn’t. Unfortunately, all too many mobile navigation solutions are applied in the wrong scenario for the wrong reason. So while most navigation solutions out there now are pretty good, it’s the application of them in individual scenarios that presents today’s challenge.

Notably, UX and development teams are working from frameworks for both website layout and mobile app functionality. These frameworks includes Bootstrap, Foundation, Google Material, and the like. Each of them have effective mobile navigation solutions, sometimes several, but they’re for specific products, services, or concepts.

The problem is that navigation, and by proxy Information Architecture, tend to be an afterthought driven by either the convenience of the framework, the existing content structure or codebase, or (even worse) the organizational structure and org charts. By taking a poorly thought out navigation, and applying it with a boxed framework solution, we end up with navigation patterns that are familiar yet frustrating to use.

Users Come First

Rather than starting with the code, framework, or even the design, navigation should always begin with the user. More importantly, navigation is one of many outcomes in developing a sound Information Architecture. The best path is, well, a path–specifically, a User Journey Map or Customer Journey Map. The purpose of either of these is to get to the heart of the individual user’s story from her perspective. What this means is that we’re trying to sort out what she wants to do and how she’s going to do it. It’s important to point out that these tools are used for far more than navigation, but they are critical to understanding the architecture and way-finding of any large app or website.

Navigation is not Information Architecture

There’s a tendency to merge Information Architecture and Navigation into a single concept, especially among mobile app designers. The difference is far more than semantics. The Information Architecture of any application or site is the foundation of where everything is and how it’s related. Navigation is a user interface element, and means, to get to **some** of the things in the site and application’s architecture. Not every page, section, or tool can or should be reached from the navigation UI element. Information Architecture is based on understanding the user and her needs, navigation takes Information Architecture and the design of the site into consideration to create a user interface element that can be used to move throughout the site. If your app or site were a building, Information Architecture would be your stairs and elevators, navigation would be your fire escape.

At Nine Labs, our approach to designing and building the navigation of any application or site starts with the user journey. This includes mapping out each possible path a user could take to arrive at a particular goal or key action. Along the way, we denote detours and derivations.

journey map

From here, we stress test each scenario to ensure that the user can always find her way back or forward with as little friction as possible. From this exercise, we begin denoting where we may need navigation elements or help functions to get the user to their goal without frustration.

journey map with friction points identified

From here, we create a hierarchy of information to understand how information is grouped. Typically information and pages can have more than one parent, but having too many parent or “top-level” pages can make a site difficult to navigate. There’s a lot of trial and error here to determine the best balance between top-level elements and over-reaching groupings. We document this in a “tree” format, typically as a mind map.

mind map for the committee to protect journalists

After determining the best path for each user and the Information Architecture, we then determine how navigation will be implemented. We typically ask three questions: Will it be universal for all users or modified based on context, status, or use-case? Will it be simplified for mobile or presented in a different manner? Will we progressively reduce the navigation as users gain experience?

A good example of this process comes from a recent overhaul we did for a leading hotel brand. Their mobile application was filled with navigation elements and sub-elements that had been added over the years to meet some individual users’ needs (good), but without anyone taking a look at the flow and journey that made sense for each user (bad). Also, business units within the organization had each fought to get prime real estate for their product or program, resulting in a disconnected hierarchy of information. Our job was to untangle the wires and sort out how to get 5 key users, grouped into personas, to particular goals in the application. From there, we would simplify the steps needed for general use cases to accomplish common goals, and then build progressively reduced navigation for advanced logged-in users.

The application is currently in development, but as we’ve seen in testing, it’s reduced friction and frustration across user types and allowed the client to still push the business units to their respective target audiences. Users are accomplishing tasks in half the steps in some scenarios, and they’re finding their way around with much greater ease. Long-term and power users are seeing a faster experience to accomplish their common repetitive tasks.

In this particular project, we selected the most common navigation pattern for mobile, off-canvas navigation. Off-canvas is usually placed on the left side of the application and slides into view after pressing an icon, usually the hamburger menu.

Off-canvas navigation can be found in most of the major design frameworks and is an effective pattern for a few reasons. It allows a longer list of navigation elements since it uses the device height, which is usually longer. It also allows nesting for some hierarchy of information, and off-canvas menus can be stacked to mimic dropdown or secondary navigation patterns on desktop.

Off Canvas Mobile Navigation Sidebar

Another good example of our process comes from ongoing work we’re doing with The Committee to Protect Journalists. While their site navigation wasn’t in bad shape, it was driven by organizational structure rather than the logical arrangement for the end-user. But more importantly, how the site was arranged and organized from a technology perspective was a recipe for future headaches. Our job was to completely restructure the database and the Information Architecture of the site to create strong relationships across content types rather than tenuous connections using loose techniques such as tags and hashtags. From these exercises, we simplified the navigation and  moved items to their logical home, rather than their organizational parent.

CPJ Information Architecture layout

In this project, we selected the top-down menu pattern. We then duplicated the pattern for in-page menus and the footer. A top-down menu slides down from the top of the page. Usually, it’s triggered by an icon, such as the hamburger, or the word “menu.” It works well for a short list of parent navigation elements, less than 7, and if it’s critical to always have a search box in view or within a single tap.

Hamburger Icon mobile navigation examples from Starbucks and Ableton

For most mobile apps, the common solution is a bottom navigation drawer, typically limited to four or five options.

mobile navigation bottom drawer examples from instagram

Some will offer a “junk drawer” option with an icon or word to indicate that it can be opened to view more options.

mobile nav junk drawer example from fitbit

For sites with complex navigation or large Information Architecture hierarchies, this solution is rarely best. It should be reserved for single-task mobile applications or consumer websites with a major area of focus, such as eCommerce or social posting.

No matter which solution you choose for mobile navigation, start with the user. By focusing on the clearest path to each goal while minimizing friction, the likely solution will rise to the top without much hassle. There are only a few common patterns for mobile navigation. Choosing the right one comes down to finding out where things should be before you determine how to get to them.  From determining how many parent elements are at the top-level to how the navigation itself is triggered, the process isn’t for the inexperienced and certainly shouldn’t be blindly determined based on the framework chosen.

At Nine Labs, we love solving complex navigation problems. So much so, that we’ve solved them for Fortune 500 brands that had lost hope that anyone could, and we had fun doing it! If you’d like to have us take a look at your navigation and Information Architecture challenges, let us know!