UI Component

The same things keep reappearing while you design screens. There is a button on the document list, a button in settings, a button at checkout. It used to be that each one got drawn again from scratch: open the design file, draw a rectangle, round the corners, drop in a label. Engineering worked the same way, writing fresh button code on every screen.

With one designer and ten screens this causes no trouble. Copy the last screen, and if something drifts a little, ten screens side by side make it obvious. With three designers and a hundred screens the arrangement stops working. Each person remembers the button slightly differently, and there is nobody to ask which version is correct.

At Pagedeck the problem surfaced while building the delete-confirmation dialog. Noa opened the dialogs already in the product and found three of them, each closing differently. The sharing dialog closed on an outside click, the billing dialog responded only to the Escape key, and the invite dialog demanded the X in the corner. A customer had already written in about it, through Sofia: they clicked outside the dialog, nothing happened, and they assumed the app had frozen.

Theo had the same problem in a different shape. The three dialogs were three separate pieces of code, so making them close the same way meant editing three places. Ten dialogs later it would mean editing ten. None of the three shared a line of code, even though all three were a box, a title, a body and two buttons.

The root of it is having several copies of one thing. Copies drift apart eventually, and once they have, somebody has to decide which one everything else should match. A UI component collapses those copies back into one. Build the button properly once, and screens use it rather than redrawing it. Changing the corner radius becomes a single edit, and so does unifying how dialogs close. The saving is not mainly in build time; it is that the number of places a decision can go wrong drops from ten to one.

The frame that holds these pieces is the design system, which also contains values like color and type size along with documentation of when to use what. This page's term names the individual objects inside that frame — the ones that actually land on a screen.

The terms under UI component fall into six groups, and three questions sort them: what the user does (action, input), how something sits on top of the screen (layers, notifications), and what gets shown and in what arrangement (indicators, structure).

Action has exactly one member. A button is an element that runs something when pressed. One member does not mean one simple thing. A single button needs a resting look, a hover look, a pressed look, a disabled look, and a waiting-for-a-response look. Skip the last two and users press the same button twice, which saves the same document twice. A button that looks finished in a mockup is usually about a third of a button in practice.

Input is the group that collects values, and it has eight members. The first fork is whether people type freely or pick from a fixed set.

1. Text input — takes typed characters. Used for names, search terms, anything you cannot list in advance.
2. Select — pick one from a fixed list. It stays collapsed, so it costs little space.
3. Combobox — narrow the candidates by typing. Used when there are something like 200 options, such as country names, and typing three letters beats scrolling.
4. Checkbox — choose several at once, like turning on all three notification types.
5. Radio button — choose exactly one, for values such as a pricing plan where two cannot be true together.
6. Toggle — flips between on and off. Unlike a checkbox it applies the moment it is pressed, which suits settings screens that have no save button.
7. Slider — drag to a value inside a range. Best where the approximate position matters more than the exact number.
8. Date picker — choose a date on a calendar. Typed dates fall apart over whether 2026-09-16 or 16/09/2026 is meant, so this gets its own element.

Choosing among the pick-one elements usually comes down to count. Two or three options are faster laid out as radio buttons; past six or seven, collapsing them into a select is better; past a few dozen, a combobox with search. Twelve options as radio buttons means one question eating half the screen, and the next question on the page never gets read.

Layers are the group that floats above the existing screen, four members, sorted by how much they block.

1. Modal — dims the screen behind it and sits on top. It exists to stop everything else until the question is answered, so it belongs to irreversible decisions like deletion. The blocking is the cost, which is why it should be rare.
2. Drawer — slides in from an edge. Half the screen stays visible, which fits editing one record while looking at the list.
3. Popover — attaches to a specific element and opens small, like an account menu appearing under an avatar.
4. Tooltip — shows a short explanation on hover. Touch screens have no hover, so anything only a tooltip explains disappears entirely on mobile.

Notifications are the group where the product speaks first without being asked, three members, sorted by how long they stay.

1. Toast — appears for about three seconds and vanishes. For confirmations like "saved" that are fine to miss.
2. Snackbar — reports a result and offers a way back. It is the "Deleted · Undo" that appears right after a document disappears.
3. Banner — pins to the top of the screen and stays. For notices that require an action afterward, like a failed payment or scheduled maintenance.

One rule separates the three: anything costly to miss does not go in a notification that disappears. Announce an expired payment card through a toast and whoever was looking at another screen never sees the sentence at all.

Indicators are the group that reports state rather than inviting a press, four members. A badge attaches a count or status in miniature — the red dot saying three notifications are unread. A chip shows a selection or tag as a small pill and often carries which filters are currently applied. An avatar is the small image standing in for a person, so you can see who else is in a document. A progress indicator shows how far along something is; it looks different depending on whether the percentage is known, and anything that makes a user wait more than a second needs one, or they assume it stalled and reload.

Structure is the group about arranging and dividing information, six members. Tabs swap content in the same slot. An accordion folds content behind a heading you click, which suits material most people will not read. A card bundles related information into one box, useful for laying out a list as a grid. A table arranges data in rows and columns so values can be compared. Pagination splits a long list into pages, which matters once a list runs to thousands of rows and loading it in one go takes eight seconds. A stepper walks a person through ordered stages while showing which one they are on and how many remain, which is what keeps people from abandoning a five-screen setup flow on screen two.

The six groups are less a build order than the order of the questions you ask. Decide what the user should do and you are choosing from action and input; decide whether it belongs on top of the screen or inside it and you are choosing from layers and notifications; decide how results appear and you are choosing from indicators and structure. Whether these pieces actually work on a real screen also depends on accessibility, because whether a modal can be closed from the keyboard and whether a badge's red conveys a count to someone who cannot see red are both settled at the component level.

"Let's make this a drawer instead of a modal. People need the list behind it while they edit."

The task needs information from the screen underneath, so don't use a layer that blocks it entirely.

"Twelve options should be a select, not radio buttons."

Laying every option out takes too much room, so switch to something that collapses.

"This one's too important to miss. It should be a banner, not a toast."

A message that has to be read is sitting in a notification that disappears after a few seconds.

After the dialog episode, Pagedeck reversed its order of work. Noa now picks from existing pieces when starting a screen and only draws something new when nothing fits. The three dialogs became one that closes on both an outside click and the Escape key, and Theo left exactly one copy of it in the code. New dialogs since then swap out the contents and keep the shell.

Build speed was not the only thing that changed. Noa and Theo started using the same names. When a design file says "confirm modal," Theo can find that name in the code. Before, every rectangle in a mockup required asking which piece of code it corresponded to.

The first mistake is reading a component as a look. A design file contains only appearance, so that reading comes naturally. In practice most of a component lives in its rules: how it appears when disabled, whether long text wraps or truncates, what its minimum width is, what shows during the three seconds after a press while a response is pending. Mockups usually draw one case, the one that went well, so when the rules are unwritten the developer decides the rest alone. The same button then behaves differently on different screens, and the reason for having a component evaporates on the spot. The written rules are also what let a piece be reviewed at all — a look can only be agreed with or disliked, while a rule can be checked against a case.

The second is assuming more pieces make a better system. A large catalog looks like more to choose from. What actually grows is the cost of choosing. At thirty button variations a new hire cannot tell which one is correct, and someone who cannot tell ends up building a new one, making it thirty-one. When a library needs to grow, it is usually better to split a single piece by role and size than to add another piece. One button with primary, secondary and destructive roles in three sizes replaces a menu of thirty with two questions. It covers the same ground and leaves one place to edit when the shape of a button changes.