We are integrating a BI tool into our maintenance system and I am currently evaluating two viable products to put forward as a recommendation.

One item where these tools differ is their filtering capabilities, one follows the path of selecting criteria and then applying filters altogether. The other updates in real time as soon as a value is selected in the filters.

Are there any viable UX studies or consensus, leading me to believe that one is better suited to a users needs?

The tool would be used on desktop applications only, not phones or tablets.

We will be using 7-8 list style filters, where you can select one or more items from each list like so:

enter image description here

2 Answers 2


This is a very general question, You won't find studies or consensus on such a question. Reason is that in the core of UX is to work out a solution to problems that involve many variable specific to the use case (and users).

Some variables

In your case, some of the variables will be:

  • What does the system do?
  • What is the nature of the filters and the data presented?
  • Why users will filter things in the first place? What data they wish to find?
  • How users do (or assumed to) use it

Information seeking behaviour

With relation to this case, perhaps of prime importance is to know the information seeking behaviour of users, primarily, whether they will:

  • Narrow down on results (in which case live filtering is probably the way to go).
  • Fill-and-submit queries (like when the live results are useless for them - they have to fill in the full query before results will be meaningful). An example is someone looking for a house, they only want to see offers in a particular city, that doesn't cost more than X pounds, and must have 3 bedrooms or more.

Roughly speaking, the two map to the known class and perfect match information seeking behaviours.

For live filtering

  • If you can let users do it in 3 steps, why do this in 4? That is, why provide a filter button if you can not have it?
  • It can promote serendipity - even if I didn't mean to perform this specific query, the results may be useful for me.
  • It can save time, as say if a combination of two filters will yield no results (or unsatisfactory ones), the user won't continue filling other filters. Only you know if a particular combination of filters may yield a blank results set.

Against live filtering

  • Filtering the data may take time (like it would on data-rich web applications).
  • If the live results are of no use, this can be annoying.

Izhaki has some good points, but I think the answer is a bit simpler.

In my experience, the reason some applications handle filters instantly and others don't, is simply a technical one.

Up to a few years ago, data (and big data in particular) was tough to wield. Sure it's easy enough to cache a couple of pages worth of data, but as soon as you start filtering, issues would arise.

Recent developments in the field of data crunching have made it a lot easier to crunch data on a larger scale, nigh instantly. Frameworks like MongoDB, Angular and others focus purely on instant delivery and manipulation of data, allowing developers to easily use super-efficient queries.

With that in mind, my first response to your question would simply be "they went with instant results because their technical set-up allows for it".

Having said that, some data is just so huge and unwieldy that it still requires non-instant approaches, and some companies simply don't have the resources to build a super-fast system.

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.