x

Love our Articles?

Sign up and we’ll send you new ones every month.

Written By:
Fanny Vassilatos
Ceara Crawshaw
Visual drawing of a map of a couple city blocks showing a pink dotted path from one point to another on the map

The Cartography of The Internet

In UX, ‘navigation’ includes all functionalities and visual cues that people use to orient themselves in any digital product. When we think of all the digital places we go, navigation is the wayfinding system that makes or breaks someone’s understanding of where they are, where they can go, and how to get there. It’s critical (and we aren’t using that word lightly) to treat navigation as a keystone of your product because it speaks to basic human needs like clarity and safety— essential preconditions to getting anything done at all.

Why does navigation matter?

By definition, navigation is a process rather than a single thing. Think of a road trip… your product’s navigation is, all at once, the GPS, the road network and the car. Navigation in products is both pointers to places as well as the places themselves. 

When navigation is well-designed, a user can find delight in how much time they can save by using your product. Conversely, when navigation is poor, somebody might be trying to complete something stressful and end up feeling they are in an abyss making them even more stressed.  

Why is navigation relevant to Enterprise UX?

By their nature, enterprise products are biggies; they house a ton of information and functionalities for a diverse group of users. What is more, enterprise products are supposed to enhance the productivity and efficiency of a team. It should go without saying that wasting time just navigating is an important problem to solve and avoid. For example, a manager uses an HR platform to view analytics about her team’s vacation time while her employee uses the same platform to request vacation time. A well-designed navigation will help both these people complete their task quickly so that they can move onto something else.

Common Mistakes

Verbiage that doesn’t match people’s thinking

It’s important to avoid using confusing labels in a navigation. This might sound basic to you, but we often encounter products whose navigation labels seem to make sense together and sound nifty (ex: Build, Manage, Learn) or on-brand (ex: Ignite, Imagine, Inspire), but totally miss the mark on making enough sense to users. 

It’s impossible to label your navigation elements properly without understanding how your users navigate these concepts in their mind. Take a non-tech example: your roommate might think it’s helpful to group your spices into categories by cuisine or region, but imagine how it might feel for you to navigate that when your mind is just looking for the word “cinnamon.”

Therefore, be careful and empathetic when it comes to labeling. Your multi-departmental enterprise users might find it more natural to use nouns like Settings, Employees, Analytics instead of verbs like Build, Manage, Learn

Lack of predictability

Some features in your product might benefit greatly from being surprisingly delightful, but navigation does not. During a user test, you might ask someone to tell you where they think a navigation item will lead them, and you want them to be right every time – especially when we’re talking about a back button, my dears. Given that enterprise products often touch fundamental matters like the financial projections of a business or someone’s identity and tax records, you’ve got to make people feel safe as they navigate and execute functions.

Poor predictability occurs often in products that are designed to help people go through complex workflows. For example, we worked on a project management product for enterprise where each stage of the user’s project is explained with a ‘wizard’ progress indicator. In the product, when you click on a project, you would either end up in the most recent place you were, or you’d end up on a results page (with a generic design across projects, no less). Users found this logic really unclear; the unpredictable behaviour in the navigation created a sense of mistrust for them.

🔥 Hot take

This language might sound strong to you because we’re talking about navigating tech platforms, not fending for our lives in the woods, but people get very scared when they feel lost in enterprise products. Emotions are heightened when roadblocks appear as you’re trying to get somewhere important, somewhere that feels obvious to you. We’re speaking to basic human needs for security here, so be mindful of how something as simple as language can inspire or spoil that.

Modern nav hodge-podge

It’s okay for a product to mature over a long period of time, but this can sometimes lead to weird navigation problems. For example, we often see a mix of navigation styles originating from different eras of a product, like a new nav on top of old software, or, worse, opening up an iFrame of new software inside an old platform. These issues are normal to come across, given the emphasis that our industry places on prototyping and low-effort solutions, but beware of letting these Frankensteins linger. And, just in case you need to hear this: you can let go of your legacy navigation.

coinbase navigation ux switch between modern version and legacy version

Didn’t think we’d find a legacy navigation hodge podge example in the crypto world, but hey, goes to show how this stuff can just creep up on any product, even Coinbase!

Things to consider

