7

Problem: We are working on a medical scheduling application. A common problem are duplicated patient records, stemming from legacy data or from careless inputting under pressure, without consulting whether the patient exists (input will be subject of another question).

Solution: We're preparing a diff tool for merging records and struggle to make the screen easy to understand for non-programmers. The users know about the problem duplicated records cause and know which records are duplicated.

A first draft, using Material Design, looks like this, once the user has selected two records:

Draft

Where the system detects differences, the user can chose whether to update the "good" profile on the left, or whether to discard the change (the icons between the records toggle between "overwrite/copy" and "ignore/delete"). The system suggests a default, so there's no "null" state. Once the user presses "unify", the "good" record will be updated and the "duplicated" record on the right will be deleted, along with all data attached to it.

I have sent this screenshot to some users, but they didn't understand that there would be any updating. Some feared that they would lose good bits of information of the deleted record.

How can I better explain "diff-and-merge" to non-programmers?

Improve this question

2 Answers 2

Reset to default
6

I would reduce the information and show the user a window per attribute, but only attributes, where the value will change:

enter image description here

When the user clicks on 'Discard' or 'Apply Changes' the next attribute will be shown until all attributes are merged.

Update:

If you do not want to use one window per attribute, I want to suggest you to list all changes and work with checkboxes (checked by default):

Merge

The user is able to discard some updates via the checkboxes.

Improve this answer
3
  • Thanks for that idea! I like that the user will see less information at a time. This will not work for cases with lots of differences (above 3-5?), IMHO, because the user will feel like doing flash-cards. Also, he should be able to break out of the process. Don't you think it is easier to see the full record and only interfere where interferance is needed because the user disagrees with the suggested action?
    – PeerBr
    Mar 23, 2015 at 15:37
  • You are right. I have added an second suggestion.
    – Simon
    Mar 23, 2015 at 19:17
  • This is clever, thanks. I like the (deleted)! I'm afraid my point still isn't perfectly clear: One of the two records will be deleted (the user wants the duplicity to end!), so instead of "old"/"new", it is better to talk of "original"/"duplicate". The "appointments" in the screenshot are linked to the record and will be either re-linked to the "original" or deleted. Often, the "dupe" holds some nuggets of valid info we want to keep - so the merging will almost always be additive. Do you feel (open question) your design makes it clear that we're updating only one record and deleting the other?
    – PeerBr
    Mar 23, 2015 at 19:29
0

To me the design reports more on losses than the final result while as I user I am "building the correct record". Maybe if you make the final user and its data the most important on the page it could help.

Random thoughts about how:

  • making the updated card visually more important than the deleted one (Some green to updated and some gray to deleted?)
  • strikethrough red data
  • put an icon or green/blue/yellow background to updated data
Improve this answer
1
  • Indeed, the design focusses too much on the "loss", great explanation. I'll have to think about that!
    – PeerBr
    Mar 23, 2015 at 19:35

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.