Help a user to choose from a long list

[willrichards]

I've observed different teams researching the best way for a user to make the right selection from a long list, often resulting in repeat findings.

My suggestion is to compile some guidance on 'Help users to choose from a long list' to reduce the duplication, and to help teams select the right method for their scenario first time.

This might include guidance around:

• when, and when not to use patterns
• research findings on what makes the patterns work well
• content advice on what to do with long lists of data, and how to optimise for selection

I have the following questions:

1. Would guidance on this topic have value for teams?
2. Are teams willing to contribute examples to this discussion on GitHub, showing what works well and what doesn't?
3. Any other feedback or suggestions welcome

[robertdeniszczyc2]

Hi Will,

Guidance around this would definitely have value. I wonder if one consideration around this is the context which the list is in, and what defines a "long list"? Is 10 items classed as long, or 10,000?

If there are thousands of items in the list, is a list the right pattern to use for displaying the information?

Thanks,
Rob

[tomyems]

I think we should cover what we mean by long in the guidance. Perhaps with less than 10, about 100 and 1,000? There isn't going to be one answer, but guidance about the advantages and disadvantages of different designs would be helpful for designers.

[guermanc]

Some interesting observations on accessibility of listboxes from ARIA Authoring Practices Guide Listbox guidance, which will be especially relevant to long lists of options:

• Avoid long option names
• Don't use option names that start with the same word or phrase

There's the optgroup element for dividing up groups of options but screen reader support is not great https://a11ysupport.io/tech/html/optgroup_element

[GenevieveParke]

In UKVI we use a 'type ahead' pattern when we want users to select their country of nationality

[daniel-ac-martin]

In case it is relevant: https://github.com/alphagov/accessible-autocomplete
(Might be a little neglected, but maybe there is some good design stuff in there.)

[larab-codes]

[LauraLian]

LinkedIn blog post with a design using a long list of radio buttons (with hint text) instead of dropdowns or typeaheads from Adam Silver.

[LauraLian]

[LauraLian]

Content from the email from Adam Silver (not my content):

Last week I posted this on LinkedIn:

===

I tell my students to avoid select boxes.

Because it’s often better to go for radios.

But they often say “But it’ll make the list long”.

Yep, but that doesn’t necessarily mean it’s bad UX.

See below for the page I designed to let users select a course. Huge list of radio buttons. But no issues in user research whatsoever.
​
Does this mean you should always use radio buttons?
​
No.
​
But most designers would balk at a design like this (even though this design worked well for my users).

Long list of radio buttons for users to select a course

Many designers and researchers criticised my design in the comments. Some even accused me of breaking a UX law.

So today I’ll respond to the 6 main criticisms, to give you all the ammo you need to try this out yourself.

Here goes:

“How did you test it?”
We asked users to make an offer.

To make an offer you have to go through a multi-step flow. One step involves selecting a course from the long list of radio buttons.

The result:

Everyone chose a course quick and easily.

But what people really meant was:

“What other options did you test? Just because this worked, doesn’t mean it’s best!”
I rarely test 2 solutions at the same time.

Don’t get me wrong: I consider many options.

But only one gets tested (unless it fails, then I try another).

That’s because there’s usually a clear winner. Plus testing 2 versions has downsides.

But even if there was a better design out there, given how well the radio buttons worked, it would be a lot of effort to shave just a few milliseconds off the interaction.

Plus the product had many other more important issues to solve.

“I would use a dropdown.”
Most designers love a dropdown (select box):

That’s because it’s the easy choice to keep your UI clean and your page short.

But select boxes have downsides:

Some users try to type into them
Some users confuse focused items for selected items
You cannot pinch-zoom on mobile
You cannot add hint text (like I did with the radio buttons)
But even if you ignore these issues, select boxes don’t make the list shorter. They just hide it behind an extra click.

“What about an autocomplete?”
In case you don’t know, an autocomplete control is a text box that reveals options as the user types.

But autocompletes have downsides:

Some users may not know exactly what to type
Some users may not realise they can reveal all the options
Some users won’t spot the suggestions as they type (they look at the keyboard)
All of which degrades UX and increases the time it takes to select an option.

Don’t get me wrong, I would have explored this pattern if radio buttons performed badly.

But they didn’t.

“There’s too much scrolling, especially on mobile”
We didn’t test on mobile because our research showed that users were all on desktop.

But that’s a copout so let me address the point directly:

There’s nothing else on screen but radio buttons, so there’s nothing users need to scroll past (the radio buttons are the UI)
Scrolling a web page is no harder than scrolling an overlaid list of options (like you’d get with a select box or autocomplete)
It’s quick and easy to scroll on mobile (one or two flicks max)
“You broke Miller’s Law”
Miller’s law states:

On average people cannot hold more than 7 items in their short term memory.
So because I used 20+ radio buttons some people think I broke the law.

But users don’t need to store them in their short term memory. They’re literally on screen.

So that’s the main criticisms addressed.

But what do they tell you?

Here’s what they tell me:

Boring design is not always popular with designers. But it’s almost always good for users.

If you’d like to learn how to design simple, accessible and rebellious form flows that break the law (and actually work), you might like my course, Form Design Mastery:

​https://formdesignmastery.com/