Totals in 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 that Totals number is “correct.” This is one of Looker's top feature requests.

Role
UX Designer
Team
Sarah Waterson (lead designer)
Duration
Mar 2021 - June 2021

The problem

Why are we focusing on how a number is being displayed? Let's do a deep dive into the Totals functionality and why it is a current 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 do not 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.

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.

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.

Our objectives

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”.

The Design Process

We sketched out a few possible options...

... and created hi-fidelity mockups to send to internal Looker users (essentially people within Looker who were well-versed with the technicalities of the product) as Google Slides for feedback and testing.

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.

Internal Users Feedback

We developed three insights from our internal users session.

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. This was really helpful to know because we initially couldn't think of reasons why analysts would want to add multiple rows.

The Second Prototype

Based on feedback from our internal users as well as our Support team, we made additional design choices to help us achieve our objectives.

Note that in the second prototype, instead of using Unique Totals or Simple Totals, we changed it to Database Aggregates and Result Statistics, respectively. Database aggregates is the equivalent of Looker Totals while Result Statistics are calculations based on the results returned in the data table interface.
‍

Research

With the help of an external UX testing group, we 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.

Key Findings

Results statistics and database aggregates labels were too technical.
Most users had difficulty understanding the initial distinction between Result Statistics and Database Aggregates, but they understood the labels after reading the descriptions. Many believed Result Statistics should be the default choice when selecting Totals because business users will have an easier time grasping that concept.

People loved the idea of showing multiple summary stats.
Users are less likely to use another tool such as Excel to perform custom formulas if they were offered easier options to do multiple calculations within Looker.

People appreciated the tooltips and the descriptive row limit warnings.
The tooltips offer additional explanations, which were helpful for such a complicated concept.

Next steps

The user flow for Totals are pretty much finalized. The plan is to kick off another research initiative to finalize the language before handing off specs to our engineering team.

We could measure the success of the project by working with our Support team and quantifying the number of questions related to Totals. We can also calculate the time on task or the number of clicks required for an analyst to summarize their data and generate a report, and measure the satisfaction or efficiency of a task by CSAT or NPS score

Reflection

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.

Due to a limitation of resources, this project was put on hold temporarily. It should be on the roadmap in 2022.
‍