Every BrightGauge Dashboard is just a collection of individual Gauges. Gauges are a quick way of visualizing information of any kind.
We needed to add an item that clients have been waiting for over 18 months - Calculated Metrics, but this requires a complete revisit of the Builder interface. The Gauge Builder is also pretty similar to the very first iteration that the company started with, so there's a significant level of design debt to clean up as well.
We used 2 methods for gathering research: Talking with our support team that builds gauges for clients and 30-minute conference calls with 3 power-users.
The support team interfaces with clients and the Gauge Builder in 3 main capacities. Building out gauges the client identified during their Onboarding call, fixing gauges that are already built but have broken, and creating new gauges for clients that don't know how to use the Gauge Builder.
Our biggest finding is that close to 1/3 of the support team's time was spent dealing with broken or new gauges, so any increase in clients building their own directly helps with the support workload.
Our design ethos at BrightGauge is to make things simpler and easier, while not alienating all of our biggest fans. We had calls with 2 power users and 1 user that has everything built for them to get their feedback after our wireframing phase to talk through some of the changes we planed to make.
The feedback calls were a great reminder about how powerful the tools are deep in the app and as long as these power users can still access them, relearning where the feature is was not a huge concern. The simple user knew how to do a few basic things in the gauge builder and pleaded for us to not completely change those items and make him relearn.
At the end of the day, we were able to validate the majority of design decisions and make a few tweaks to others to balance the concerns of the different users.
Since power-users have already learned how to use the complex gauge builder, we didn't want to change the overall mechanics.
We also wanted to make the Gauge Builder more friendly, as most users called our support staff to have them build gauges for the client. Making the Gauge Builder more human-friendly while retaining power-features is a delicate dance.
For users to create Calculated Metrics, we needed to add the concept of many 'Layers' where each layer is comprised of a dimension from a dataset.
With users able to add lots of layers now, we needed to make it easier to manage. Before, layers were just auto-named "Layer1", "Layer2", etc. Now users can change the layer name to whatever they want.
We leveraged the same contextual menu trigger visual style that had just gone live with the Dashboard update to add a new Calculated Metric layer. Just clicking the "+" gives you a popover with labels and icons to make the item easier to scan for.
Giving users power to make many gauges means we need to smartly handle the overflow. I love the way both Sublime Text, Photoshop, and Google Chrome handle document or page overflow, so instead of reinventing the wheel we took the best interactions from each and combined them to handle overflow.
Instead of a scary popup with 'dev text', we give the user a way to take action by showing them which datasets are having an error and with a big button to click for visiting the dataset page. From the dataset page, a user can manually sync their data again. Prior to this, users almost always called or emailed support for help.
A big complaint was having to start from scratch when making a new gauge. We added a way to copy the exact configuration of a gauge and then a user can just change one setting or dimension and be done - saving users minutes and confusion.