Search vs. Filter Preconceptions

Design Thinking
#1

One of the ongoing conversations within my organization is the labeling of certain buttons as either “Search” or “Filter” buttons to get only specific rows of information from already-displayed data tables on page. Our current paradigm is that the “Search” button actually goes into our systems and pulls out a fresh set of data, whereas a “Filter” button uses data already in memory and simply doesn’t display anything that doesn’t match the selected criteria. The upshot is that “Search” buttons take significantly more time to execute their functions than “Filter” buttons, since “Search” functionality requires pulling back data from older legacy systems that can’t be sped up.

This has me thinking-- from a UX perspective, when it is appropriate to mark something as a “Search” button or a “Filter” button? Should searches only be used in conjunction with text entry fields, while Filters are limited to a selection of options applied to existing columns within the data set? That’s my gut feeling, but I’m having a hard time finding anything to support my theory.

What are your thoughts/resources?

#2

A filter button should only be relevant on a screen that is already presenting data.

3 Likes
#3

@SteveCrow I like this approach and I’d like to add that even if there are no data, filter controls should be there, to help users skipping dead spot and to refine the initial query.

For instance we are searching for a specific type of shoes:

  • users type new balance 574 in the search field
  • users land on a zero result page (ZRP) due to the fact that there are no results for “New Balance” “574”
  • within the ZRP there are some filters to choose from to optimize the initial search, for instance a dropdown with the models and the list of available New Balance models
#4

Hi

Can be a good option to, have the search button change to ‘update search’ or something similar after a filter is applied. I’ve seen this work very well.

Paddy

1 Like