Usability of autocomplete overwriting user input

Question

We have a web application for professional users, who have to register with their organisation and department. And of course there are tons of ways to write out the name of the same department. But because our application is open to everybody in that profession, we cannot use an existing list of departments (we would need a list of all departments in the world!)

Currently, users have a free text field with autocomplete suggestions for the department when registering. Nevertheless, our users frequently register an existing department a second time instead choosing their department's name from the autocomplete list.

We see three possible options here:

1. Leave it as it is, and manually merge double departments later
2. Use a dropdown for the organisation selection, with a "create new department" button for those whose department is not there.
3. Change the behavior of the autocomplete field. Once the user clicks outside of the field, the content gets replaced with the first autocomplete suggestion, whatever it was. The way for a user to avoid this is to first hover with the mouse cursor over the autocomplete suggestions but not select any, then click outside the autocomplete field or its list of suggestions. This way, the user always gets registered with the department whose name best matches the string he entered.

Which solution (of those above, or a different one) is likely to be better UX, given that we don't have the resources to A/B test.

Answer 1

I come across this all the time, so I have a prepared answer for this.

We are not building solutions for the benefit of the developers - we are building them for the benefit of the users. Making something easy to use is rarely easy to do. So if you want an easy, usable solution, it might be difficult to do.

• Option 1 - difficult for the team to build and will probably require a new set of additional features to moderate things that cannot be achieved programatically. However, moderating duplicates could be very a useful set of future features for someone (you can research this).
• Option 2 - I don't see how this would be complicated for a user, either their department is in the list or not. However if not, there is a very clear trigger to create it (which could be moderated in the future features if needed).
• Option 3 will cause user frustration. If something is set without the user explicitly selecting it, expect the user to be confused and say WTF!

So Option 2 gets my vote because it is very clear, simple to use, and simple to build.

Answer 2

Autocomplete functionality is great for advanced users who don't look at the keyboard whilst typing, however lots of users need to look at the keyboard. This can cause them to not even notice the autocomplete suggestions, this type then hit tab or return.

A UX pattern of search then select for a list (ideally not a <select> one) with a "don't see your department" or "add new department" button/link might be a better and more inclusive solution.

You could also do some validation on the data before putting it into the database to check for duplicates.

Answer 3

The problem is not with the autocomplete field, but with the creation of departments. Right now, registering a new department and picking one from a list take about the same amount of effort. To minimize double-listed departments, it should be considerably easier to find one than to register one.

There are two ways to do achieve this. A: make the finding easier, or B; make the registration a bit more difficult.

I suggest a combination of both. Right now you have autocomplete, but how about turning that in a slightly more advanced search function? Not just query for the string, but if a user types in "Germany" also offer that as a button and have it lead to a list of German departments. Perhaps a map? Categorize by type of department?

Secondly, don't just let them add departments. Require them to fill in a good amount of information about them, and make it specific. Not just department name and town, but ask country, phone, address, zip. Don't accept all combinations (e.g. "12345AB" vs "12345 A B") but enforce a specific one.

Then, if they are creating a department, you feed that information back to the query. Because it is now more specific, it is much more likely to have a correct hit. Suggest this hit to the user "We have department 'Potato' listed at 12345AB, is this your department?" and then you can cut them off from creating doubles.

In short: make it easier to find, make it harder to create, let creation tool also work as find tool.

Yes, making this will cost effort from the dev team. It's their job, suck it up and be happy with having work.

Answer 4

I would say combine both option 2 and 3. Give a dropdown of department list to a user and keep "create new department"/ "dont see your department"/"not finding department"/"other" as last option.

Since department list will be more, its better to have a button near to the drop down as suggested in prev comment.

Once User clicks on that, you can show text box and show suggestions as per User entered text. User can either select the suggestion option or continue his own.

We need to check for duplicate, spell correction, text cases and also add the user entered department to the dropdown only if more than 5-10 users try to add the same department.