Refining Data Tables

Communication Design

Musings from the merger of medium and message

A column by Luke Wroblewski
August 28, 2006

Many articles have been written on what is probably the single most ubiquitous interface element within Web applications today: the form. Forms justifiably get a lot of attention because their design is critical to successfully gathering input from users. Registration forms are the gatekeepers to community membership. Checkout forms are how eCommerce vendors close deals. But what goes in must eventually come out, and the information users provide to Web applications often makes its way back to users in the form of tabular data.

After forms, data tables are likely the next most ubiquitous interface element designers create when constructing Web applications. Users often need to add, edit, delete, search for, and browse through lists of people, places, or things within Web applications. As a result, the design of tables plays a crucial role in such an application’s overall usefulness and usability. But just like the design of forms, there’s more than one way to design tabular data.

In a previous Communication Design column, “So the Necessary May Speak,” I discussed how to reduce the number of both visual design and content elements within a table to the absolute minimum necessary for effective communication. So, I won’t repeat myself here. Instead, I’ll focus on interface design solutions that enable users to find their way through large data sets.

Sponsor Advertisement
Continue Reading…

Maximum Exposure

When tables are chock full of information, it’s quite likely that people will need to filter out information that isn’t relevant to their queries. In such cases, exposing a complete list of data filters is an effective way of quickly communicating what refinement options are available.

Figure 1 shows data filters in use on In this example, a complete list of available filters is always present above each set of product search results. Filter categories group the filters—for example, price, brand, size, category, etcetera—and help users get an immediate sense of how much data will be left after refining the search results by a specific attribute. With an above-the-grid design, vertical space is at a premium, because you don’t want to obscure the actual data in the table. As a result, the display of filters in each category is often truncated after a predetermined number of items, with a link to see the remaining options.

Figure 1—Data filters above a table
Data filters above a table

Alternatively, you can place a complete list of data filters to the right or left of tabular data, as shown in Figure 2. Though this design provides more vertical screen real estate for each category of filters, some filters may be less visible, because they appear further down the page.

Figure 2—Data filters to the left of tabular data
Data filters to the left of tabular data

In cases where a limited number of filters is available or frequently used, presenting just a few filters might do the trick. As shown in Figure 3, a simple set of tabs, links, or drop-down menus can provide a few high-priority ways of quickly slicing through a large set of data.

Figure 3—Selecting options to refine tabular data
Selecting options to refine tabular data

Consistent Availability

When there are too many possible filters to expose them all at once or refining a data set is a secondary use case—for example, the purpose of a tabular grid may be to get an overview of all the data rather than find a specific value or set of values—keeping data filtering options accessible, but not constantly visible may be a better solution.

For example, a user might expand a collapsed group of filters by clicking a link labeled something like Search Options, thereby displaying the filters only when the user needs them to refine the search results. In the example shown in Figure 4, a set of filters dynamically appears overlaying the top of a table when a user clicks Search Options. By default, the three most popular queries determined the first three filtering options that appeared. However, users had the option of choosing a different set of filters or adding more filters before executing a search.

Figure 4—Filters that require a user action to become available
Filters that require a user action to become available

Occasionally, the best way to find what you’re looking for in a table is to search for a specific attribute value. In such a case, you can provide a means of specifying a query for each attribute by adding input controls to every column in the data grid, as shown in Figure 5. Of course, this design presents problems when column labels and values consist of small amounts of text or numbers, because the addition of input fields can dramatically increase the overall width of a table.

Figure 5—Refining a search on individual attributes
Refining a search on individual attributes

When an explicit relationship exists between the filtering options in a set, it may be preferable to expose that relationship within the filtering controls. In Figure 6, the data has a strong hierarchical relationship that the user interface expresses and enforces.

Figure 6—Representing a hierarchical relationship between filters
Representing a hierarchical relationship between filters

The examples in Figures 4–6 highlight the use of expandable groups of options for filtering the data in a table, as follows:

  • adding filters to and removing them from a list, as in Figure 4
  • providing input fields for each attribute column to let users search each column of a table, as in Figure 5
  • using a hierarchical filtering control whose content changes, depending on a user’s selections, as in Figure 6

Certainly, there’s no reason these solutions couldn’t always be present on a screen like the options we looked at earlier—and vice versa.

Sorting It Out

In each of the options I’ve discussed, the ability to sort a table remains a useful way of drilling down to specific content. Sorting, of course, can occur either when a user clicks a table header to sort a specific column, which corresponds to a specific data attribute, or uses a dedicated sorting control, as shown in Figure 7.

Figure 7—Two common ways of sorting a table of data
Two common ways of sorting a table of data

While we’ve looked at a number of design solutions for filtering large sets of tabular data, this isn’t an exhaustive list. So, if you’ve encountered other ways of getting through a large set of tabular data, I’d love to hear about them from you. 

Product at Google and Speaker and Author at LukeW Ideation & Design

Silicon Valley, California, USA

Luke WroblewskiAn internationally recognized digital product design leader who has designed or contributed to software more than 700 million people use worldwide, Luke is currently Chief Design Officer for the newly launched startup Bagcheck. He is also an Entrepreneur in Residence (EIR) at Benchmark Capital and speaker and author at LukeW Ideation & Design. Before embarking on his entrepreneurial career, he was Chief Design Architect (VP) at Yahoo!, where he was responsible for product alignment and forward-looking, integrated customer experiences on the Web, mobile, and TV. Formerly Lead User Interface Designer on the platform team at eBay, Luke led the strategic design of new consumer products and internal tools and processes. He got his start at the University of Illinois, where he taught graduate interface design courses and worked as a Senior Interface Designer at the National Center for Supercomputing Applications, birthplace of NCSA Mosaic. Luke is the author of two popular design books: Web Form Design: Filling in the Blanks and Site-Seeing: A Visual Approach to Web Usability, as well many articles about digital product strategy and design. He is a top-rated speaker at conferences and companies around the world and a cofounder and former Board member of the Interaction Design Association (IxDA).  Read More

Other Columns by Luke Wroblewski

Other Articles on Information Design

New on UXmatters