Common Components
Dropdowns, steppers, pagination, drawers—know the full set before choosing one.
Components are previous generations' fixed answers to common problems. Know them all and your job becomes picking from a few mature options instead of reinventing each time. The component catalog that decades of graphical interfaces have settled on is close to industry consensus—worth knowing before you start. gui-elements-wiki
What you'll run into:
- You describe the interface as "add a box" or "add a button," and what gets built isn't what you meant
- You pick the wrong component, users feel awkward operating it, and nobody can say why
- The same problem is solved by three different components in three places in your product
Know components by problem
| Problem to solve | Components to choose from |
|---|---|
| Pick one from a set | Radio buttons, dropdown, segmented control, selectable cards |
| Pick several from a set | Checkboxes, multi-select tags, transfer list |
| Enter content | Single-line input, multiline text, rich text, number stepper, date picker |
| Too much content to fit | Pagination, infinite scroll, accordion, tabs |
| Show a batch of data | List, table, card grid, timeline |
| Supplementary info without interrupting | Drawer, popover, tooltip, inline expand |
| Must interrupt | Modal dialog, full-screen confirmation |
| Tell the user a result | Toast, global banner, status tag, progress bar |
| Multi-step task | Stepper, wizard, segmented form |
| Finding something | Search box, filters, sorting, quick entries |
Remembering by problem beats remembering by name. The skill to build: look at a need and instantly say "this is a pick-one-from-a-set problem." And remember that a component library isn't better when it's bigger—know the full set first, then cut. Choosing is subtraction, not addition.
Easy to get wrong
- Dropdown or radio buttons. Under five options, use radio buttons—everything visible at a glance; over five, use a dropdown to save space. Over twenty, add search.
- Modal or drawer. If the user must decide now and the decision affects the main flow, use a modal. For supplementary information or a minor edit, use a drawer—it doesn't interrupt the context.
- Pagination or infinite scroll. If users need to locate precisely or return to a specific page, paginate. For casual browsing with no clear endpoint, use infinite scroll. Back-office systems should almost always paginate.
- Table or card. Many fields, comparison, sorting—use a table. Few fields, images, mobile—use cards. Tables are basically unusable on phones.
- Stepper or one page to the end. If steps depend on each other or fields exceed ten, use a stepper; otherwise one page fills faster.
Every component has states
A component isn't one static style—it's a set of states. Once you pick a component, work through default, hover, pressed, focus, disabled, and loading together with it. Inputs add two more: error and read-only. Lists add four: empty, loading, error, and populated.
Focus is the state most often missed, and it decides whether keyboard users can use your product at all. In AI-generated components, disabled and focus are the two most likely to be missing—add one explicit line about them in your prompt; it costs nothing.
How to check your choices. Screenshot every place in the product that uses the same kind of interaction and line them up: the same action using three different components across three pages is a signal to unify. Conversely, if one component shows up in two meanings—say, the same dialog for "close" and "delete"—split it into two, because users can't predict the consequence from the style alone.