Vendini: Patron de-duplication
My role: Senior UX Designer
A performance venue's list of patrons is arguably one of its most valuable resources. However, that list is only valuable if it contains quality data. And the main thing junking up that data is duplicate records.
De-duplication works best by creating a de-dupe session, identifying all potential duplicates and then displaying each set of duplicates in a series. This assures the user that once the session is done, their database is duplicate-free.
However, a particularly long de-dupe session may not be completed in a single sitting. Therefore, we needed a way to store uncompleted sessions and allow the user to resume a session upon returning.
What determines duplicate records is impossible to predict, as it depends on the user's particular data. Therefore, we decided to let the user choose which fields to compare in determining duplicates.
Choosing Correct Data
When comparing duplicates, the differences are important. The user must decide which data is retained in the newly-merged record. The results of this decision must be made clear before a user can confidently merge multiple patrons.
Stop Showing Non-Duplicates
Sometimes the system will identify unique records as duplicates. (Think multiple patrons named "John Smith".) In this case, there's no point in repeatedly identifying these as potential duplicates when they're not. The user needs a way of telling the system "These are not duplicates. Stop saying they are."
Due to backend technical constraints, once multiple records have been merged, there's no going back. The user needs to be aware of this, but only at the time when it matters.