Enough with the Data Tables

There’s a new restaurant coming to town.

A Big Hit

Everything on the menu will be curated by a well-known chef. It touts fresh, high-quality ingredients and impeccable service. To make it even better, the restaurant claims it will bring your food out nearly as fast as your favorite fast food joint. With these factors in place, you know that this restaurant will be a big hit, so you make a reservation for opening night.

You get there and the excitement builds. Everything on the menu sounds delicious. You go through the list and, after a few minutes of alternating joy and trepidation (since you can only order one of these stellar options), you make your selection. Now you wait for the meal to arrive. As advertised, the food arrives within minutes of your order. The server places everything in front of you…and disappointment washes over your face.

Instead of serving you a well-prepared meal, the server places the individual ingredients for your meal on your table. You shoot the server a questioning look but it’s clear, you are on your own now.

You do your best and follow the provided instructions but you can’t quite get things right. You season your food unevenly. The stove temperature is a bit too high and you cook your chicken a little too long. At the end of the meal you complain. This is not the experience you were hoping for. The chef comes out and says, ‘You have everything you need for a world-class meal. You are the one that messed this up.’

Yes, this is a far-fetched tale. No restaurant would ever do this. You don’t go to a 5-star restaurant to prepare your own meal. So why do product designers do this to their customers all the time? Why do we expect our users to filter, sort, and manipulate their own data to make decisions? We need to rethink how we use data tables.

The Proliferation of Data Tables

Data is important. For many systems, it is the basis for everything we do. People cannot make decisions effectively without it. But as we see from the restaurant example, simply shoving data into a table and making your users do all the work does not make for a well-designed system.

There are four scenarios that address 99% of cases involving data: 1) The user needs to understand the data set (as a whole or in subsets), 2) the user needs to compare parts of the data, 3) the user needs to find interesting data points to explore further, and 4) the user needs to find a specific data point. Having a large data list doesn’t by itself help with any of these.

So why are data tables everywhere? Because they’re easy. It’s easy for a developer to create an API and show that the desired data is coming back — usually in a data table reflecting how the data is structured in the database. Unfortunately, as Alan Cooper points out in “The Inmates are Running the Asylum”, once something is prototyped out to prove effective, it becomes very difficult to throw that away. People see the data is there and the work has been done and the time pressures dictate that this will be all that ever gets designed for the interface. It also happens that since they are so commonly available, users will ask for these and demand that they are on the screen. It’s a never-ending cycle of sub-optimal design.

We as designers should know better. And yet too many products still rely on only data tables to tell their story. We use a lot of excuses to let this pattern proliferate. We tell ourselves that customers may want to tailor the data in unique ways and the table gives them that freedom. We add in filters, so that the user can limit the amount of data to a manageable size. We decide that any other solution will cause performance to be to slow and that we are doing it to provide a good experience with our product.