Context

What is Looker?

Looker is a modern BI platform that helps users explore, analyze, and share their business metrics easily. Users should be allowed to self-service and extract insights about their company data quickly and confidently.

In Looker, we offer an option to display Totals, a number at the bottom of a data table that reflects a total of the underlying data. Customers face an issue in interpreting whether Totals number is “correct.” This is one of Looker's top feature requests.

Context

A deep dive into the Totals functionality

Why are we focusing on how a number is being displayed? Let's do a deep dive into the Totals functionality and why it's a problem.

When Looker displays Totals, the number reflects a total of the underlying data and not necessarily the data visible in the data table. In the example below, we see the superpower.

We see that the data is currently being filtered by Orders ID 9. We have the dimensions Orders ID and Order Items ID selected, along with the measures Orders Count and Order Items Count. Under the measure Orders Count, we expect to see a Total value of 1 because there is only 1 type of Order - Orders ID 9.

Business analysts don't have to worry about double counting their data due to fanout because Looker knows the relationships between the tables underlying the query.

Nevertheless, there are moments of confusion.

Problems

Row limit & Different aggregation used

Problem #1: Row limit

• In certain cases involving the row limit, there are moments when the Total isn't adding up to what they expect to see. In the example below, we see that there is a row limit of 10. Looker shows only 10 rows, but the Looker Total is still aggregating the entire dataset and returning the total count of order items. This is expected behavior.

Problem #2: Different aggregation used

• For other cases, analysts will expect to get a sum of the column because of the word "total". However, Looker Totals takes the aggregation used to define the column. Without getting too deep into the weeds in the below example, the Order Items Max of Sale Price column is using a MAX aggregation type so Looker Total is displaying the MAX aggregation.

so what?

Why it matters

Users are surprised, frustrated, and confused when they realize these problems because they often already have a preconceived notion of what "Totals" should be. I've selected some direct quotes from users to paint a better picture of their sentiments.

User Stories

Through competitive analysis and qualitative research based on user requests, we created these user stories to stay user focused as we started to rethink Looker Totals.

• Keep Looker Totals
  As an investigator/ analyst, I can continue to display totals in my data table that smartly aggregate against the entire underlying data set so that I can leverage aggregations beyond the row limit while avoiding double counting.
• Allow for “result totals” to also be displayed
  As an investigator/ analyst, I have the option of alternatively displaying a summary for just the results in my data table without creating a custom field so that I can get an understanding of the returned results.
• Allow for “result totals” to be displayed without creating custom formulas
  As an investigator/ analyst, I can use different result-level calculations to summarize my data (SUM, AVERAGE, etc.) so that I can get a specific understanding of my results.
• Educate people on the various ways of calculating summary stats
  As an investigator/ analyst, I can understand the different types of summary stats offered so that I can make informed decisions on when to use Looker totals vs “result totals”.

Sketching and prototyping

By sketching, we discovered that adding a summary dropdown was the most non-intrusive method to integrate New Totals. It allowed us to meet user needs without overwhelming the already complicated interface or competing with existing table elements.  

Testing & Iterating

We created hi-fidelity mockups to send to internal Looker users.

In our mockups, we created a summary modal where users could select between "Unique Totals" or "Simple Totals". "Unique Totals" were equivalent to Looker Totals, and "Simple Totals" was the new functionality we added where analysts could create calculations based on the results instead of underlying dataset. We also incorporated an editable summary table where users could easily manipulate the type of calculation used.

Our internal usability tests helped us validate and rework our design choices.

• Unique Totals and Simple Totals labels weren't comprehensive enough.
  ‍People thought that our new labels - Unique Totals and Simple Totals - were not good word choices because they didn't really explain the functionality behind the design.
• Users really liked the ability to add or remove a row, and even suggested an option to include more.
• Clarify the row limit warning.

With the help of an external UX testing group, we then conducted 6 1:1 remote interviews with external Looker users for 30 minutes. These were moderated usability studies where we guide them through an interactive prototype.

Results

Develop a clear, scalable experience that gives our users confidence they’re addressing the most critical issues in their system

• Increased user understanding of what total represents and how they are calculated - thanks to clearer labels
• There was positive feedback from both internal and external users, which was important since Looker Totals is so integral to our product
• The new design also set the foundation for future enhancements, like multiple summary statistics

Some learnings

Should we have conducted an internal usability test?

• We conducted an internal usability test with our extremely technical Looker users. This led to us re-wording Unique Totals and Simple Totals to Result Statistics and Database Aggregates. We later discovered that the new labels were way too technical for our external Looker users. I'm curious as to whether our external Looker participants would've preferred Unique/ Simple Totals.

Adding friction into a product

• This project was interesting because it highlighted experiences where designers should introduce friction into the product. Many products are created with the intention of reducing as much as friction as possible, but as designers, we need to be thoughtful in that decision because friction might not necessarily be bad.