Are Radio Buttons still useful in Modern Web and Application Design?

Or have we used them for so long, and for so many things, that we use them without thinking?

Thomas Pritchard
4 min readMar 26, 2014

I was recently challenged by my UX lecturer to find a place for radio buttons in modern web applications. She asserted that it was an element of a bygone era in web and application design, and, most likely, not necessarily suitable for the current, mobile-first, web, claiming that almost anything that could have been done with radio buttons could have been done better with something else.

I’m not sure that is the case, so she asked me to prove to her that they can still be relevent in modern designs. There are plenty of times where radio buttons are misused in design, and I think this is one of the main reasons people might think that radio buttons are on the way out.

So, to be clear, the following things should not be represented by a radio button:

  • A boolean, yes-no, operation. I know this sounds strange, as this is often when they are used. One should never use a radio button for ‘Accept / Decline’ options. This is what a checkbox is for. Checkboxes should be used when the affect on an object is true or false. Not radio buttons.
  • A selection where only the currently selected option is important. For instance, say you have an option for how many items to show (say: 10, 25, 50, 100) on a page, only the active selection matters for quick information, and if one wants to edit it, one ought to use a drop down menu, as is used in Figure 1.

Really, they should only be used in the following scenarios:

  • Mutually exclusive options distinct of one another. While boolean operations are mutually exclusive, they are better served by a checkbox, unless a checkbox cannot adequately differenciate the options clearly.
  • There are a small number (perhaps 3 - 6) of options which are mutually exclusive, and it is important to be able to see all of the options, all of the time. This happens less often than you’d think. If it’s not a prominent control, being used regularly, it’s often cleaner and easier for the user if you put it in a drop down.
Figure 1: Gmail’s ‘General Settings’ tab. A mismatch of well done and incorrectly used radio buttons.

Take a look at the above image (Figure 1) and try to work out which of the radio buttons really should be radio buttons. I see 3 that should be radio buttons, with the rest better suited to a different control.

Take the first instance of radio buttons in Figure 1, ‘Right-to-left editing’. Why shouldn’t it be a checkbox with the label ‘Enable Right-to-left editing support’, which would be consistent with the above ‘Enable input tools’ checkbox. Or how about the choice of ‘Always use https’ or ‘Don’t always use https’? How about a checkbox for ‘Always use https’? The same, again, for ‘Show Send & Archive button in reply’.

“With radio buttons we can clearly spell something out, leaving nothing to the imagination of the user.”

On the other hand, ‘Always display external images’ and ‘Ask before displaying external images’ are useful as separate options. If one had a checkbox who’s label was ‘Always display external images’ and you unchecked it, what would you expect? Certainly a large number of people would expect Gmail never to display external images, and likely no one would expect to be asked about displaying images later. This is a great case of the clarifying option that radio buttons give us, as designers. With radio buttons we can clearly spell something out, leaving nothing to the imagination of the user.

Figure 2: Display Options in OS X 10.9 on a Retina MacBook Pro

Here is an example of radio buttons used well. The options are mutually exclusive, but are not ‘yes/no’ operations. If it were a checkbox, what would ‘Not best for display’ look like? It wouldn’t be the same as ‘Scaled’ in most users’ mental model, I assure you.

Figure 3: Display Options in OS X 10.9 on a Retina MacBook Pro, having selected ‘Scaled’

This is a good example as well, because changing the option to ‘Scaled’ reveals more information (Figure 3), with options to change the resolution. This being hidden by, and subsequently only being activated by, the radio button means that the user isn’t likely to make any mistakes about the resolution without consiously choosing a scaled resolution, and then adjusting to a non-standard resolution. If they don’t like it? It’s easy to revert the error by changing the radio button selection.

In essence, radio buttons do still have a place in today’s designs, and, as a designer, you shouldn’t shy away from them if they’re the best option for displaying an option. They are, however, easy to misuse, and should only be used with care.

Friends don’t let friends misuse web elements.

Thomas Pritchard is a UX Designer from England, currently living in the midwestern United States. You should probably follow him on Twitter (@tpritc).

Want to weigh in on this? Why not discuss this post on Designer News?

--

--

Thomas Pritchard

British bloke who lives in Indianapolis, USA. Studying at @ButlerU & @PlymUni. I write awesome code and make pixels look fab.