Hiver Analytics - Dashboard design

Designing an effective dashboard for Hiver's analytics module

Team

2 designers, 1 PM, 4 developers

Company

Role

Hiver

Product Designer

Duration

One month

Overview

Hiver is an email management tool that works inside Gmail and allows team inboxes to streamline their workflow.

Dashboards are a component within Hiver’s analytics. Dashboards allow Supervisors and Admins to quickly gauge the health of their team and stay on top of the key operational metrics for the shared mailbox they are responsible for.

Dashboards are a snapshot of how the system is doing at the current point in time.

Problem Statement

Build a way for admins and supervisors to stay on top of their key performance metrics. The platform must be actionable and easy to consume.

Process

Research

1. Conducting user interviews and gathering data 

This user discovery was done by the product managers and Customer Success team, I analyzed the data gathered. Gathering accurate data was crucial in this project. I collected user requirements and pain points from past data and multiple data points from the interviews and PMs.

2. Users 

From this data gathered, we came up with two primary user personas:

3. Use cases 

These are the broad use cases that I solved for:​​

4. Competitor analysis

How are Hiver's competitors solving this? How are other good analytics tools going about this?

Structure — Information Architecture

  • Hiver Analytics sits in the main navigation of the Hiver extension within Gmail

  • Dashboards sits within the Analytics module of Hiver.

  • Analytics has 2 broad sections — Dashboards and Reports.

  • Further, the user can create custom dashboards and custom reports.

Information architecture of Analytics dashboards (Made with XMind)

Ideation

1. Guiding principles 

Since Analytics is a function-heavy module, we followed a few guiding principles to design all the modules in Analytics.

2. What makes a good dashboard?

Almost every single enterprise product has an analytics module, and consequently, a dashboard. But what makes a useful dashboard? After doing a bit of research, I found these 4 principles of good dashboard design:

  • Provide relevant information in about 10 seconds of scanning through the page.

  • Display information in a logical layout: Current insights → trends → drill down.

  • Have only about 5–9 visualizations at a time: Reduce cognitive load for the user.

  • Use the right data visualization.

  • User should get information about anomalies of the system from the Dashboard

3. Sketch up!

This is where we go crazy with the ideas. You can explore absolutely anything, and that’s where brilliant ideas come from anyway 🤓

Solution

1. Dashboard components

Now that I had answers to questions like — where will data come from? how will the dashboard be actionable? and I also had random, useful ideas from the sketching phase. This led to the next step — what are the core components that’ll make up the dashboard?

As all dashboards are made, our dashboard is also made of widgets. These are card-style components that ensure scalability and easy customization. These are all the various types of widgets I designed:

Design challenges

1. Laying the foundation

The dashboard layout had to be absolutely free and scalable — when a user creates custom dashboards, he starts with a blank canvas, which means we had to design a grid-based layout to accommodate all the different kinds of widgets in a systematic way. 

Solution
To solve this challenge, I experimented with various grid layouts. The 8-column-grid-layout was the most appropriate. 

2. Creating a custom dashboard

This one took a couple of iterations to solve. From where can the user create a custom dashboard? Does it go into a new screen? How does he/she exit out of this? How can I make this flow intuitive?
Solution

I started with a fullscreen layout but the users I tested with didn't find this flow seamless. We also wanted the user to feel that he was building something from scratch and that it was fully customizable. After several experiments, I ended up with a full-screen popup with a grid board that helps the user feel like they’re building something from scratch.

3. Two different approaches for creating a custom dashboard

Hiver's ecosystem is slightly different from a traditional data-analytics system. I had two different approaches for how to go about creating a custom dashboard and tested out these flows with internal users and the product team.  
Solution

Contrary to my belief, most people seemed to find the 2nd flow more intuitive and so we ultimately decided to build that. 

3. Rearranging in Custom Dashboards

This was a tricky one. Can the user re-order widgets in a custom dashboard? If yes, when can he perform this action? What kind of engineering effort will this bring in? Does this action hinder other actions to be taken? Towards the end, I came up with an interaction keeping all these cases in mind.

4. How does the dashboard connect to Views and Reports?

This was the core working of widgets on the dashboard. There were various cases where we had to think about how the data is fetched from Reports or Views, and how do we take the user back to the dashboard where he started from?

Visual Design

The layer where all the magic and delight happens 😬. The Visuals for this module had to be in sync with our newly revamped UI and that of the Reports module.

User Testing

We conducted multiple user tests with internal stakeholders and iterated on the designs. For Ex: The fullscreen feature was an idea that came from one of the users for ease of presentation. The Customer Success team took our prototypes to users and shared feedback that we worked on.

Business and user impact

This feature is currently in development. Stats coming soon!

Takeaways

Analytics was one big story that we worked on. It had many components and details tied together. To nail the UX of all these pieces was not an easy task. A few takeaways from our process:
What could have gone better?

  • I should have generated ideas quicker. Iterated faster.

  • I should have thought about the functional aspects more deeply early on in the process

  • I should keep my Sketch file organized.

What did I do well?

  • Dashboards was strongly connected to the Reports module. I played well with the team.

  • I understood the use cases well before tackling the interactions.

  • I wrote a short, well-structured case study out of it :)

© 2020 Sukanya Basu. Proudly created with Wix.com.