Thirty years ago, navigation was something only pilots and ship captains did regularly.
Today, navigational systems are a ubiquitous part of our daily lives. We attempt to find our way around applications by pointing our fingers at lists of tersely named labels. Hopefully we get what we expected, if we had any expectations at all.
The navigational list-o-links is already a deeply ingrained paradigm, adhered to with the assumption it works well. Product development moves too quickly for designers to invent new methodologies every time, and because users are familiar with the form, we might as well just stick with it, right?
Play it safe?
Designers are taught to create interfaces that people understand instinctively, to use patterns they’ll know how to interact with. Reduce cognitive friction, give them a little squirt of endorphins, and make them feel good about your recognizable navigation menu bar. Keep it simple and don’t reinvent the wheel.
This attitude is usually meant well, but often accompanied by complacency — at worst, mindlessness. Once it’s decided that a standard navigation menu is the way to proceed, critical thinking often stops, and any link suggested by anyone and their mother is dumped there to collect dust, regardless of whether anyone might click it. Good intentions backfire, and users have a hard time finding anything relevant.
Focus on goals, not options
Barry Schwartz, in his book The Paradox of Choice, discusses the steps people take when encountering a set of options to decide upon:
Figure out your goal or goals. Evaluate the importance of each goal. Array the options. Evaluate how likely each of the options is to meet your goals. Pick the winning option. Later use the consequences of your choice to modify your goals, the importance you assign them, and the way you evaluate future possibilities.
People use applications and websites because they want to buy something, or meet someone, or learn something, or complete some task. Presumably you know what goals your users are afforded by using your application, and ideally you have some idea which of these are the most valuable. Users don’t want to navigate.
The existence of multiple alternatives makes it easy for us to imagine alternatives that don’t existBarry Schwartz, The Paradox of Choice
While people have an idea of what they might wish to accomplish when using your app, they don’t necessarily have a clear mental model of how to achieve it. A successful navigation system should provide a framework for evaluating possible goals, making a simple decision about what to click, and understanding what will happen when you click it. The more choices you provide, the greater the sense people have that they’re making the wrong one.
Reducing choices to the smallest possible number makes it easier for people to connect their (potentially vague) goals with the actions they can take, and feel less anxiety about the possibility of going down the wrong path. Focus your application on the tasks your users most likely want to complete, and eliminate everything else. Use a consistent voice and make it abundantly clear what action is being triggered by clicking a link or a button.
The best navigation is no navigation
The term “navigation” implies a wide open sea, with no particular direction preferred, and no spot looking much different than any other. Go any which way you like, you’ll find something useful… maybe. Or you might just keep floating until you have no idea how to get back to where you came from — a sad, rickety dinghy lost in the waves.
What we have discussed so far makes the underlying presumption that our navigation presents a set of global, coequal choices. For most applications and websites, however, at any given time there are one or two relevant tasks we are asking the user to complete. Even a simple brochure site should have a primary task, typically initiating contact and generating a business lead. The more clearly we point to these key tasks, the more likely a user is to complete them.
The easiest choice we can ask someone to make is no choice at all. Rather than giving users an open sea to navigate, we should aim to provide a focused set of paths. A path is one-dimensional, allowing someone to see clearly where they are going, where they have been, and what possible deviations might be taken. There may be choices at each waypoint, but those choices are not necessarily equivalent; they are contextual and possibly weighted.
A path is a story
There are myriad techniques one can use to design a path-finding system that doesn’t ask its user to navigate, but they all essentially boil down to one thing: write stories. When designing any application, think about tasks by writing stories with a plot, a setting, and, most importantly, a character.
What is the character trying to achieve? What motivates them and what difficulties do they face? What’s the environment in which the task takes place? What are the surrounding conditions that could affect its completion? How does it play out? What are the steps the character takes to get from evaluating their goal, to taking action, to success and reflection.
By thinking this way about each of the tasks available to our users, we are setting them up for success, not dropping them in the sea and asking them to find their own way. There is no one-size-fits-all design solution that will fulfill every story. There is no universal navigation system that will get every user from A to B to Z. That’s the point. Every story is different.
So, let’s give navigation back to the ship captains.