Binning 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-serve and extract insights about their company data quickly and confidently.

Looker allows users to create custom bins in the UI that do not require complex nested IF statements. However, users struggled with this interface. How might we redesign how business analysts think about binning?

Role
UX Designer
Team
Sarah Waterson (lead designer),
Katherine Gillespie (PM)
Duration
Nov 2021 - Feb 2022

Background

Before diving deep into this project, what exactly is binning? Binning is a method for business analysts to analyze the frequency of quantitive data, bucketed into smaller categories. For instance, if we have data about a group of people, we might want to bucket their age into smaller age intervals.

In Looker, we offer two ways of manually creating these bins. One is via LookML and the other is through the Explore interface. LookML is a modeling language for developers - we won't be focusing on that. Instead, we'll be looking at the Explore interface, used by a majority of non-technical business analysts.

The current interface for binning has certain usability and comprehension issues that needed to be addressed.

I was brought into this project as a UX designer to work on how we might rethink binning in Looker. What is the ideal happy path?

Based on user feedback and their pain points, our new binning functionality should account for...

Expectation. Users should know how their data is being binned e.g. how many bins will be returned?
Customization. Users want the ability to rename their labels.
Usability issues. e.g. We should avoid giving users a text editor option where they could input in anything they want.

Flow and Frames

We proposed a simple user flow for binning, where Looker generates an optimal number of bins (by using a common formula used by Google Sheets and Excel) for the analyst.

I turned this user flow into some wireframes and presented to the team for feedback, doing multiple rounds of revision before going into hi-fidelity mock ups.

The First Challenge

When I began creating the hi-fidelity mockups, I started to detail with precision the steps that a user may typically take when they edit the bins and I realized there were a few tricky issues.

The issue

When Looker generates an optimal number of bins for the analyst, conflict may arise if the user wants to change the start (min) or the end (max) value. For instance, let's say we have values 0 through 50 and we assume that Looker thinks that the optimal number of bins is 5. The bin size will be 10 (e.g. 0-10, 10-20, 20-30, etc.). However, the analyst wants the min to start at 5 instead. What should the ideal path be? We could allow the analyst to change the bin in the modal, but allowing the analyst to change the bin within the interface would clash with the number of bins or bin size (the width of the bin). This was a rabbit hole which we did not want to enter.

‍

We wanted to make the design as simplistic as possible while being thoughtful about an analyst's needs when binning, and began to remove functionalities we didn't need.

The Second Challenge

A second challenge unexpectedly came up when I found out there were plans to change the design of the Explore interface such that modals were no longer encouraged. Instead, previous functionalities using the modal (like binning) will be relocated to a sidebar of roughly 325px x 700px, which didn't fit my initial design sizes at all. This unexpected challenge required a few more revisions.

We also began thinking about the different paths that a user may also face, such as encountering really long numbers or error states.

The Prototype

Our new binning functionality should show analysts exactly how their data is binned and offer them the ability to customize those bins. It should be simple and avoid opportunities for user error. We also included interactions with applying and viewing the bins to the query using the new sidebar functionality.

Note: the gifs are laggy because I no longer have the original prototypes - only copies.
‍

Research

Finishing the prototype, I conducted 5 moderated usability studies with Looker users to evaluate the proposed new experience for creating bins on the Explore page. Our research objectives:
‍

Do users understand the basic interactions for defining bins? (adding/removing bins, auto-size)
Do users understand how to apply and view the bins to the query? Do they understand the interactions for previewing?
Are there any general interaction problems or concerns?

I gathered my observations into a spreadsheet and presented my recommendations to the team.

Evaluation

Ultimately, our analysts had a really good sense of the interactions of creating bins with the new interface.

Learnability

Users understood the basics with defining the bins, though many of them initially thought that hovering over the plus and minus icons will increment and decrement the bin range by 1 respectively. We could include tooltips to the icons as guides. The sidebar interactions and custom labels were straightforward.

Visibility

Users wanted to learn more about the algorithm of creating optimal bins. We should surface information about the bins for the users - such as the bin size, number of bins, and the min/max values that Looker is using. The information is all there in the sidebar, but not obvious and require some brain power from users.

Efficiency

There were concerns with performance and query costs. Some users shared it'll be useful to get an understanding of how long binning would take and the associated query costs. As a next step, we should get engineer perspective on the backend performance.