Follow these prompts as you embark on designing and building your navigation with your team (or yourself).

Map out the IA, making sure housekeeping is done

The first step of our approach to mapping out information architecture is to take inventory of all your content across places and functionality. With all your content mapped out, you can do a consistency-check: 

  • Does all this language make sense to the people who need to use this? 
  • Where did I come from to land on this page or end up in this state? 
  • What are all the paths I could take to land here? 
  • Am I in a nested menu of any kind? If there are breadcrumbs, are they all relevant? Would anyone understand them? 

Then, consider personas and permissions

Now that you’ve made a map of your information architecture (the ‘what’), the next layer is about who is using what, and to what degree. This step will help you uncover any hotspots of activity or other insightful patterns for particular user personas that might otherwise be overlooked. For example, the content on an analytics page might need to be categorized or organized in such a way that it serves distinct user mindsets like a manager vs. an employee.

Do a product analytics check 

Take the pulse on your product’s usage analytics. Pay a visit to the Fullstory’s and Mixpanel’s you’ve got setup. 

  • Observe how people move around
  • Which pages do they spend time on? 
  • How easy is it for them to get there?

Pull out the support tickets you received over the past 6 months that sound like they’re about navigation issues. Gathering that quantitative and qualitative data can be a good first source of gold to identify recurring pain points.

Identify problem areas

All this mapping will help you see tricky areas in your navigation that might require a bit more design attention. For example, there might be two functions that logically exist in totally separate areas of your product, but are otherwise very closely related in one very popular case. Design challenges like these are important to identify early and treat with care. 

Having trouble finding these tricky spots? User interviews are an obvious win, but you might already have access to plenty of insights if you look for any commentary relating to confusion or time wasting in your user feedback and feature requests. These problems are likely navigation-related.

The craft-your-language moment

Finally, it’s time to take everything into account and make sure everything is labelled in a way that people will appreciate. Here are some prompts to guide your thinking: 

  • Does this language resonate with all use cases? If not, and if it’s impossible to find perfect language, how might the design solve for that differently?
  • Are there synonyms anywhere? We want to avoid those! 
  • Beyond synonyms, are there any concepts that overlap? In navigation we always aim for black and white.

Labels can be especially difficult in enterprise software because we have to use an abstract term to refer to something—and that something is inherently abstract and technical. For example, we were working on a settings feature set. The settings were related to an automation in the software, it allowed you to specify if you wanted a file automatically attached, or manually attached. We came up with ‘attachment method’ for the label, but could have used words like “mode” or “style”. We decided “mode” had too much overlap with mode switching in the UI, and that “style” made it into a psychology term “attachment style”. 

All this to say: make sure that you don’t use any synonyms willy nilly when working with abstract language. A basic understanding of the label is fragile enough in the first place—even a slight deviation can erase a person’s understanding totally.

☝️ Don’t optimize for God-view only

Make sure you consider access levels in the nav structure you create. You might be able to save people from seeing and mentally processing useless information or functions simply by distinguishing what a user sees using permissions logic. This approach can be very useful, but be careful to avoid creating cases where users with lowest permission levels see a navigation that is far too bare. If you design your navigation so that it looks and works great for users with high permission levels, make sure it works just as well for all other access levels that might have only a handful of items visible.

The anatomy of navigation

There are 3 fundamental approaches to designing navigation: object-oriented, task-oriented and workflow-based. With a solid understanding of each, you’ll be able to mix and match when appropriate. 

The difficulty with nav is knowing when to break your rule and when to keep your rule in a way that maintains a coherent way of thinking across the whole thing. We know how good it feels when design follows simple and coherent rules in the face of complexity, but the right nav—that is, the most human-centred and efficient one—will likely require more than one of these 3 approaches. 

It’s really up to you to create the most human-centred way to make them all work, to think through the experience of transitioning between navigation styles and to reassess your navigation as your tool grows. 

GIF alternating between a diagram of Object-Oriented navigation structure and Task-Oriented navigation structure highlights how the same elements are just placed differently

Notice how the exact same elements can be remixed from a task-oriented structure to an object-oriented one.

💁 UX Tip: What ‘perfect IA’ can mean

