Which is best, predictive text (aka type-ahead), or a pre-populated dropdown? As ever the answer is ‘it depends’. However, I do sense that predictive text has become the default, even when it might not be the right thing to do. Which approach to take on the British Airways booking panel was the single longest running argument I had with colleagues at BA.
To choose where you wanted to fly from there was one dropdown for country and one for city which was populated according to the selected country. However, to choose where you wanted to fly to, it was predictive text. When the user started typing matches would show up for city, airport, or country names.
The funny thing was that time after time colleagues at BA asked why we didn’t change the dropdowns to predictive text. My boss, my team, colleagues in the business would all argue passionately for predictive text in the ‘From’ field. The reason that was odd was that on a number of occasions in usability labs customers would ask why we didn’t change the predictive text to dropdowns in the ‘To’ field. Not one customer ever asked for what my colleagues wanted. Yet when I explained this internally people found it very difficult to accept as it was so counter-intuitive to them.
So why was the panel designed that way? Good question. I’m not sure I can clearly articulate the original thinking, but here’s the post-rationalisation. If you are flying from somewhere the likelihood is that you know where you want to go from — or at least which country. It’s also likely that many customer don’t know which airports BA flies from, but by selecting the country they get a definitive list. It also means that you don’t have to be able to spell the name of an airport or city to get a hit, and if your favoured city isn’t in the list then you know for sure BA don’t go there. Those factors aren’t catered for in predictive text.
If you are flying to somewhere there’s more of chance that you’re not so familiar with the destination. If you know you want to go to Sofia you may not know which country it’s in. You might not even know what continent it’s on. So the predictive text is less constraining where a search might be more diverse.
In the usability labs customers liked the fact that didn’t have to think — so long as they knew their departure country.
By contrast, let’s take a look at what Ryanair do.
Both the ‘from’ and ‘to’ fields have a consistent design which in principle is good. You can pick the country, and then you pick the airport. But you can also just type something in. If you didn’t know which country Dusseldorf was in, and typed ‘Dus’, then Dusseldorf would show up. The customer gets the choice of which method to use.
I do recall a time when Ryanair had all destinations in a single dropdown which covered the entire page of a desktop screen. It was a bit much.
There is a sense in which pre-population merges into a hierarchical navigation. Amazon couldn’t have a single dropdown with all their products in it, but you can drill down through the product listings to get a relevant (more or less) set of results. It’s the same principle as the BA and Ryanair menus, just presented in a different context.
A simple rule of thumb is that if there is a ‘small’ set of possible choices, then use a pre-populated dropdown. If you use predictive text then a key issue is how you handle errors. You could disable progress unless a valid choice is made from the options displayed. This eliminates the possibility of the user getting an error from the search, but doesn’t help if they don’t know what the choices are or what the spelling is.
If you don’t force a valid choice then if the user enters an invalid search term it’s typical to see ‘did you mean’, as exemplified here by Amazon. I searched for ‘beetles red album’, and the system guessed that I wanted the ‘Beatles’ red album, but still allowed me to insist on ‘beetles’ if I really wanted to. This is useful.
It can also be useful, even if the user enters a valid search term, to show alternatives.
There is a Sydney in Australia and also one in Canada. There have been occasional stories in the press of travellers flying to the wrong one. Perhaps if their search engines had been clearer that there were other ‘Sydney’s the error might have been avoided.
There is a Grenada in the Caribbean and a Granada in Spain. Just because someone types in, or selects, a valid search term doesn’t necessarily mean that it’s the one they want.
The booking panel on ba.com now has predictive text
This approach doesn’t wait until the user has hit the ‘enter’ button to let them know their search term isn’t recognised, and it makes helpful suggestions.
As is often the case with design there are some useful patterns out there, but which one you choose will depend on context.
If you have a limited number of defined choices use a dropdown. There’s no hard rule on how many is too many. That again can depend on context and how users react. Once you get to too many then you need to start categorising into a menu structure.
If you use predictive text consider whether you want to force a valid choice. Let the user know that their text is not recognised (where appropriate), and offer alternatives. You still often see a simple ‘no results’ as a consequence of a simple spelling error. Consider whether it’s better to alert the user to the issue before or after the search button is pressed.
The two approaches aren’t necessarily mutually exclusive, as the Ryanair example shows.
A little thought and consideration of the issues could make a significant difference to experience on many sites.
Here’s a comment from an ex-colleague, Allan Dade:
Predictive text can pip drop downs to the post if they are built correctly for screen readers. Drop-downs are a tad easier to build to standards as long as the number of ‘results’ are announced so that the visually impaired customer doesn’t have to. Longer dropdowns can cause display issues on mobile, while assistive choice can be disrupted by the way a user uses their device.
Source link https://uxdesign.cc/predictive-text-or-dropdown-which-is-better-701050e88bbb?source=rss—-138adf9c44c—4