Should all columns in a data table be provided the functionality of filtering?

Question

In a data table with at least 20 columns and various data types, e.g. strings, numbers, categories, should we provide the functionality of every column being able to be filtered? Or only provide filtering to selective columns if there is a valid use case?

More context. In this data table, inline editing is not allowed. The common use cases are not very clear from the product side.

What are some governing principles to make decisions about filtering?

Answer 1

“Should we provide… filtering to selective columns [only] if there is a valid use case [when the] use cases are not very clear?”

As a heuristic, the more general the use cases, the more general the UI needs to be. If you don’t know exactly how users will use the table, then you should provide users with broad functionality so the users can achieve whatever (unknown) goal they have. So, in your case, support filtering on all columns.

It is true that if you know exactly what user will and won’t do, then you can optimize the UI for just what they’ll do, making a relatively simple streamlined UI without clutter or distractions. That enhances UX (and can reduce development costs). However, supporting all functionality also enhances the UX. Therefore, your design needs a balance between optimizing the design for known (or common) use cases and supporting in some form unknown (or rare) use cases. Here are some signs you need to include broad general functionality like sorting on all columns:

• Use cases are unknown or purpose of app is open-ended.
• Use cases are broad (e.g., “Inspect data” is broad, “Find all records with missing data” is specific).
• The page or window is used in a complex task with a variety of starting points, inputs, and goals.
• Users include domain experts (users who know more about the general task than you ever will).
• Wide variety of users.
• Heavy repeated use (e.g., daily).

Typically, you almost never know all the use cases, so by default include some flexibility for the user to do the unanticipated. Filtering is such a useful function, it’s generally a good idea to include it for all columns regardless of the task. Once you have it for one column, it's pretty undemanding for both developer and user to have for all columns, so why not? The same can be said for sorting and converting (e.g., copying-and-pasting or exporting) tabular read-only data.

For most applications, the only reason to not sort on all columns is if such a functionality will interfere with a common known use case.