3

I am in the process of building a new component for an existing application and I have a fairly specific scenario I need to design an interface for. The purpose of the tool is to allow a user to do a mass search of arbitrary data against an existing database and to return the best guess at a match if one or many are found. I have been looking all over for examples of something that is similar for inspiration, but I haven't found much that seems to get close. I will detail the entire process in the hopes someone can help me get unstuck :) The general workflow is as follows:

User uploads a CSV file containing rows of data about an individual. Each column of the file contains similar data (there may be a first name column, a last name column, email, etc). Once the file finishes uploading the user is taken to the next screen. There the "discovered" columns are presented by name. On the same screen a list of searchable fields is present. There are currently 15 of these fields and they are considered constants. They are listed by name (first name, last name, telephone, email etc). On this screen, the user maps their "discovered" fields to the searchable constants by dragging and dropping them. Their file may have any number of columns which will be ignored in the processing unless they map them at this stage. A user may choose to map as little as one field or as many as all 15. Once this stage is complete, the file is mapped and processed. During processing, for each row of data in the file a search is performed that attempts to find the best matches. Without getting too far into the details, a composite score is built that specifies the level of confidence there is that the input data matches some existing user. The top scoring items are returned and the absolute best match (if it exists) is marked as a match. After this is complete the user is directed to the third screen (This is the one I am having trouble with!!!). At this stage, the user needs to be able to quickly review each of the rows that were processed. It's at this stage that the confluence of constraints is preventing me from defining a working solution. I will list the constraints I have identified below (the term "row" refers to a file input row):

  • For each row there may be 0, 1 or many matches
  • For each row it must be obvious a match was picked (or that no match was found), what the match is, and the composite score for the match. These shouldn't be easily confused with the list of potential matches (those with a low composite score that didn't make the initial cut)
  • The user must be able to quickly unmatch a result they deem incorrect
  • a user must be able to replace a match with a "more correct" match from the list of matches (which are ranked by composite score)
  • For every match that is returned, metadata (about 10 data points) will be included to help a user understand why a match was picked or why another match may be more correct (for example, people with the same name at living at the same address could be indecipherable, so we will include the matched item's date of birth to help the user make a judgement on which is more correct)
  • Each search by user or file may be performed using a different number of arguments. For example search one may use first and last name, while a different users search may use up to 15 different characteristics
  • It would be nice if the solution were not terribly ugly and extra bonus points if it could appear half way distinguishable on a mobile device

I think that's the best detail I can give at the moment. Please let me know if something is unclear. Thanks so much in advance for any help anyone can provide :)

  • Matt, it's possible the user interface you describe is attempting to closely follow the implementation model of this search activity. That could be what's blocking you. I wonder if you could generate more ideas, more ways to potentially solve this UI question, to see if you can break away from the implementation model. If you have two or three other people to do this with you, then try the Five Sketches method, described here: fivesketches.com/quality-software-designs-by-sketching (Disclaimer: this post is on my website.) – JeromeR Dec 5 '15 at 12:40
  • Interesting problem - To help understand, is it then possible, say a match for a first name field, for say, "Amit" could show a match that is not, "Amit", but is "Matt"? Depending on, if the composite score is high, say because their date of births and city are same? – Amit Jain Dec 7 '15 at 19:40
  • Yes. We evaluate many interdependent components and narrow the pool down to the best guesses with their calculated composite score. So as you suggested, it is possible to have false positives (Although in the specific example you suggested, the composite score would be lower as heavier weightings are applied to elements deemed more important). One of the uses of the screen is to allow an analyst to sift through less data and decide if our guess makes the most sense. – Matt Dec 7 '15 at 20:50
  • This is a pretty dense question. If you want to increase your chances of getting answers, try breaking up your explanation a bit and, if possible, providing some sketches or examples of some of the atomic functionality you have in mind. – plainclothes Dec 10 '15 at 23:24
4
+50

Ok, after much thought, here are few suggestions (two wireframes attached for reference) -

1) Its better to tell the user at this stage of the flow, about what he is searched against - and possibly modify these parameters.

2) Since the information is more, its better to adopt progressive discovery as a method to portray the info.

3) Hence, suggestion is to have an accordion style row interface, where a snapshot of important info is mentioned, with an option to the user to see more details.

4) Expanded row, has clear approved and rejected sections, with clear scoring indicated, and an option to reject/approve the same.

5) Rejection shifts the bar from left to right column, and vice versa(Motion design could be the visual shifting and stacking of row to right). Optionally a swipe right to reject could be adopted.

6) It could be that, a visual guide, like a flag, change of tab color etc - indicates that the user has viewed/edited the information for a particular row. This helps user in keeping track.

7) The two columns (approve/reject) are scrollable after a certain height. This helps keeping interface cohesive.

8) With a little tweaking, I think this could be adapted to mobile as well.

Obviously my understanding to the gravity of the problem/issue is very limited, and hence it would be interesting to hear your thoughts @Matt. Interesting problem nevertheless!

Rows not expanded: enter image description here

One row expanded: enter image description here

  • I like the idea (an accordion-style feels the sensible way of convey this intelligibly) but it seems to be missing the "it must be obvious a match was picked" (if you're working down the collapsed list, it's not obvious how far you've checked). Possibly an icon at the beginning of each row: Green tick = match positively confirmed by user; red cross: user = has deselected all matches; question-mark = not inspected. Whether an entry with a really strong candidate match is left as a question-mark (must be ticked by user) or tentatively ticked (user deselects if they don't like it) is up to OP – TripeHound Dec 11 '15 at 12:12
  • Or, roughly what you suggested at (6) which I'd missed when I started that comment. – TripeHound Dec 11 '15 at 12:14
  • Thanks so much for the well thought out answer and fantastic wireframes (how did you generate those?) :) Your view of the problem is very insightful and provides a number of fantastic points I can incorporate into the next iteration (I'm on a bit of a deadline, so I was forced to come up with something as a first iteration before you posted your answer). One thing I failed to make clear is that the user can only select the top or best match. For each row of file input data, we will find the best possible matched user in the system or not match the row. Then the user can override it. – Matt Dec 12 '15 at 1:28
  • Hey Matt, glad if the suggestions could help in any way. It will be great to see what first iteration you went ahead with, since that will give a lot of ideas about the context and priorities. Regarding the one best match, I kind of thought that (not exactly as you said though), and hence added that "Closes Match" field in the un-expanded row. Possibly that could change to mean, a system preference - And over-riding could happen once you expand the rows and pick a better option. – Amit Jain Dec 12 '15 at 4:41

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.