Looker Totals

a screen explaining what database aggregates are upon hover

my role

Designer

my team

Sarah Waterson, lead designer

Year

March 2021 - June 2021

In Looker, we offer an option to display totals, a number at the bottom of the data table that reflects a total of the underlying data and not necessarily the data visible in the table. By calculating database totals, Looker leverages aggregations beyond the row limit and also avoids issues where data may be double-counted in a table calculation, depending on how the table is organized. However, customers face an issue in interpreting whether Totals are “correct.” Many times, users are actually looking for a summary of the data in the table instead of the database Totals. This confusion leads to one of Looker’s top feature requests.

the problem

an image of why looker totals is problematic when the row limit is reached

When the user select `Totals` and hits the row limit, they can get confused as to why the number in the bottom doesn't match the sum of the values in the column.

‍

In addition, Looker avoids issues of double-counting totals, but this can also confuse users.

an image of why Looker Totals is confusing when Looker avoids double counting

iterations

After doing some sketches of possible layouts, we decided on a standard dropdown menu, which will allow the user to seamlessly choose a summary statistic or an aggregation for their analysis.

‍

One of the main reasons why users become so frustrated with this totals problem is because they often have an assumption of "Totals" that do not reflect what the functionality actually does. When they discover that the values in the column don't add up, they are surprised and angry.

"this is causing problem with my trust of the tool" - a user

We knew that we had to come up with better language for totals, and chose "simple totals" and "unique totals" as a first pass at the design. We also added a way for users to easily manipulate the type of summary stat and aggregation used.

an image of our first iteration of Looker Totals

From our internal feedback session, we had three main discoveries:

Finding the right word is tricky. The language of "Unique totals"/ "Simple totals" were not comprehensive enough.
Some functionality made more sense than others (changing the aggregation types for simple totals vs unique totals)
People liked the idea of showing two types of totals side by side - even the possibility of adding more rows

‍

In our next iteration, we focused a lot on the language to make sure that users know exactly what they were getting when they clicked on "Totals".

an image of our prototype, where users can select between result statistics and database aggregates and they can collapse the description to learn more on the differences between the two

Making sure our users really understood the differences between the two by supplying a description and link to documentation

an image of our prototype where users can add or remove multiple statistic rows

Allowing our users to create summary statistic rows so that they can easily grab valuable insights from their data

an image of our prototype that warns the user when row limits are reached and how many rows are showing, as well as a notification on how many rows are getting calculated

Providing notifications whenever users can potentially get confused by the discrepancy between the different types of Totals

testing

We conducted a study with 6 external users who frequently used Looker. There were a lot of delighted remarks for showing multiple summary stats at once and people also appreciated the tooltips and warnings. However, people found the words we used to describe the two different types of "totals" - results statistic and database aggregates - too confusing.

To me, the only value of it being called "database aggregates" is they would never understand what it is and maybe never use it.”

on pause

This project was temporarily put on pause as priorities on projects have shifted. The next steps of this project will be to perform another research to finalize the language and identify other areas of the product that will be impacted because of this new functionality.