Anatomy of a UI component: button, input, card and their states

A “Book now” button appears in a dozen places: the header, a service card, a form, a modal. If it is redrawn each time, a couple of months later the product has five slightly different blue buttons with different padding, radii and shades. Components solve this: the element is described once — parts, variants, states, usage rules — and then simply reused.

For a designer, a component is a main element in the file: in Figma it is literally called a component, and its copies on screens are instances. For a developer, it is code with parameters, such as <Button variant="primary" size="m">. The contract works when both sides use the same names: the same variants, the same states, the same property names. A set of components is a UI kit; a UI kit plus tokens, rules and documentation is a design system.

Anatomy means breaking a component into named parts. The names are not jargon for its own sake: when the spec says “in the error state only the container border changes”, the developer knows exactly which property to touch. Apple’s Human Interface Guidelines describe a button through three attributes: style (size, color, shape), content (icon, text or both) and role (the meaning of the action: primary, cancel, destructive).

Hit area is part of the anatomy too. Apple recommends a hit region of at least 44×44 pt for a button. WCAG 2.2 success criterion 2.5.8 (level AA) requires pointer targets to be at least 24×24 CSS pixels, with exceptions listed in the standard. The visible shape can be smaller; the clickable area cannot.

A variant is a predefined version of a component for actions of different importance. A button usually has three or four levels of prominence:

Apple recommends keeping prominent buttons to one or two per view: more accents mean more time spent choosing. The same guide adds a second rule: distinguish the preferred option by style, not size — buttons of different sizes side by side look inconsistent.

Sizes (S, M, L) change height, padding and font size, not meaning. Take them from the same spacing scale as the rest of the interface (the scale is covered in the visual hierarchy lesson). For the main action on a phone, pick a size whose hit area meets the platform recommendation.

A state is how a component looks and behaves at a given moment. For the user it answers the question “did it register?”. Nielsen Norman Group advises keeping feedback fast: focus and pressed states should appear within roughly 100–150 ms, otherwise people press again.

On focus. The :focus pseudo-class matches any focused element, while :focus-visible matches only when the browser decides focus should be shown: when tabbing with the keyboard — yes; when clicking a button with a mouse — usually not. This lets you give keyboard users a strong outline without distracting mouse users. Never remove the indicator entirely: MDN warns that doing so makes keyboard navigation inaccessible for sighted users.

On disabled. The browser handles the disabled attribute on a <button> itself: the button cannot be pressed and drops out of the Tab order. WCAG 1.4.11 exempts inactive components from the 3:1 contrast requirement, but the label still has to be readable. If an unavailable button must stay focusable, use aria-disabled="true" — then you block activation and style the state yourself.

Here is a small example: three button variants, a disabled button and a loading state. Save it as two files side by side and open it in a browser.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Button states</title>
  <link rel="stylesheet" href="button.css">
</head>
<body>
  <form id="booking">
    <button class="btn btn--primary" type="submit">Book now</button>
    <button class="btn btn--secondary" type="button">Call us</button>
    <button class="btn btn--ghost" type="button">Cancel</button>
    <button class="btn btn--primary" type="button" disabled>No slots available</button>
    <p id="status" role="status"></p>
  </form>

  <script>
    const form = document.getElementById("booking");
    const submit = form.querySelector('[type="submit"]');
    const status = document.getElementById("status");

    form.addEventListener("submit", async (event) => {
      event.preventDefault();
      if (submit.getAttribute("aria-busy") === "true") return; // already sending
      submit.setAttribute("aria-busy", "true");
      status.textContent = "Sending your request…";
      await new Promise((resolve) => setTimeout(resolve, 1500)); // stands in for a request
      submit.removeAttribute("aria-busy");
      status.textContent = "Request sent";
    });
  </script>
</body>
</html>

:root {
  --brand: #1d4ed8;
  --brand-hover: #1e40af;
  --brand-active: #1e3a8a;
  --brand-tint: #eff6ff;
  --on-brand: #ffffff;
  --muted-bg: #e5e7eb;
  --muted-text: #4b5563;
}

.btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 8px;
  min-height: 44px;
  padding: 0 20px;
  border: 1px solid transparent;
  border-radius: 10px;
  font: 600 16px/1.2 system-ui, sans-serif;
  cursor: pointer;
  transition: background-color 150ms ease-out, transform 100ms ease-out;
}

/* Variants: one component, different prominence */
.btn--primary { background: var(--brand); color: var(--on-brand); }
.btn--secondary { background: transparent; color: var(--brand); border-color: currentColor; }
.btn--ghost { background: transparent; color: var(--brand); }

/* Hover and active only for an available button */
.btn--primary:not(:disabled, [aria-busy="true"]):hover { background: var(--brand-hover); }
.btn--secondary:not(:disabled, [aria-busy="true"]):hover,
.btn--ghost:not(:disabled, [aria-busy="true"]):hover { background: var(--brand-tint); }
.btn--primary:not(:disabled, [aria-busy="true"]):active { background: var(--brand-active); }
.btn:not(:disabled, [aria-busy="true"]):active { transform: translateY(1px); }

/* Keyboard focus: outline at least 3:1 against the page */
.btn:focus-visible {
  outline: 3px solid var(--brand);
  outline-offset: 2px;
}

/* Disabled: muted, but the label stays readable */
.btn:disabled {
  background: var(--muted-bg);
  color: var(--muted-text);
  border-color: transparent;
  cursor: not-allowed;
}

/* Loading: the button keeps focus, the script ignores repeat presses */
.btn[aria-busy="true"] { cursor: progress; }
.btn[aria-busy="true"]::before {
  content: "";
  width: 16px;
  height: 16px;
  border: 2px solid currentColor;
  border-right-color: transparent;
  border-radius: 50%;
  animation: btn-spin 700ms linear infinite;
}

@keyframes btn-spin {
  to { transform: rotate(360deg); }
}

@media (prefers-reduced-motion: reduce) {
  .btn { transition: none; }
  .btn[aria-busy="true"]::before { animation-duration: 2s; }
}

The aria-busy="true" attribute tells assistive technologies that an element’s content is being updated; here it also serves as the styling hook for the spinner. It announces nothing by itself: the result is read out by the role="status" region, whose text screen readers announce without moving focus.

We ran these steps automatically in Microsoft Edge 155 with Playwright: every state switches correctly, label-to-background contrast stays at 4.5:1 or higher in every state including disabled, and the focus outline against the white page is 6.7:1.

An input consists of a label, the field itself, a hint below it and a slot for an error message. The most common mockup mistake is dropping the label and leaving only grey text inside the field — the placeholder. Nielsen Norman Group explains why that hurts:

• the text disappears as soon as typing starts, so people have to remember what the field was for
• a filled-in form is hard to review before submitting because the labels are gone
• grey text has poor contrast, and some screen readers don’t announce it
• people mistake the hint for a value that is already filled in and skip the field

Nielsen Norman Group’s conclusion: put the label and any essential hint outside the field. A placeholder is fine as a format example (“+1 555 000 0000”), but not instead of a label.

Nielsen Norman Group defines a card as a container for a few short, related pieces of information — a brief representation of an item that links to more detail. Typical parts: an image, a title, a short description, meta (date, price, tags) and sometimes a secondary action.

Most often the whole card leads to the item page: a large hit area is easier to use on a phone and with a mouse. But cards also contain their own buttons — “Save”, “Share”. You can’t wrap the whole card in an <a> and put a button inside: HTML forbids interactive elements inside a link. The working technique is to make the title the link and stretch its hit area over the card with CSS; secondary buttons sit above that layer.

A card has the same states as a button plus a few of its own: hover (a shadow or lift), focus-visible, selected — when cards are chosen, like pricing plans — and loading, when a skeleton temporarily takes its place. Nielsen Norman Group also points out a limit: cards work well for browsing mixed content but poorly when options must be compared — a list or table is better there.

A spec is a short document or a page in the design file that holds everything needed to build the component. In our experience it saves the most time in review: questions like “what does this look like on error?” get answered before the code, not after.