3

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. enter image description here

  • Why not minimize the noise? Why do you have to have multiple lines of the same data? "Submission Date, Date of Service From, Date of Service to, Member and Subscriber." If you really need all of that, why not just have a line that says "Add New Claim." – Majo0od Aug 17 '15 at 17:33
  • I think I should have given more realistic data. The data what we in screenshot are dummy we will have different unique fields for each row in real scenario. If this was a case of repetitive data, your point is valid. – Preyash Aug 19 '15 at 10:49
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.

  • Hi Alex, Thanks for your comments. I agree with your point that many search criteria will always increase kind of cognitive load for the user. But in my scenario, we have many search criteria and we are not displaying them in search result grid. And user exactly knows what they are doing, so in that case facet search will not be suggested I believe. They dont want to filter again and again as they have one scenario in mind and they will do it in a single shot. Because by looking the result user will not come to know what are additional filter I need to apply. – Preyash Nov 25 '14 at 8:00
  • @Preyash I don't know neither your users specificity, nor task. Still from my experience users use search results as feedback to refine the results on the next iterations. This is especially true for complex data. It's more cheaper to make several search by PC, than manual selection in bad-filtered data. Just observe your users and make decision. – Alexey Kolchenko Nov 25 '14 at 12:58
0

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.

enter image description here

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).

enter image description here

0

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.

  • Thanks Phillip for your view. It definitely makes sense to give have advanced auto complete filter which gives suggestions and in fact that part is already there wherever you see autocomplete control. Tricky part which I have not talked about so far is that we already have advanced filter option which consist of much more options than what we see here in this screen. I know sounds insane but this is real complex use case we have got here. Good point for saving and re-using the filter option but so far this is just for POC and we do not have any actual users to test with. Thanks again. – Preyash Aug 19 '15 at 10:56
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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