We recently shipped an update to navigating inside Honeycomb. Thus far, results have been positive – thank you! We wanted to give you a behind the scenes look at why and how this work came along.
It’s easy to develop a certain blindness after working with your own code day-in day-out. Staring at something over a long period of time wears down the jagged edges that once used to protrude and now appear as normal. Which is why, when we heard more than a few customers talk about getting lost within Honeycomb, we decided to investigate.
After talking to some folks, it was clear that everyone had a slightly different mind map of the features in the product and more importantly, whether they had a mental model for navigating Honeycomb at all. Among the most telling cases was the fact that some users would rather go to the URL bar on their browser and type in the location they wanted from memory because it was easier than recalling the various clicks to get to where they wanted.
So, we knew we had a problem.
Houston, we have a problem
Actually, we found a number of them. Often, they manifested as users not being able to describe where they were situated within the product. In addition, many users had different ideas of how various parts of the product related to each other. They often wound up expecting a navigation action to do something, only to be surprised by the outcome. This often led to “un-intuitive” navigation, not discovering new features, and more importantly, difficulty in perform some key workflows effectively.
It became increasingly obvious that we had outgrown the structure that had supported the product thus far.
Let’s recap: we know that users come to Honeycomb to perform a variety of tasks. The main one is obviously to run queries investigating an issue in systems that they are shepherding. Some users do that by using queries stored in Boards as jumping off points, others go off a historical point of record, and others simply go straight to the Query Page and bang out a query. Other times, users come to Boards to check up on various queries that indicate system health. They might want to cycle through a few graphs and ensure that things are looking the way they should. Occasionally, the Team Owner will want to rebalance or increase storage across datasets.
Erecting the signposts
In this redesign, the central focus was on making sure that each of the facets of the product are clearly demarcated and labeled so that it is easy to find and go between places. We want our navigation to be simple, explicit, and stable.
We replaced the existing contextual top navigation with a side navigation that has static entry points into different parts of the product. From our statistics, we know that most of our users’ screens are wider than they are tall, so we expect this change will give some precious pixels back to the main focus: graphs and charts.
Next came the items in the navigation bar: We know that running a query is the most important task in Honeycomb, so now the Query Page has its own section and is always a single click away from anywhere else in the UI.
We also separated out datasets into their own section. Clicking through, you see the list of datasets that belong to your Team and some additional information to help you find a specific dataset. It is now also easy to click in and start modifying the various attributes of a dataset itself; adding a description to the schema, or modifying an existing Trigger. With our latest Boards update, this entry point makes it easy to start working with Boards. Saved queries are now no longer more than a couple of clicks away, and you can get to all the different Boards that are created by your teammates quickly from there.
And to round it all up, we also consolidated all the administrative tasks in Honeycomb and made them accessible from the user icon on the bottom left of the page, flanked by a quick link to our documentation – because you know help is always a click away.
Honeycomb’s UI now contains these four main sections, and the sidebar allows us to make space for any future expansion. In each step of the design, we carefully validated the design artifacts with customers, making sure that we are truly solving the problems we identified earlier. Shipping a change that cuts across such a wide swath of the product is always challenging. That said, as we’ve rolled out to our test users and more generally, we’ve been getting great feedback.
As usual, we strive to continuously improve the product, and we’d love to hear about your experience with us.