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:
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?