What's a good way to design a menu in which some menu items are dependent on others?

Question

My company likes to design interfaces with side menus that look like this:

The problem with this design is that it allows the user to click on links like "Profile" before they've selected which profile they want to view. This leads to confusion - new users naturally try and click directly on the "dependent" links (e.g. "Profile") when searching for detailed information in the app.

To solve this, we typically do one of two things:

1. Disable the dependent links (like "Customers → Profile" or "Customers → Orders") until the user has visited the search page ("Customers → Search")
2. Leave the dependent links enabled, but automatically redirect the users to the relevant search screen if they haven't previously selected an entity.

As a side-effect, this design introduces a concept we call "context" - clicking the "Customers → Profile" link brings up the customer currently "in context" (i.e. most recently selected from the search screen). While this behavior can be handy at times, it can also lead to some confusion and some tricky edge cases.

How can I redesign this application flow to avoid the issues described above? I'm open to all ideas, even if they don't directly involve the menu structure.

Answer 1

1) Horizontal sub-navigation

One solution may be to separate those items which require more context (like the prior selection of a customer or supplier), into a seperate level of navigation. One representation being a horizontal sub-navigation.

This would allow you to have some tabs in the sub-navigation depend on selecting a customer (like 'Profile' and 'Orders'), and others (like 'Complaints') not, through the inclusion or omission of the 'Viewing customer...' element beneath.

To the problem of what happens when you first click on 'Customers', and the 'Profile' page is displayed, you wouldn't be able to display content (because no customer has yet been selected) - you would need to instruct them to do so...

Now, the down side to this approach is:

• You always land on one particular page that you might not first want (e.g Customers > Profile).

• Depending on how your app loads, it's a bit more cumbersome to get to the sub pages (e.g you'd have to wait for a load of some kind to see the next level of navigation).

How severe these down sides are depend on your application and how your user's use it.

2) Sub-group in existing navigation

Another approach may be to group anything that requires further context into a sub-group in the existing navigation.

With the initial state, I would think it would be quite clear what was happening if you disabled 'Profile' and 'Orders' until a search was performed.

Answer 2

My suggestion is to avoid having these context-dependent items in the menu in the first place. The items are especially confusing because they lead to different places depending on who was selected last in your search.

What should the navigation look like, then? You can take inspiration from a number of sources.

Amazon, Google Play, Etsy, Gmail, and others all keep the navigation non-contextual and rely on the browser's back button to let the user get back to his search. They all feature non-contextual navigation that lets the user jump to category overviews anytime.

Some websites, like eBay, go further and include a "Back to search page" button. This is quite similar to how back buttons work within mobile apps.

Breadcrumbs may also serve as a navigation aid.

So my suggestions for you are:

• Remove non-contextual items from the navigation menu. In your case, that seems to leave you with a simpler single-level hierarchy: Customers, Suppliers, Products, and Locations.
• If you know that people need to jump between recent items of different kinds a lot, create a Recent page with a list of recently visited items. Or, if even faster access is required, include a "Recents" section in your sidebar.
• Conduct user testing with your target audience to see if there are any problems with this new navigation.