NRX

Some quick feedback about New Relic's NRX prototype.

Left-side vertical navigation.

Left-side navigation.

Left-side navigation.

I've never been so frustrated with a horizontal navigation as I was when we tried to fit a broad category structure into a horizontal navigation bar at New Relic. It was a mix of design legacy and technical constraints, but it made for a confusing user experience.

We used tiny font sizes, and crowded items close together to make the list of categories fit into the limited horizontal space. We also had to create unnaturally short category labels. Worst of all, we had to adapt the IA so that there were only as many main categories as we could fit in the available space. By limiting a broad information space into a small number of categories, we ended up with top-tier items that were too generic, we had to hide them behind buttons, and we made it difficult for users to find what they needed. Also, we had a lot of navigational elements scattered across the screen. Switching to left-side vertical navigation is an excellent solution to solve many of the issues we encountered then. Vertical navigation is easier to scan, offers room for growth, supports customization, and people are familiar with it. It's such a great improvement.

nr-nav-00-1

Some aspects to consider.

Some aspects to consider.

I think we can safely say that the navigation bar is only the beginning.

We've all been there. You're trying to use a new product, and you're just not getting it. You don't know where to go or what to do. You start to doubt your own intelligence as you stare at the screen like a frightened deer in headlights. As if all of this isn't bad enough, now you have to start all over again when you find yourself in a different section of the product.

Starting from your prototype, here are seven suggestions on how we can make navigating New Relic less confusing and make the overall experience better.

1.

1.

The first-level navigation items are structured in such a way that they all appear to be doing the same thing. Even though they're not, we perceive them as such because they're all visually very similar.

The reason that we do this is because if things are close together, we tend to link them as a whole. If they're far apart, we consider them as doing different things even if they are visually the same. If there's not a substantial difference in how elements in the navigation are treated (visual appearance, proximity, etc.), people will perceive them as the same. In this case, they are not.

Also, we could try to teach users how to use keyboard shortcuts in a more explicit way. For example, we could show visual hints of the keys combination next to each element on the interface. We could also extend this to any other element on the interface and let users enable or disable it from settings.

nr-nav-01-1

2.

2.

Second-level navigation should be visually related to first-level navigation, and entity-specific navigation should be visually separated from first-level navigation and closer to the content it refers to.

The purpose of second-level navigation is similar to that of entity-specific navigation: to help users navigate through the site. However, they are different in context. Second-level navigation is meant to help users navigate between sections or pages within a section, whereas entity-specific navigation is meant to help users navigate through the content in that specific section. For example, if you select APM in the main navigation and then an item in the table, the navigation shown after that selection is somehow related to APM but not directly related to it. We could consider it a third-level.

nr-nav-02-1
nr-nav-03-1

3.

3.

If we apply the beforementioned tweaks, there's no need to use such a big space to separate the menu items that are at the bottom of the left-side vertical navigation (invite, user info, etc.). We could also consider adding the menu items at the top right corner to the main navigation. Scattering navigational items across different parts of the screen may result in creating feature blindness for those who are away from the place where users learn to use to navigate. If you think it's too much content for the navigation, consider adding a "more" item that shows the extra elements.

Lastly, I would consider not making menu items appear and disappear. I don't know if it's a matter of the prototype but makes it more difficult to predict the behavior of the navigation and remember what did you do to make that specific item appear. Also, I would avoid using "mystery actions" than only appear when you're hovering over a specific element.

nr-nav-04-1

4.

4.

When navigating through items, you're going to reach a table most of the time. And that's fine—it's still data, and it's still useful. This is especially noticeable in dashboards. Right now, we show a table with names and labels—and it's up to you to remember if the name of a dashboard relates to what you were looking for. Wouldn't it be better if we showed visual representations instead? We should strive for consistency, but also consider when it makes sense to break the rule to show more meaningful information on the screen without the need of navigating further down the line.

nr-nav-08

5.

5.

I've been thinking about your feedback regarding the use of boxes inside boxes. I'm not a huge fan of it either, but some layouts would benefit from better visual differentiation of items you can interact with. For example, in the "add data" and "all capabilities" sections. We may be cluttering the screen with so many shapes, so an alternative could be to space elements better to create the visual aspect of a card without using any shapes. Also, we could use a different state on hover to increase affordance. We could also clarify secondary actions (docs, pin, unpin) using buttons instead of links. I tried to completely get rid of the cards, but the information tends to float over a huge dark space (Gestalt principles apply here). I used a more subtle look for cards, but I'd need some more time to play around with spacings to eventually getting rid of the containers.

nr-nav-07-1

6.

6.

I would try to avoid using vertical and horizontal navigation. We should always stick to vertical navigation instead of combining different models like in Infrastructure. If we aim to create a sense of familiarity with the product, we should not change the navigation model depending on the number of navigation items one specific section may have. Note also some subtle improvements that this change enables. Each vertical content block on the screen is titled based on what that area contains. Reading the headings from left to right creates a natural-looking breadcrumb you can use to know where you are and to quickly navigate through it: New Relic > Infrastructure > Hosts. 

nr-nav-06b
nr-nav-06

7.

7.

Some people think that aligning elements on the screen makes absolutely no difference. But they're wrong, and here's why. When we align elements in a way that creates a sense of order and facilitates scanning through content, it makes the user feel safe and comfortable. When things are out of alignment, and there's no clear "line structure" to follow, it can be disorienting and overwhelming—which is exactly the opposite of what you want your users to feel. Also, it makes it easier to move the mouse horizontally while navigating between first-level and second-level menu items.

nr-nav-05-1

Conclusions.

Conclusions.

We could consider many other aspects, and this review may look slightly shallow. Still, it's worth mentioning that these proposed changes could contribute to making the overall experience easier to predict and repeat. I think some solutions in the prototype still take some time to understand because they look similar and behave differently. Focusing on defining the chrome of the experience at a user interface level could help us deliver an easier-to-understand product experience that could facilitate learning and improve familiarity with the product.

Let me know if there's any specific area you'd like me to look closer to!

email   |   linkedin   |   medium