XD Essentials: Radio Buttons and Checkboxes
When creating forms, designers are often faced with having to select a UI element that dictates the interaction of option selection. There are several different types of controls that allow the user to select options from a preset range: checkboxes, toggles, radio buttons, and drop-downs controls. In this article we’ll focus on radio buttons and checkboxes. Despite the fact that these controls are fairly simple, all too often they are broken in terms of interaction design.
Radio Buttons and Checkboxes
Radio buttons were named after the physical buttons used in old car radios to change the stations — when one of the buttons was pressed, other buttons would pop out, leaving the pressed button the only button in the “pushed in” position.
The UI element radio button was modeled after these physical radio buttons. They are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.
Checkboxes originate from paper forms. Whereas radio buttons are generally used for mutually exclusive options, a series of checkboxes are well suited for multiple option selection. They are used when there are lists of options and the user may select any number of choices, including zero, one, or several. In other words, each checkbox is independent of all other checkboxes in the list, so checking one box doesn’t uncheck the others.
A variation of checkboxes is the stand-alone checkbox, which is used for a binary yes/no choice.
Radio Buttons and Checkboxes Aren’t Intended to Act as Action Buttons
Checkboxes and radio buttons should only be used to change settings, not as action buttons. The changed settings should not take effect until the user clicks the command button. Requiring a button press allows users to review their settings before they commit. This helps prevent accidental activation errors. If the user clicks the Back or Cancel buttons, any changes made to radio buttons/checkbox on the page should be discarded and the original settings restored.
Use Standard Visual Representations
Radio buttons and checkboxes should conform to standard visual representation:
- Radio buttons should be presented as a small circle with a second circle inside when selected.
- Checkboxes should be visualised as a small square with some form of cross, tick, or check mark when selected.
- Checkboxes or radio buttons should have focus styles (focused, active, checked).
Image credits: Mono
Conforming to this will help to avoid user frustration when the UIs fails to behave as expected.
Present Options in a Logical Order
You should list the options in a logical order, such as most likely to be selected to least, simplest to most complex operation, or lowest to highest risk. Alphabetical ordering is not recommended because it is language dependent and therefore not localizable.
Lay Out Your List Vertically
List all options vertically instead of horizontally, because horizontal alignment is harder to read and localize.
If list items must be placed horizontally (which is occasionally necessary to reduce the overall length of the page), it is important that items are clearly spaced to reduce any confusion (it should be abundantly clear which choice goes with which label). Good horizontal radio buttons can be found in example below which was taken from the Duolingo app for iOS. Duolingo uses a classic horizontal radio buttons, but make the targets visually distinguishable and large enough for touch-enabled devices.
Use Label Tags as Click Targets
Let users select an option by clicking on either the button/box itself or its label. A bigger target is faster to click according to Fitts’s Law. In HTML forms, you can easily achieve this by coding each label with Elements.
Avoid nesting radio buttons with other radio buttons or checkboxes. You should keep all options at the same level to avoid confusion and prevent unnecessary screen clutter.
Recommendations for Radio Buttons
Keep Labels Brief
Labels tells users what the corresponding radio button means. Labelsare not help texts. You should use succinct and short, yet descriptive labels so users can quickly scan all available options:
- Limit the radio button’s text content to a single line.
- Write the label as a phrase, not as a sentence, and use no ending punctuation.
- Try to keep the length about the same for all labels.
Always Offer a Default Selection
One of the 10 heuristics of UI design says that users should be able to undo (and redo) their actions. This means enabling people to set a UI control back to its original state. In the case of radio buttons this means that there should always be exactly one option pre-selected. If none of the buttons is selected by default, users have no way to revert to this original state after they’ve made a selection. The lack of a standard can be confusing to users.
Tip: Select the safest and most secure option as default. If safety and security aren’t factors, select the most likely or convenient option.
Exceptions: Don’t have a default selection if the goal is to collect unbiased data (e.g. customer survey). Default values would bias data collection.
Ensure Options are Comprehensive and Clearly Distinct
If it’s impossible to be comprehensive, offer a button labeled “Other,” supplemented by a type-in field.
Use Radio Buttons Rather than Drop-Down Menus
If you only have a small number of options (between 2 and 7) in your list, you should consider using radio buttons instead of drop-down menus. Radio buttons have lower cognitive load because all options are permanently visible making it easy for users to easily compare them.
Help Users Find the Right Option
Assist the Person: If an option is strongly recommended, add “(recommended)” to the label. If an option is intended only for advanced users, add “(advanced)” to the label.
Radios Buttons on Mobile Apps — Yes or No?
It’s ok to use radio buttons on mobile apps, but be sure they are easy to tap. If you have only 2 or 3 available choices the solution below, called segmented control in Apple iOS, should work well.
Recommendations for checkboxes
Set to “Off” by Default
Leave checkboxes blank by default. Don’t tell users what they need, let them decide for themselves.
Make Checkbox Labels Obvious
The biggest usability problems for checkboxes come from vague or misleading labels. Users should be able to easily understand the consequences of checking and unchecking a checkbox. Thus, write checkbox labels so users know both what will happen if they check a particular box, and what will happen if they leave it blank.
- Avoid negations such as “Don’t send me notifications,” which would mean that the user would have to check the box in order for something not to happen.
It should be clear what will happen if the user turns on the checkbox.
- When possible, use positive and active wording. Word the checkbox label as a statement that the check mark makes true, and the absence of a check mark makes false.
Use Checkboxes for a Single Binary Choice
Don’t use two radio buttons for a single binary choice. If there are only two mutually exclusive options, combine them into a single checkbox.
Don’t Use a Checkbox as an Action Button
A c_heckbox is for status_, not for action. In the example below, it’s clear with the toggle switch that the wireless is set to “On.” But with a checkbox, the user needs to think about whether the wireless is on now or whether they need to check the box to turn wireless on.
In order to make interactions unambiguous it’s important not only to use a right control, but also to provide clear visual feedback for the user who interacts with it. It’s especially important for mobile apps where UI controls should appear tangible, even though they are behind a layer of glass.
As you just saw there are a lot of considerations that should be taken into account when selecting selectors. When designing your interface, try to be consistent and predictable in your choice of interface elements. Following design standards enhances a user’s ability to predict what a control does and how they should use it.