Design

A Dropdown lets users select an option from a list of choices that appears when they interact with a trigger. It helps keep interfaces clean by hiding secondary or large sets of options until needed, which makes it useful when space is limited or when the user needs to choose from a set of mutually exclusive actions or values. The component is fully responsive and intentionally designed to be used across all viewports.

Anatomy

Trigger
Chevron
List
Selected option

When to use it

Use the Dropdown when:

You need to offer 4–12 options without overwhelming the interface.
The selection doesn’t need to be immediately visible until the user interacts.
The user has to switch between predefined values or trigger an action.
Space is constrained and a compact UI is preferred.
You need to organise secondary actions tied to a primary object or context.

Avoid the Dropdown when:

The user needs to compare all options at once — consider radio buttons or a list.
The selection needs frequent or rapid access — a persistent UI element is better.
The action is a highly visible or critical CTA — use an explicit button.
The options include complex content like large images or long descriptions — use a menu or a select list instead.

Properties

State

Rested, Hover, Filled, Disabled, and Focus. The filled variant carries a subtle background so users can see at a glance which dropdowns hold a value; focus shows a 2 px outline so the trigger stays reachable from the keyboard.

Label

A persistent label sits above the trigger and names the selection. Keep it visible while the user interacts — placeholder-only labels fail when the user comes back to revise the form.

Helper text

Optional one-line helper text beneath the trigger. Use it to communicate constraints or examples (for example “Choose your preferred year”), not to repeat the label.

List

The list of options that opens beneath the trigger. Keep option labels short and scannable, and organise long lists alphabetically or by category to reduce cognitive load.

Chevron

The direction indicator inside the trigger. It points down when the list is closed and flips up while it is open.

Platform considerations

Desktop

The menu opens beneath the trigger and matches its width by default. Adapt the width to fit the longest option where clarity matters more than alignment.

Tablet

Same behaviour as desktop. Don’t auto-open on focus — it’s disorienting and doesn’t reflect typical usage patterns.

Mobile

The dropdown often promotes to the native picker on mobile. Keep the visible trigger tall enough for comfortable tapping and ensure clickability is clear without relying on hover.

Best practices

Treat the dropdown as a way to compress a known set of choices — not as a hiding place for important content.

Do

Keep option labels concise and easy to scan, organise long lists alphabetically or by category, use placeholder text that clearly indicates the expected action (“Select model” rather than “Choose”), pre-select an option only when there’s a strong default, keep terminology consistent across dropdowns in the product, and adapt the trigger width to fit the longest option when clarity matters.

Don't

Don’t overload the dropdown with too many items (a searchable dropdown fits very long lists), don’t mix unrelated content types inside the list, don’t use vague or repetitive labels like “Option 1” or “Item”, don’t rely on hover to indicate state on touch devices, don’t hide critical information inside a dropdown if it affects the user’s decision, and don’t auto-open on focus.

Content guidelines

Write option labels that stand on their own — users shouldn’t need surrounding context to understand them. Keep them short and scannable (one line wherever possible), use sentence case for readability, and make sure the wording is parallel across the menu (all nouns or all verbs). Use placeholder text that tells the user what kind of choice the dropdown holds (“Select model”), and reserve helper text for constraints or examples rather than restating the label.