Use a choice component when a person should select from defined options rather than type an answer. Choice components can appear as radio buttons, checkboxes, a select list, autocomplete, action buttons or a button menu.

The presentation matters: the same list of options can be quick and clear in one format and difficult to use in another. Choose the format based on the number of options, whether more than one answer is allowed, and what happens after selection.

Select the right choice format

flowchart TD
  A[Define the decision] --> B{Can more than one answer be correct?}
  B -- Yes --> C[Use checkboxes]
  B -- No --> D{Does selecting an option perform an action?}
  D -- Yes --> E[Consider action buttons or a button menu]
  D -- No --> F{Are there many options?}
  F -- Yes --> G[Consider autocomplete]
  F -- No --> H[Use radio buttons]

Write options that are easy to compare

The component label should ask one clear question. Each choice should complete that question naturally and use parallel wording.

Good example:

How would you like us to contact you?

• Email
• Telephone
• Post

Avoid option labels that mix unrelated concepts, overlap, or hide an important distinction. Add hint text to an individual selection item when a short explanation will help a person choose correctly.

Each item has a visible label and a stored value. Use stable, meaningful values, especially when conditions, actions or integrations depend on them. Changing a stored value can break a journey even if the visible label has not changed.

Radios and checkboxes

Use radios for one answer and checkboxes for multiple answers. Do not use a checkbox to represent a yes-or-no choice unless it is genuinely an independent consent or acknowledgement; a two-option radio question is usually clearer.

For checkboxes, configure a minimum or maximum selected count only when the service rule requires it. Explain the rule in the label or hint, then test the boundary values.

Display choices vertically by default. Inline radio buttons can work for very short options that are easily scanned on smaller screens, but they become hard to read quickly. If the final option needs to be separated, a divider such as “or” can help, but use it only where it reflects a real alternative.

Autocomplete and dynamic options

Autocomplete is appropriate for a large, known list. Set the point at which matching suggestions appear carefully: showing matches immediately can help with a short list, while requiring a few characters can make a much larger list manageable.

Check the autocomplete behaviour for keyboard users as well as mouse users. Test an exact match, a partial match, no match, a pasted value, leaving the field while a match is highlighted, and returning to edit a saved answer.

Choice items can also come from a data feed, a list integration or a Liquid template. Dynamic choices require extra care:

• Make sure the source returns a consistent visible label and stable ID.
• Decide what should happen if an existing answer is no longer in the source list.
• Provide safe representative values in non-production environments where the live source is unavailable.
• Test no results, a changed source list, slow responses and an existing saved selection.

Do not generate a selection ID from volatile display text when a stable external identifier is available.

Reveal a follow-up question

A choice can reveal related components on the same page. Use this for a small, direct follow-up such as “If you selected Other, describe it”.

flowchart LR
  A[Choose contact method] --> B{Selected Other?}
  B -- Yes --> C[Reveal: describe another method]
  B -- No --> D[Keep follow-up hidden]

Keep the revealed content close to the choice and make it obviously related. For a full page or section that is only relevant to some people, use a page flow condition instead. See Revealing choice components for the dedicated pattern.

Buttons are actions, not ordinary answers

Choice buttons and button menus can submit the page and can replace the normal page continue control. Use them for explicit actions, route selection or workflow decisions—not for a standard questionnaire response.

Make every button label describe the result of selecting it, such as “Continue to payment” or “Save and return later”. When using more than one button, make the hierarchy and consequence clear. Test keyboard activation, error handling and what happens if the person returns to the page.

Pre-select and validate responsibly

You can pre-populate a choice based on earlier data. Do not pre-select an option that a person could reasonably interpret as their confirmed decision unless they can review and change it.

Use field-level conditional validation only when a rule determines whether a chosen answer is valid. It does not show or hide the component. For straightforward same-page follow-ups, use a reveal; for journey routing, use page conditions.

Final checks

• The label asks a single, answerable question.
• Options are mutually exclusive for radios and independently selectable for checkboxes.
• Stored values are stable and meaningful for downstream use.
• The selected display format suits the number and length of options.
• Autocomplete handles no results and keyboard interaction well.
• Dynamic options have safe fallback and change-management behaviour.
• Revealed content is directly related to the triggering option.
• Button choices describe their action and do not create an unexpected submission.

Related guidance

• Shared component settings
• Revealing choice components
• Use conditions and branching
• Selection item settings