Helping customers spend less

How we optimized customer database costs with data visualization

 

Table of Contents

  1. Understanding the problem

  2. Digging into the data

  3. Customer research

  4. Building a solution

  5. Going to market

  6. From feature to solution

 
 

  1. Understanding the problem

Our company knew that we needed to make it easier for customers to manage the overall cost of data ingestion and storage - this was a clear ask from our go-to-market team as it would bring us to feature parity with our competitors and ultimately help us close more deals.

 
 

About the company and the product

Grafana is a popular data visualization tool that is used by millions of customers daily. It was launched 10 years ago as an open source software (OSS) project and has grown to a 1000+ person company with both OSS and paid solutions. Grafana’s primary users are in the DevOps space and the tool is used for Observability - monitoring the behavior of backend and frontend systems.

Grafana is one of the world’s most popular observability platforms - it serves millions of users daily, allowing them to unify [their] data, wherever it lives.

What we wanted to understand

As a product team we wanted to understand

  1. How our enterprise customers approached managing cost, especially when DevOps teams were managing an observability platform for hundreds and even thousands of engineers.

  2. What types of workflows our customers used when making decisions around cost savings and also what types of data they needed to see at what points in the journey.

Team

The team for this project was:

  1. A senior UX designer (me!)

  2. A senior Product manager

  3. 2 senior Engineers (who primarily served as subject matter experts)

  4. 1 senior Front-end engineer

 
 

2. Digging into the data

This project required a strong understanding of complex data sets. So my first step was spend time learning about the data and our customer use cases.

 
 

Learning about high cardinality metrics

When I first started this project, I didn’t know much about high cardinality metrics and, truth be told, I had a bit of difficulty understanding the concept at first. One of the great things about working at Grafana is that you have access to colleagues who truly want to help -so I set up casual interviews with 5 internal engineers to better understand the data and the use cases.

I learned so much about high cardinality metrics that I became an SME in the subject and even wrote a blog post about it with one of our sales engineers

Using internal experts to learn about a new subject matter is essential for designers who build products for technical users. Having a clear understanding of the data and use cases is an absolute must - so even if it takes a bit of extra time for designers to learn about a new technical area, it pays back in dividends for designers to spend time learning about a new technical subject matter before they dive into a project (and now that I’m a manager I make sure that my direct reports do just this when they start working on a new area of the product).

Understanding the competitive landscape

This is not the first time our team had heard about this problem - high cardinality metrics are a common problem in observability and one for which many of our competitors (like Chronosphere and Datadog) also offer solutions.

At Grafana, we did have an open-source CLI tool to address this problem, but this tool is complex and difficult to use - we knew that we needed to build a more out-of-the-box opinionated solution in order to drive real value for our customers.

 
 

3. Customer research

Even though we had a clear idea of what to build, we sought early customer feedback to test and validate our assumptions.

 
 

Review research repository

The Product Manager and I spent about two weeks delving into our internal data repositories—Product Board, Dovetail, and Zendesk—to unearth valuable insights about cardinality and cost management that our internal teams had already collected. We discovered a wealth of data and also gathered some valuable input from casual chats with engineering and sales. With all this information in hand, we created a set of "messy" mockups and to share with our customers.

These are two of the many explorations I designed to explore our early ideas with internal engineering teams.

We shared the mockups with 5 users, comprising both internal and external stakeholders. At this point, we felt very confident about addressing the right problem, yet we sought a deeper understanding of what data would be most beneficial to users at different points in their user journey.

This is the final version of the wireframes that we shared with customers.

I took the lead in designing the rough mockups, collaborating closely with the Product Manager and the engineering team. Engaging with the engineering teams at the project's outset was crucial as they possess the subject matter expertise and insights into the data types that should be exposed to users.

 
 

4. Building a solution

With insights at hand, we were ready to use them to create a solution that genuinely solves our customers' problems.

 
 

Narrowing our scope

After conducting our initial customer research, the product manager and I had to make tough decisions about what to include in our version 1 release. We had discovered so many interesting insights that could lead to a great product experience - but we had to be smart about our initial scope given time constraints and the technical feasibility of some potential features.

We narrowed down our scope based on two main themes that emerged from our initial research:

  • We needed to ensure that customers were able to easily decode specific types of data at distinct points in the journey, and

  • We also needed to approach the problem with a “learning and development” or “training” mindset - as something many of our customers brought up is that central DevOps teams didn’t always have the ability to offer the training that other development teams may need to properly send data to the databases.

 

These are the final dashboard designs I created in Figma - we didn’t have Figma design system components for data visualizations so I had to build many of these from scratch.

 

Once we established the scope, I worked closely with a front-end engineer to build out a set of dashboards that were designed with the two themes above in mind. We had a clear idea of when to expose the user to which types of data and we also knew that we needed to ensure that the data was visualized in a clear and concise way (we are Grafana afterall).

 
 

5. Going to market

This feature received a lot of attention and excitement from our sales team when we introduced it to the market, and it has been incredibly valuable in helping us secure and renew deals ever since.

 
 

The final product

We ultimately released a set of 3 interconnected dashboards, and the team made some small adjustments as we moved from Figma to code.

First, we modified the colors to account for accessibility. We knew that pairing green and red could make it difficult for color-blind people to interpret the visualizations, so we decided to use more accessible colors (in this case, red and blue) in our final designs.

Second, we still needed to incorporate some of the educational content, so the Product Manager and I integrated “tips” and “learnings” into the overall dashboards. This way, DevOps engineers could encourage their organizations’ application developers to use the dashboards as a way to build out their own Observability skills.

 
 

Our go-to-market movements

We released the dashboards to the public with much fan fare! Our sales team was excited to show it to prospects and existing customers and our own internal DevOps teams started using them immediately.

I (again) partnered with a sales engineering to write a blog post introducing the feature, while our sales and marketing teams conducted several webinars on dashboards (something they continue to do today).

The results have been excellent - the dashboards are extremely popular with our customers, who frequently ask us to extend their functionality. And we are doing just that with our newest feature, Adaptive Metrics. While I am no longer the designer on the project, I am still closely involved as I now manage a team of designers that work on our database products. In fact, one of the designers on my team just recently released a new UI for Adaptive Metrics - and that UI was informed by the intial research we did at that start of this very project.