The most-used aspect of BrightGauge is the Dashboard page. You can build 'dashboards' with your data and easily visualize KPIs, see the status of different things in real-time, and even view calculated metrics taken from multiple datasources (for example: total time spent on support calls this month from Clarity time tracking / the amount of billable hours from Quickbooks = Billed Support Gauge).
Many users manage their entire team using these dashboards and display them on big TV screens in their office. C-level managers use dashboards to keep their finger on the pulse of how different departments are doing at any given time. This is a must-get-right page for BrightGauge, for both customer retention and growth.
The Dashboard started as a very simple tool. As the customer base has grown, the amount of features have as well. Our sprint backlog is full of small functionality that we'd love to add to the page, but don't have anywhere to put it.
1. The dashboard page is running out of space for adding any new functionality. Adding any further buttons means we'd need to remove labels or make space in some way.
2. The dashboard needs to introduce additional gauge-level functionality, yet remain visually easy to scan when not interacting with an individual gauge.
We conducted research through 3 main channels.
1. First, we gathered research from our bug reports in Intercom to see where the biggest self-reported pain points were in the app. There's no better feedback than the kind of pain that makes someone fill out a help ticket. The most common issues needed to be addressed in the redesign.
2. Next, we leveraged behavioral analytics (using Inspectlet) to identify common usage patterns. Users can't hide behind just what they say and we can surface the most common use patterns. I spent around 10 hrs watching videos of actual users interacting with the product to draw conclusions.
3. Finally, we held video / audio conferences with 5 of our longest-standing customers. These users range from die-hard power users to satisfied once-a-day or once-a-week logins. This range of viewpoints really rounded out the dataset and filled in gaps that we would have had with other methodologies.
The final approach balances the need to clean up interface clutter with the actual user patterns and goals gathered through interviews.
The thinking here is that the more common a task is to complete, the higher up in the hierarchy it should be. Tasks that are completed all the time should be at the top of menus. Instead of bombarding the user with lots of "mystery meat" icons that they'd have to spend many sessions learning, we instead wanted to reduce the interface's cognitive load.
The old app approach was to show all functionality at once... which means that every bit of browser chrome was being used for buttons. This also means that the dashboards couldn't really be responsive because you'd 'cut off' the labels for the button icons, which were confusing. Moving to 'popover' menus means that there will be a home for new functionality that was coming down the development pipeline, as well as reducing the visual fatigue from constantly looking at 8-10 buttons.
A bigger idea came from the research and design work done for the Dashboard page: contextual menus. This means that actions taken on a dashboard (Rename, Switch Dashboards, Share a link, Add a Gauge, etc) should be in one menu. In the same way, gauge level items (rename gauge label, refresh datasource, delete gauge from the dashboard, etc) should be accessible in a menu triggered on the individual gauge. This seems simple, but the added hierarchy was a completely new concept for the app that ended up trickling down to other areas.
The dashboard-level menu for the Dashboard page houses a lot of new functionality, including the Switch and Create functionality.
Filter and TV Mode UI elements have all been collapsed to single menu triggers for their respective categories.
The gauge-level menu trigger appears on hover of a gauge, so that focus can be on the actual data instead of the UI layer.
There when you need it, transparent when you don't.
The Dashboard redesign also included a reworking of how to view the dashboards created by a user. Instead of only being able to toggle 'TV Mode', the users can now present a dashboard, or group of dashboards, by creating a 'playlist'.
Once users hit 'Present in TV Mode', these critical numbers are displayed in rotation... at user-configurable intervals. This is the #1 highest requested feature and was finally able to be delivered after more than a year thanks to the Dashboard restructuring.
Most users have 20-30 dashboards. Instead of going to a page with a list of all their dashboards every time they want to switch, users can now pull up a modal with their list dashboards and filter for the specific one they want. Making this simpler is the concept of 'favorites' that's stored on a user-level, so you never forget what that important dashboard is named.