How to tell users that s/he might be adding a duplicate record

Question

I have a form where users can add new contact records. Multiple users all use the same form, so it's quite possible that user ABC might try to add the same contact record that user DEF has already added.

So, there are multiple ways in which we can handle this situation:

1. Give user a search option up front on the 'Add Contact' page, so they can check for duplicate contacts before adding.

2. Let the user add the contact details and while provide feedback while they fill out the form. Give the user warnings depending on the data that they have added (see the UI below). The user can ignore the warning and keep on adding the details, until they hit the 'Save Contact' button and finds that they can't add the contact because it already exists in the system.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Question: What would be best approach to solve this problem? Option 1 or 2 or a mix of both or something else?

Answer 1

I'm trying to understand why you would wan't to validate the First Name and Last Name of the records users are adding into the system.

Basically, this doesn't appear as a valid scenario, because in any system there can be users with same first name and last name. Even in a small organization with one thousand employees; the first and last names conflict with many employees.

It would be wise to give the users a unique User ID and apply the validation on user ID. In case if users choose duplicate user IDs, display a validation message as:

Additionally, you can apply validation on Mobile Numbers (you have that option in your form), as they are unique.

Answer 2

Upon completing the form, bring up a notice indicating that similar contacts already exist in the system. Show a summary of each of those contacts, and allow the user to either select one of those existing contacts (possibly updating the contact's info with any new information) or continue creating the new contact.

Answer 3

There is a very simple way. First of all, let's consider which data can be duplicated and which data cannot be duplicated.

As other answers mentioned, Name (first, last or combination of both) is not a good choice, since there might be many repeated names.

So you have mobile. This could work on an intranet or if your app is restricted geographically, eg only one city. Otherwise, you could have the mobile number NNN-NNNN for someone in Big City and then NNN-NNNN for someone in Small City. You might say "OK, let's validate with city prefix". Then you might find an user wit mobile number NNN-NNN-NNNN in UNicornCountry and then mobile number NNN-NNN-NNNN in RainbowCountry. To make it worse, not all countries have the same amount of digits, so this is clearly not a good choice either.

But do not despair! We have a field that is very easy to validate, we can use for confirmation AND can't be repeated: email. Since there can't be 2 emails that are the same, this is a perfect choice.

Now, with this in mind, we can make things run smoothly. Check image below (click if you need to enlarge):

It's as simple as this:

1. we add mail as first field to avoid user fill unnecessary fields in case of existing accounts.

2. System checks if the email isn't duplicated

3. If duplicated mail, we offer teh user the option to access her account.

   3b. If not duplicated, then we create account AND we can ask for confirmation of mail account

And that's it. Simple and to the point.

Answer 4

I would suggest that you shouldn't validate based on a unique name as it is not unlikely that you could end up with 2 people with the same name in your database.

Validating the phone number might work as generally a phone number is unique and not shared by multiple people, though if this is a landline, you may find that multiple users share the same number. It may be most sensible to show a warning if the user is trying to add an entry with a duplicate number, but allowing it if the form is submitted.

You could also add AJAX to your first and last name form fields which displays matching users when the form is being filled in. For example, if I am adding John Smith and whilst typing a list on the side shows that John Smith exists with a phone number I am about to enter, I know that he exists on the system and don't have to add him.

Answer 5

Exact Matches (with a Natural Key)

Your approach will be fundamentally different based on whether a Natural Key exists for the type of record your are trying to create.

A natural key is something that uniquely identifies a piece of data that already exists in the real world. For example, if your record has a Social Security Number, ISBN, Active Directory Account, or occasionally email / phone, you can prevent duplicates by guaranteeing each record has a distinct key.

For example, here's the sign up page on Twitter:

Note 1: As with any validation error, it's best to do so inline and immediately if the data state is invalid. So you should prompt for any unique information first, either in a stepper or seperate page in order to avoid any unnecessary typing.

Note 2: Bear in mind that you might NOT want to use email or phone as a unique identifier for contact records (for example, multiple professionals can all share the business contact email and phone number).

Note 3: While you can create your own sort of natural key, like a username, this isn't really a mechanism for prevent duplicates of anything but the generated name itself.

For example, here's the sign up page on Reddit:

This does a great job at dynamically showing validation errors as you type. However, the same user/person/individual can still create nearly identical accounts. Even though we've generated an identifier that will bear real world significance, it can only be used to differentiate accounts, not people.

Similar Matches

If we rely on multiple fields to establish a record AND genuine records can repeat information across fields (i.e. same First Name + Last Name + DOB), then the best any system can do is look to minimize the amount of duplicates, and technology can play a role in that business process.

Now the question becomes:

When is the most appropriate time to show users a list of similar looking records during the process of creating new records?

Option 1 - Synchronous / Modal Matches

When presenting potential duplicates in a synchronous fashion, you need to collect enough information to know about the incoming record and then have the user review potential matches before proceeding.

For example, here's the steps for adding new foods to My Fitness Pal:

Note 1: You should seed any search parameters into the new item if the user proceeds to creating a new record so they don't have to type the same info twice.

Note 2: How strongly you programmatically enforce the review will depend on the severity of duplicates and user telemetry from your actual system. For example, you could force scrolling / reviewing each one before proceeding to the actual creation step (like the TOC agreement on many sites).

Note 3: When identifying potential duplicates programatically, make sure to check for typos, nicknames, alternative spellings as well.

Option 2 - Asynchronous / Modeless Matches

This approach assumes the happy path and allows users to immediately begin entering record information, all of which becomes available for identifying potential matches asynchronously.

For Example, here's the steps for asking a question on Stack Overflow:

Note 1: When dynamically inserting potential matches (or any new content) onto the page, the content should come to the right or below the current page position to prevent the content from jumping and the user from having to regress back to a previous portion of the page.

---

In terms of choosing between synchronous and asynchronous checks, you might want to review your data of how often users successfully add new records without creating duplicates. If 80% of the time, users create unique records, then forcing them all through the duplicate check bottleneck is an added pain point and needless context shift.

Nothing forces users to actually read any information you put on the screen, so the goal should be to put something that looks and feels useful on the screen that will help them save time. And doing so requires really good matching algorithms without a lot of noise.

Deduplicate Records - Journey Mapping

If this is an important feature for your business, remember this need can also be addressed at multiple other interaction points. Certainly, it doesn't hurt to address during creation (GIGO), but you can manually deduplicate after the fact as well with functions for:

• Individual Users
  Put the power in the user's hands to review their own data quality, as per Google Contacts:

  

• Community Reports
  Ask for help from users to keep content clean (the wiki model), as in Untappd:

  

• Moderated Review Queues
  Ensure admins review system wide duplicates, as in Stack Exchange:

  

Further Reading:

• How to prevent creation of multiple accounts under the same company?
• How to design a 'Search for Duplicates' GUI in an Image Cataloging Program

Answer 6

Option 1 is a good idea but in these images you have shown first name and last name for validation which will prevent some users who have the same name. Add validation validation on mobile record because 2 users cannot have a same mobile number.

This answer is based on the fields shown in these images if you have username then username could be the main and first validation point. Live inline validation is better because you are asking users to do all the work.

Read the link given below: https://baymard.com/blog/inline-form-validation

Answer 7

Website with username oriented unique id have single field for username where name and last name are provided in single field and when username is already taken it is shown immediately with help of ajax search without reloading the page.

The website which has option for first name and last name are supposedly have some other unique id such as phone number or email address which must not be a duplicate, these kind of sites are social networking sites where a large number of user share a common name but different phone/email id.