Sharing & Reporting UX for Grafana Labs

Overview

Organization/Client: Grafana Labs
Grafana Labs provides open-source software for monitoring and observability, enabling users to query, visualize, alert on, and understand their metrics no matter where they are stored. They offer tools like Grafana for dashboards, Loki for logging, and Tempo for tracing, which are integrated into a comprehensive observability stack.

Project Timeline: 6 weeks

Role(s): UX Lead, UX Manager

Summary:
Looking to optimize sharing reports. Current workflow can become disjointed or difficult to navigate. Users report frustration in executing the task efficiently and often get lost navigationally along the way or after completion.

Problem Statement:

User Story:
As a grafana user I want to share a panel or dashboard’s information via an email to stakeholders so they can quickly understand our data and information at regular intervals.

Problem:
I am struggling to quickly produce and edit reports. I’m trying to ensure what I send is accurate and up to date but find the process of creation and editing to be cumbersome and difficult to navigate because the interface is jumbled together in a way that lacks clarity and the process sometimes lands me on a page I didn’t expect. This makes me feel like Grafana doesn’t take this functionality seriously.

How might we:
How might we improve clarity and increase speed of completion for our users sending and updating reports so they can trust our product is able to give accurate up to date data to their clients and stakeholders.

Strategy & Approach

Discovery Phase:

User interviews

• Pulling from VoC and support tickets we were able to uncover some key issues and frustrations for the user when they attempt to create and manage their reports
• Using these issues as a guiding force we conducted interviews with internal users to walk us through the full flows from multiple angles and with multiple outputs to ensure we understood the product workflow from all angles.

Solution Vision:

3 key problem areas.

• Users are dropped in the wrong place if they back out of the workflow
• Many of the details present feel redundant or unnecessary to our users
• Preview, which is quite hidden and cumbersome, is a primary desire of our users.

Design Principles:

• Aesthetic-Usability Effect — when an interface is poor in appearance it is often seen as a reflection of the quality of the entire product.
• Hick’s Law — the more choices available for the user at one time, the slower the process will take.
• Jakob’s Law — users spend most of their time on other sites so they expect your site to behave similar to what they’re used to.
• Peak End Rule — users are impacted mostly by their first exposure and their final experience with a tool.

Process & Execution

Initial Concepts:

One theory for a solution was to create a unique “creation workflow” separate from the edit workflow. This creation workflow would break the different fields and options into distinct steps to reduce cognitive load for the user.

Using a drawer with accordions was one way to “chunk up” information to reduce cognitive load.

The default implementation used in other workflows is to integrate the stepped flow into a page.

There was no standard for where to display the stepper.

Initial designs quickly got into the nitty gritty of the interface. The designer zoomed in immediately on key usability strategies for navigation, progress indication, confirmations, and progressively disclosure. High experimentation in the details led to a wide variety of possibilities in the interface but lacked experimentation in the usability and core content being delivered to users.

Ideas explored:

• Top nav vs. Side nav
• Top buttons vs. Bottom buttons
• Fixed or pinned buttons for ease of progress
• Collapsible accordions for selective and progressive disclosure
• Structural systems like panels, slide outs, drawers, dialogs, and pages.

Then a key engineering stakeholder asked a simple question:

“Do you really need steps at all?”

Exploration of a single page view of the creation flow.

But how do we avoid issues with Hick’s Law?

You don’t need to hide choices in steps, especially choices that most people don’t desire to change. These can exist behind dialogs or sub pages within the navigation, not unlike Google’s settings.

Google’s settings allow for drilldowns into certain settings parameters using a simple back button to return to the previous page.

By placing our less commonly utilized functions behind a click and autofilling functions that we already know enough about, we are able to reduce the cognitive load and number of clicks simultaneously.

In addition, the lack of steps would allow us to do one single implementation for onboarding and post-creation editing. This reduces engineering work and upkeep and also simplifies the process for the user so they don’t have to learn two different ways of working with the interface to accomplish the same outcome

Design System Contribution:

• Moving away from the “stepper” freed us up from having to make a design system contribution. This reduced the engineering overhead for our project. All other components in this project were pulled directly from Saga and required no additional work.
• While differentiation may seem important for certain releases, the implicit ask from customers was a more consistent and coherent experience. This makes adoption of pre-existing design components the logical and efficient choice.

UX Research:

• We ran a three way split test in user interviews, asking users to navigate the current version and clickable prototypes of the stepper version of the product and the single page version.
• Feedback was clear that a single page was optimal. Many users commented on the large preview being a source for the positive feedback.
• When asked about the multiple steps one user mentioned “editing it later will be easier with less steps because I’ll see everything at once”. This bolstered our strategy of unifying the onboarding workflow and the post creation edit flow into one standard.

Collaboration:

• Primary feedback internally came from our internal users via dogfooding while much of our early problem definitions came from VoC. These groups are integral to the early stage processes of any project
• When approaching the work in the discovery and iteration phase the primary colleague collaborating with the project was the engineering manager and product manager who provided push back and insights.
• Connecting with our design system colleagues was also important in the early phases to define the potential and limitations of the stepper component.

Outcome & Impact

• Qualitative Feedback: Users reported a strong positive usability sentiment in post release interviews. Reporting that the new workflow was faster, clearer, and less cumbersome.
• Metrics: Report completion rate went up by 23% and speed of completion was cut in half. Users were generating reports faster, more frequently, with less errors.

Learnings & Retrospective

Key Learnings:

• Don’t stop at your first idea. Remember to explore your options, free yourself from assumptions, and open up your strategy to new ideas.
• Utilize design system to accelerate production. Engineers are happy to lean on pre-existing front end code. This means less front-end oriented engineers are able to move quicker and we can better resource the project to get it out the door faster.

Future Opportunities:

• The drawer dynamic of this workflow greatly improved user context and navigation. Using these types of drawers in the future, for other workflows, may do the same.