Strive to build a brilliant IA, but don’t freak out if a feature needs to live in multiple places in your product architecture. Maybe something has a deeply nested home base, given the robust logic of your IA, but it also needs to be quickly accessible for a certain user persona on a daily basis. It’s better to prioritize your user’s need for convenience over a ‘perfect IA’ all the time.

Object-oriented

Diagram showing the structure of Object-Oriented Navigation. The top level items are are "objects" (Clients, Publications, Campaigns) and the second level items are tasks (Analyze Sales, Manage Publications, etc.)

An object-oriented navigation organizes content under typically noun-only categories. This approach exudes more of a “drilling in” dynamic between your users and the content, making it useful when your product handles a complex or diverse set of use cases. For example: Chidi the CFO clicks on Publications to Analyze Sales for their monthly board meeting, whereas a Pip the Account Manager clicks on Clients to access Client Accounts

Object-oriented navigation can be an elegant choice when user access is already object-based in the software (ex: only Account Managers can see the Clients label) or when your database is composed of objects that can have actions applied to them (ex: distinct Campaigns that can be created, managed and tracked, etc.) 

Conversely, an object-oriented approach can be a really convenient trap for cutting corners over time (this is bad!). You might find yourself thinking, “Oh, we’ll just add a whole section about Parking instead of thoughtfully integrating it into the existing navigation,” but then your product will accumulate items over time without giving enough thought to their impact on the IA. 

Task-oriented

Diagram showing the structure of Task-Oriented Navigation. The top level items are are "tasks" (Create, Manage, Analyze) and the second level items are objects (New Client, New Publication, New Campaign)

A task-oriented navigation is a better fit for products that have simpler workflows or whose users share the same intent. A common one here is Create, Manage, Analyze as an overarching structure, within which you can continue with task-oriented approach, or switch to object-oriented, as long as it’s clear and consistent. 

For example: A Managing Editor at a publishing house uses Create to kick off a New Publication or to add a New Client to the database. They use the Analyze portion of the platform to stay informed of Sales, Social Media Performance, and Audience Data. On the other hand, the marketing people at the same company never use Create; they spend their days on Analyze in order to build the most up-to-date campaigns and strategies.

We love that task-oriented navigation makes it easier for users to understand what they can do on a page and generally inspires a more active relationship between them and the software. This benefit is especially relevant in an enterprise context where products have a sizable learning curve.  

Don’t do this…

Animated example of what not to do: side navigation with overpopulated second-levels, and an unpredictable mix of object-based items and task-based items

This example shows overpopulated second levels, as well as an unpredictable mix of object-based items and task-based items.

Workflow-based

Diagram showing the structure of Workflow-Based Navigation. Small boxes flow from Start over to Phase 1 then down to Task 1, Task 2, then over to Phase 2, then down to Task 1, 2, 3, etc until Completion!

A workflow-based navigation is useful when you’re dealing with a lot of guided steps; not much exploration. This can be the case when your product helps users complete tasks that are both pre-determined and complex. 

For example: A homeowner is applying for financial assistance on a government website. They have to Learn About the Program, Upload Documents, Fill Application Form and Review Application before they Submit.

A workflow-based approach is pretty much your only choice when your software or website needs to guide people through a long process; but, if it’s not the perfect fit for your use case, it can make users feel stuck and frustrated, leading them to abandon your product. That’s why it’s important to think through how your workflow approach behaves, maybe mix and match with another approach, all depending on how your clever design brain reads the need.

UX Patterns you can use

Breadcrumbs

Like the pin on a map, breadcrumbs are great for helping someone understand where they are and where they’ve been within a workflow or within an information architecture. Beyond that, they can also be a navigation tool if you allow users to click on previous steps in the breadcrumb.

🔥 Hot take

You don’t need a back button! With the browser’s native Back button, the breadcrumbs and your nav, there are already plenty of ways for users to find their way back. Custom back buttons are confusing in that they make users feel as though using another Back might lose their data.

Zoomed-in view of an application in a web browser showing 4 ways to go back; the browser's back, the app's navigation, the breadcrumbs and an unnecessary custom Back button Zoomed-in view of an application in a web browser showing 4 ways to go back; the browser's back, the app's navigation, the breadcrumbs and an unnecessary custom Back button

