What is better interaction when we have many search criteria and many search results and is continuous flow?

Question

I am working on one requirement where we kind of screen flow (steps to complete). First step is to search the list of claims and select it and proceed to next steps. Similarly we have different steps going forward.

Question: we have many search criteria, search result is expected to be more (even using filters). We are dealing with lot of data here. My current idea is to show search criteria on top (I will divide primary and secondary criteria and secondary can go in to advanced search) and search results on bottom part. But we will have hundreds or thousands of results, so is it advisable to show search results in next step altogether? May be in step 2.

Problem: If we shoe search results 2nd step, user will have to go back and forth to change criteria and again search results. But if we show search results on same page, we might face performance issue.

What is best in terms of interaction and navigation, considering the steps, many search criteria and performance of the system?

I am attaching one screen which has dummy data. Just for your reference.

Answer 1

Search controls and results should be on the same screen, as users probably need to change search criteria for complex data after reviewing results (you anticipate this case in your question). So this is results which drive the criteria changes: user uses results as feedback.

Still, manual selection among hundreds or thousands records is a) a hard task for human, as it creates a huge cognitive load, and b) it increases time of the task. Also you have a huge risk of getting c) low-quality results/errors.

So here you potentially get bad outcomes for all the components of usability: user satisfaction, efficiency, and effectivenes.

I suggest to conduct user research to build the better task flow and UI.

There could be better alternatives for your UI, but more information of the task and users is needed. One of them is building the funnel, when on each step the results are refined. It's good for non-pover users. Other option is to have main filters and sub-filters to refine the results. You also could use pre-sets, which deliver great performance.

Answer 2

This is a typical use case, where search pagination can be applied. According to the Yahoo Design Pattern Library:

When searches return too many results to display on a single page, separate the information into a sequence of pages.

Provide pagination control, as a row of links, to enable the user to browse through more results than can be displayed on a single page.

Applying this pattern not all search results have to be loaded all at once, but only when the user requests them. The search results should be displayed directly below the filter controls in order to prevent the user from jumping between step one and step two.

Additionally you could add an evaluation panel that groups the search results by specific criteria, for example STATUS or CLAIM TYPE could be suitable for grouping. The principle is shown in the image below (source: bitzesty.com). It allows the user to filter the search results afterwards (across several result pages).

Answer 3

If you are dealing with users who are in this application regularly, using this feature every day, you might consider an advanced query builder. Imagine one text input field where you can type not only the filter terms, but the filter categories. So, if I type sub + tab + Jan 2, the filter Submission Date: January 2, 2015 is automatically applied.

Similarly, if I type browj, the system automatically suggests a fiter to that subscriber.

Many applications use this mechansim: Evernote will try to guess if I am typing the name of a tag or a notebook. Outlook will suggest that I limit my search term to the Sent-From email address. Jira allows you to create custom views based on a number of criteria.

This makes it very quick for an experienced user to add and remove filters, and to save and re-use filters (by copying and pasting them in, or you could introduce a save-view features)

You would need to test this with your users, since it is a bad idea for people who don't use the feature very much. But, if it works for them, you could hide all of the individual filter criteria under a "advanced" accordion panel, which would give you more room to show results.

Answer 4

A possible approach I have used in the past is the to split each step of the wizard or multi-step process in many horizontal layers or sections.

For example Step 1: Select Claims could comprise of the following 4 elements

1.A Search for Claims - This step should only present the search criteria and a search button prompting users to start searching.

1.B Search Results - 46 claims
- This section presents the results following 1.A., a search result counter and the pagination allowing users to browse and select multiple options.

1.C Selected claims - This section simply prints the results selected by the user in 1.B in real-time. This section is needed because due to the pagination provided, the user may move to the 2nd page but would still need to know what has been selected without moving back again through the pagination.

Button to move to the next step

---

I hope that this helps. It will surely help novice users as it is a guided approach that discloses information progressively.

Regarding the insane use case with the 100s of filters required for this feature, the following needs to be performed to really understand user behaviour: (a) monitor the usage of each filter (how many times has it been filled per search) (b) eliminate filters with less than 0.5% usage - there will be a lot. (c) group according to their usage (core filters appearing by default as expanded and "advanced criteria" expanding after the user actually selects) in step 1.A.