On conceptual models
Making sure a user can find the feature he’s looking for is essential for the success of a software application. However, simply stashing links to all features in your main menu won’t cut the cake - there is way to much information for the user. Today, I’ll share an example from the Uptrends app.
The main menu of the Uptrends product is a bit busy. It looks like it has grown out of its bounds since its conception. To me, it looks like the menu started out as 4 or 5 headings with 4 or 5 options each, where each submenu could have a CTA-button. The years took their toll, features were added, and now submenus such as this exist:
Example 1. What’s going on here: one main menu dropdown has six (six!) sub-headers, with 2 to 5 options each. Also, 4 CTA-buttons.
In software land, most people know giving a user too many options will make it difficult for them to find what they’re looking for. Theories around this are based on the Magical Number Seven, but those are debunked: the original research didn’t focus on users reading menu options. Still, not providing users with an overload of options remains a fine idea: it reduces information overload and therefore enables users to understand the application better.
There’s a reason people like dictionaries so much: they know exactly where to go to get the information they’re looking for. An application should be like this.
The solution visualized in the first example seems to adhere to good UX principles by splitting the options in 7 main menu options. This doesn’t solve the problem (okay, it helps a little), but it moves the problem one level lower: instead of a busy main menu there are busy submenus.
I think some UX principles got skewed in their application. In this case, I feel that the ability for users to reach all other parts of the application in just one click was deemed more important than the ability for users to understand the applications' navigational structure. Now I don’t think this was a conscious choice. Again: there isn’t much UX knowledge available in the organization, so the developers are not to blame. I think the developers were biased: their mental model of the application matched the real application exactly, because they built the application according to their mental model.
The solution to this problem, I think, is to focus on the user’s conceptual model of the application. Not every feature has to be a single mouse click away, as long as the user knows where to find it. The user has to be able to understand the application - to grasp the conceptual model behind the application structure - to know where to find features.
There are a couple of routes to take to implement this solution, but they all end up in the same category: separating and moving submenu options. Just a few examples off the top of my head, not hindered by any actual usage metrics:
The Uptrends app can be divided in a section for configuration and a section for monitoring. Why not allow the user to switch to one of those contexts and provide a suitable main menu to go along with it? This effectively creates an admin section (for configuring) and an end users section (for monitoring).
Some features can be grouped on an overview page, adding an extra navigation layer. For example, the account submenu now lists both “users” and “user groups” as options. Also, two CTAs are available for creating a new user and creating a new user group. Maybe an overview page where the users are listed per group would help. This page could also contain both CTAs and a link to the Audit log. This solution would result in an extra click for some actions / features, yes, but would provide the users with less submenu options and (more importantly) an application model that is easier to grasp.
Now I don’t say changing is easy. I’m not even sure the above mentioned solutions will ever get implemented in the Uptrends application. But I think that having a conversation about focusing on the user’s conceptual model helps creating UX awareness in the organization.