I know, this is a very broad question and there's a lot of context to consider, but how would you offer quick filtering of large data sets (tables/list views)?

Currently, software products in our company employ two different patterns:

  1. Text boxes for each column of data (below the header). The input is matched against the data in the same column.
  2. One text box for the entire table. The input is matched against any column.

enter image description here

In the long run I'd like to consolidate these patterns into one consistent pattern for filtering. Currently, I've a strong personal preference for #2:

  • #1 is not widely used (however, Excel does something similar for tables)
  • The UI can easily be translated to most platforms
  • Users don't have to reflect in which column a string of data occurs
  • It is relatively easy to determine if a table is currently filtered (because there's text in the box). #1 doesn't provide such a natural clue, if the filtered column is off-screen
  • Users can search for data that isn't displayed, when its columns are hidden

However, #1 has some advantages:

  • It is relatively easy for users to define more complex filters over several columns. #2 would force you to use some kind of artificial query language for the same flexibility.
  • The results are fewer (since only one particular column is matched), while #2 might show some (or depending on the data set even a huge lot) of undesired results
  • It is easier to provide data-type-specific filters for discrete states that are represented as icons

Again, I believe, it is hard to weight these options for just any data set, but quite frankly, that's what I have to do here. The data of our customers varies wildly and sometimes comes from external sources outside of our control.

I'm very interested in any conclusive research and/or anecdotal evidence, if one or the other (or something entirely different) works well for such a general-purpose setting.

4 Answers 4


For me the only reason to avoid the single search (2nd option) would be to have several columns with similar content, thus leading to an inefficient search.

If that's not the case I would totally go with the single search:

  • There's only 1 entry point for search, thus less cognitive load. The users only have to think what to search, not where to search it.
  • The search input + state is clearly visible. If the search remains inside the table it blends with to the real data, visually mixing the input with the output.
  • Some columns won't need a filter, so you would have to disabled them or make the table ignore the filtering by that column, or any situation that lead to inconsistencies.

You have already mentioned other valid reasons.


I find the search box more intuitive for search. However, the text boxes provide a way of advanced filtering. So, the question is - do you want your users to search or filter?

If you want both, you may consider the following intermediate solution, Amazon is using the same. Your search box searching all columns by default but the user has the option to search a single column.


download bmml source – Wireframes created with Balsamiq Mockups


There's a very good article on UXMatters about filtering information in tables. Although old, it still makes a lot of sense. A few options have been considered, like data filters above a table: enter image description here

filters to the left of the data

enter image description here

or tabular format in case the number of filters is low

enter image description here

There's also a good discussion about consistent availability and visibility of filters.


Actually your 1st option is a Filter, while 2nd one is rather a Search. They are just different tools. And both tools are useful.

But dealing with large and complex datasets, I'm for 1st option.

  1. Per field filters provide more clear mental model. Table explicitly presents the data in highly structured view, which affects user's mental model. They think on data in terms of key-value pairs, where keys are headers of the table. Google's single-line search control isn't the case here, as they don't show internal representation of the data.

  2. More rich and clear semantics of filtering. Dealing with large data set, you need to provide appropriate tool to process it. General rule is: greater specificity provides better results. Single input filetring (search) leaves user out of the control.

  3. The right control provides better usability. You can measure and compare it easily: time for task execution, number of errors, etc.

    Also please note, filtering isn't limited to the options above. You can provide separate control for filtering, which solves the issues of hidden columns, etc.

  • In a more general setting, I agree that there is a distinction between search and filtering. In general I'd expect a search to display its results in a separate view or window from the original data. Most of the time you don't even have access to a view with all data the search is based on (Google) and start with a blank screen. However, here this is not the case, the user's goal and the behavior of the list view are identical in both interfaces. Balsamiq's "search" hint in the textbox is a bit misleading.
    – Chris
    Jul 6, 2015 at 5:59
  • @Chris sure, the results look the same. Still the form of displaying the data affects user's mental model. Table's headers don't reflect the hierarchy of the pieces of data, each header is used equally to explore/dissect large data set. In a list view items DO have hierarchy, you set it with visual means (size, contrast, location). So we can assume the users will populate the single search field with main data element which is obvious from the UI. But you asked about large sets (both wide and deep). Jul 6, 2015 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.