💁 UX Tip: Mind your breadcrumbs!

Maybe you’re dealing with one of the many challenging scenarios we’ve come across: like a non-linear workflow with some loops; or an IA where users can go 10 tiers deep; or an IA with multiple ways to get to one place; or a need for really long labels; or labels that users customize and render confusing; or labels that must have a 10-character long prefix that essentially hides the page’s name from view… —we’ll stop there and just stress that, in enterprise products, it’s crucial to design a model for your breadcrumbs that looks good at scale and takes your unique challenges into account.

Customization & Personalization

Giving users the power to customize their navigation can really elevate their productivity when your enterprise product serves many types of users with diverse roles and functions. For example: 

  • Favouriting or starring are great examples of manual customization, allowing users to just focus on what they decided was important to them. 
  • Navigation can also be automatically personalized to your users using data-informed or conditional logic. A common example is promoting a place when it hits a certain metric, or hiding it when it’s empty.
Interaction example of hovering on a navigation item to reveal a contextual menu in which users can favorite specific items and create their custom navigation

Progressive Disclosure

Animated example of hovering over navigation items to reveal the second-level in a dropdown menu, within which we can hover again and uncover third-level items in another dropdown menu.

Progressive disclosure can help you keep things light in situations where there are a lot of possible paths. This pattern is only successful if you have good labelling and IA, so be thoughtful about it! For example: A multi-level menu (with solid hover and click states) could help you see what pages or functions are possible within Campaigns before you dive into one.

When your navigation does not go as deep as your IA, it’s helpful to also offer a landing page or index page that displays more levels of information. This way, instead of going many levels deep in your actual menu, you just guide people to the ballpark they need and take it from there. In the case that you use this strategy, you often have more real estate. This extra room on a landing page can be an opportunity to point people to other places in your product or add other information, like descriptions. This is a good approach when a product is too complex for most users to navigate easily, or there’s just way too much to do in a secondary menu. 

Omnibars & Keyboard Shortcuts

Collage of 4 omnibar examples from existing applications. Alfred for Mac, Slack, Spotlight Search on MacOS and Superhuman

Omnibars are keyboard-first components that live at the intersection of navigation and search. Common examples shown above; Alfred, Slack, Spotlight on MacOS and Superhuman.

 

Beyond menus, there’s a strong use case for a more ‘organic’ navigation. For example:  

  • An omnibar can help users find what they’re looking for in one step. Some examples include Spotlight on Mac that helps you navigate your entire computer in one go, Help in Google docs that searches all the menu functions and help articles at once. Be careful when choosing this approach: it demands that the underlying information architecture is well documented and ‘plugged into’ the search engine.
  • Keyboard shortcuts allow users to type their way somewhere. People who use computers a lot always appreciate this kindness. Couple this with customization and you could offer your users keyboard shortcuts to their most used areas of your product.

Wrapping up

A successful navigation is not necessarily simple, but it is predictable. At any moment, ask yourself: Will people know where they are, what they can do here, how to get to where they want to be, where they have been and what’s next?

Your feelings are correct: navigation is a doozy if you want to get it right. Your users’ basic need for security is at stake, and that can feel like a lot to bear, but it’s totally doable if you take the time to properly analyse your project. 

Learn to listen to how your users describe the places they go in your product, the words they use are key to helping you be an effective cartographer and guide. Avoid simplifying language and labels in the name of elegance or wittiness; when it comes to enterprise software, clarity is key. 

Focus on picking the most useful approach for the job. For example, when dealing with a hypercomplex system, you shouldn’t just offer a map for reference, but also tools to get to popular places easily. 

The only way to get all this right is by having a solid understanding of how your users think. There’s no way around it, but getting to know your users the best part of design anyway, so you should be alright!

How does this fit in with the development workflow?

If you’ve been struggling to implement complex features, (like filtering) that your users find intuitive to use, we have put together a course (UX Skills for Developers) that will help improve your implementation and overall usability.

🧠 Want more enterprise-focused UX guidance?

You’ll probably enjoy our pattern analysis on enterprise data tables.

Sign up to stay in the loop

Receive an email when we publish a new article on design.

“Finally some filter content that's not about e-commerce!”

Enterprise filtering enthusiastB2B software consultant