Dropdown (UI)

A dropdown is a control that reveals a list of options on demand. The word covers two components that look similar and behave differently, and separating them resolves most of the confusion around the pattern.

A select chooses a value. It lives in a form, holds state, and its result gets submitted.

A menu triggers actions. It does not hold a value, and its items are verbs: Duplicate, Export, Delete.

Building one when you meant the other produces the familiar bugs: a menu that shows a checkmark next to the last thing you clicked, or a select that fires an action on hover.

Choosing between a dropdown and the alternatives

The judgement underneath the counts is whether somebody needs to compare the options. A list of five plan tiers should be visible, because choosing between them is the task. A list of five countries does not, because the person already knows which one they want.

Getting the details right

Order for finding, not for tidiness. Alphabetical is right when people know what they are looking for. Frequency order is right when they do not. A list of currencies with the three you actually serve at the top beats a strictly alphabetical list every time.

Say what is selected, always. A trigger that shows a placeholder after a choice has been made is a common bug and an easy one to miss in review.

Width that does not jump. A trigger sized to its current value resizes when the value changes, which moves everything next to it. Size for the longest option.

Search once the list is long. The threshold is lower than teams assume, somewhere around fifteen.

Never put actions in a select. A dropdown that navigates or deletes when a value is chosen removes the ability to change your mind.

The custom-component problem

Native <select> is unattractive and hard to style, so most products replace it. That decision costs more than it appears to.

The native element brings keyboard behaviour, mobile pickers, screen-reader announcement, type-ahead and correct behaviour at the edge of the viewport, all for free. A custom replacement has to implement arrow keys, Home and End, type-ahead matching, Escape to close, focus returning to the trigger, correct roles and states, and positioning that does not run off the screen.

Almost every accessibility failure in this component comes from a custom implementation missing part of that list. Start from a headless library that has solved the behaviour and apply your own styling on top. See component library.

In B2B interfaces

Long lists are the norm. Accounts, projects, users, categories. Search is not optional at enterprise data volumes, and a dropdown that was fine in a demo account with six entries is unusable in an account with nine hundred.

Multi-select needs a visible selection. Choosing twelve values and then being told "12 selected" hides whether the right twelve are chosen. Chips or a summary line that names them are worth the space.

Permissions filter the list. Options a person cannot use should generally be absent rather than present and disabled, unless knowing the capability exists is itself useful.

Grouping beats length. Section headings inside a long list do more for findability than sorting alone.

In practice

A project picker is a plain dropdown listing every project in the account, sorted alphabetically.

It works during the trial and stops working in production, where a real customer has four hundred projects. There is no search, so people scroll. The three projects anybody actually uses are scattered through the list. The trigger is sized to the current selection, so the toolbar reflows whenever a project with a longer name is chosen.

None of these are new features. Search, recent-first ordering with the full list below, and a fixed trigger width fix all of it, and each of the three problems only became visible against real data volume.

Where teams get it wrong

• A select that performs actions. A choice that fires immediately and cannot be reconsidered.
• Rebuilding native behaviour from scratch. Keyboard, mobile and screen-reader support quietly missing.
• No search past a long list. Scrolling as a search strategy.
• Alphabetical when frequency was needed. Tidy and slower to use.
• A trigger that resizes. The layout moves when the selection changes.
• An arbitrary default. Pre-selected values are accepted without thought and become wrong data.