The first section of a page: a headline, a sentence under it, and the one action you want taken. It is the only part of a page most visitors read.

In practice — A hero fails on the headline, not the layout. If the headline could appear on a competitor’s site with the logo swapped, the section is decoration. Split heroes want a product screenshot on the right; if you do not have one yet, centre it rather than filling the space with an illustration of nothing.

See also call to action, social proof

A features grid of deliberately unequal cells — one large, several small — named after the compartmented Japanese lunchbox.

In practice — The point is the asymmetry: the big cell is a claim that one feature matters more than the others. A bento grid where every tile is the same size is a card grid, and a bento grid where the big tile holds your fourth-best feature is worse than one. Pick the lead cell first, then fill in around it.

See also hero

Evidence that other people already decided you were fine — customer logos, user counts, ratings, testimonials — placed where a visitor is deciding whether to keep reading.

In practice — Position is the whole mechanism: proof goes immediately after a claim, because it is what buys attention for the next section. A logo strip works with six real logos and stops working at twenty, where it reads as a list of anyone who ever signed up. If you cannot name customers, count something true instead.

See also hero, carousel

The control that asks for the one thing the page exists to get — a signup, a purchase, a booked call — and the copy around it.

In practice — One per section, and the label says what happens next rather than what the button is: “Start free” beats “Submit”, and “Book a demo” beats “Learn more”, which asks for nothing. Two equally weighted buttons is not a choice, it is a delay — make one of them a quiet link.

See also hero, pricing table

The persistent frame an application lives inside — sidebar, top bar, content region — that stays put while the middle changes.

In practice — The shell is the thing that has to survive every route, so it is where responsive decisions get expensive: a sidebar that collapses to icons at one breakpoint and to a drawer at another is two layouts plus the state that remembers which. Decide the collapsed behaviour before you build any page that sits inside it.

See also navbar, drawer

The block at the bottom of every page carrying navigation, legal links and contact routes.

In practice — It is the only place every page links to every section, which makes it the site’s real map — for crawlers and for anyone who scrolled to the bottom because the nav did not have what they wanted. A footer with four links is a missed index; one with eighty columns is a sitemap someone forgot to edit.

See also navbar

The horizontal strip at the top of a page holding the logo, the primary destinations and usually one action.

In practice — Five or six items is the working limit — past that nobody reads it, they search. The logo goes left and links home; the one action goes right and is the only thing in the bar with a filled background. If the bar sticks on scroll, give it a background, because transparent sticky navs become unreadable the moment they cross an image.

See also mega menu, hamburger menu, footer

A navigation dropdown that opens into a full-width panel of grouped links rather than a single column.

In practice — Worth it only when you have enough destinations that grouping is information — a panel with six links in one column is a dropdown with extra steps. The cost is hover: a panel that opens on hover and closes the instant the pointer leaves the trigger is unusable, so either open on click or give the pointer a forgiving path between trigger and panel.

See also navbar

The three-line button that opens the navigation on narrow screens, usually into a panel that slides in from an edge.

In practice — It hides everything behind one tap, which is the right trade on a phone and a bad one on a desktop where the links would have fit. Whatever it opens has to trap focus and close on Escape, or a keyboard user tabs straight past the menu into the page behind it.

See also navbar, drawer

A single line of links showing the path from the site root to the current page.

In practice — It answers “where am I” and “how do I go up one level” — the second is the one people actually use, and it is why the browser back button is not a substitute for anyone who arrived from search. Only worth adding when the hierarchy is real; a breadcrumb on a flat site is a decoration that invents structure.

See also navbar, stepper

A row of labels where selecting one swaps the panel below it, with only one panel visible at a time.

In practice — Tabs are for content that is genuinely alternative — the same kind of thing, seen one at a time. They are the wrong control for a sequence (that is a stepper) and for content people need to compare, because comparison across a tab switch is done from memory. Anything you hide in a tab is invisible to a reader scanning the page and to anyone using find-in-page.

See also segmented control, accordion, stepper

Two to five adjacent buttons in one track where exactly one is selected — a radio group that looks like a switch.

In practice — Use it when the options are short, mutually exclusive, and worth showing all at once; past five segments the labels start truncating and it should be a select. The difference from tabs is scope: tabs swap a panel, a segmented control changes a setting that the surrounding view reacts to.

See also tabs, toggle

A keyboard-opened overlay that searches every destination and action in the product from one input.

In practice — It is the escape hatch that lets the rest of the navigation stay small — features that do not deserve a nav item live here. It earns its place only if it covers actions as well as pages; a palette that only navigates is a search box with a shortcut. Bind it to ⌘K and Ctrl+K both, and show the hint somewhere, because nobody discovers a shortcut by accident.

See also combobox, navbar

A numbered sequence of stages shown above a multi-step flow, marking what is done, what is current and what is left.

In practice — Its job is to bound the task: people abandon a long form because they cannot see the end of it, not because it is long. So show the real number of steps, never add one mid-flow, and let completed steps be clickable — a sequence you cannot walk back up is an interrogation.

See also tabs, progress bar, breadcrumb

One input together with everything attached to it: its label, its help text, its error message and the association between them.

In practice — The field is the unit, not the input — which is why a placeholder is not a label. Placeholders vanish the moment someone types, so the person checking their own work has nothing to check it against, and screen readers treat them inconsistently. Help text goes above the input where it can prevent the error; the error goes below, where it reports one.

See also inline validation, focus ring, input group

An input with fixed text or a control fused to one end — a currency symbol, a domain suffix, a unit, a button.

In practice — The affix is for the part of the value that is always the same, and it is worth the markup because it removes a whole class of error: nobody types the currency twice or forgets the protocol. Keep the affix out of the value you submit, and remember it is not a label — “https://” tells you the format, not what the field is for.

See also form field

A text input with a filtered list of suggestions under it, where typing narrows the list and a selection fills the input.

In practice — It is the control for a set too long to scroll and too fixed to free-type. The decisions that matter are all about the empty and losing cases: what shows before anyone types, what shows when nothing matches, and whether a value that is not in the list is allowed. Arrow keys must move through the options and Escape must close the list without clearing the input.

See also command palette, form field

A row of single-character boxes for a short code sent by SMS, email or an authenticator app.

In practice — Almost everyone arrives at this by pasting, so the first box must accept a whole code and distribute it — an implementation that only accepts one character per box is the single most common bug in this control. Set `autocomplete="one-time-code"` so phones offer the code from the notification, and never clear every box on a wrong code.

See also form field, inline validation

A calendar popover for choosing a date, usually paired with a text input that accepts a typed one.

In practice — Always keep the typed input. A calendar is faster for “next Thursday” and much slower for a birthday, and picking 1987 by clicking a month arrow is a punishment. The hard parts are not the grid: they are the time zone the date is stored in and what a range picker does when the second click lands before the first.

See also form field, popover

A bordered region that accepts files dropped onto it, and also opens a file browser when clicked.

In practice — Drag-and-drop is the affordance people notice and the one they use least — it does not exist on a phone and it is awkward on a laptop trackpad, so the click path has to be a real button, not a hint. State what you accept and how large before the upload fails, and show per-file progress rather than one bar for the batch.

See also progress bar, error state

A two-state control that turns something on or off, styled as a sliding knob in a track.

In practice — A toggle means the change takes effect now; a checkbox means it takes effect when the form is submitted. Mixing them is why a settings page feels unreliable. Label the thing being controlled, not the state — “Email notifications”, not “Enable email notifications”, which reads as off when it is on.

See also segmented control, form field

The visible outline a control gets when it holds keyboard focus, showing where the next keystroke will land.

In practice — It is the single most removed and least replaceable piece of interface on the web: `outline: none` with nothing after it makes a form impossible to fill in by keyboard. If the default is ugly, replace it — a ring with real contrast against both the control and the page — and use `:focus-visible` so it appears for keyboards without following the mouse around.

See also form field, inline validation

Error and success feedback shown next to the field it belongs to, rather than collected at the top on submit.

In practice — Timing is the entire design. Validating on every keystroke tells someone their email is invalid after one character; the rule that works is validate on blur, then re-validate on change once the field has already errored. Never signal state with colour alone — an icon or the message itself has to carry it too.

See also form field, error state, focus ring

A window over the page that blocks interaction with everything behind it until it is dismissed.

In practice — Modal means the rest of the app is unavailable, so it is justified by one of two things: a decision that cannot be deferred, or a destructive action worth confirming. Everything it needs must be inside it — a modal that sends you elsewhere to find a value has trapped you. Focus moves in on open, is trapped while open, Escape closes, and focus returns to whatever opened it.

See also scrim, drawer, popover

The translucent layer between an overlay and the page behind it, dimming and often blurring the content underneath.

In practice — It does two jobs — it says the page is unavailable, and it buys contrast for the panel on top of any content that happens to be behind it. Clicking it should dismiss anything cancellable and should not dismiss anything with unsaved input. Blur is expensive to composite; one scrim is fine, a scrim under an animated backdrop is a dropped frame.

See also modal, drawer

A panel that slides in from an edge of the screen and sits over the page, usually with the page still visible beside it.

In practice — The reason to reach for one over a modal is context: a drawer lets someone keep the list they came from on screen while working on one row of it. That only holds if the page behind stays legible — a drawer covering nine-tenths of the viewport is a modal with a slower animation. Same keyboard contract as a modal: trap focus, close on Escape, restore focus.

See also modal, scrim, hamburger menu, cart drawer

A small label that appears on hover or focus to name or explain the control it is attached to.

In practice — A tooltip is for a hint, never for information required to complete the task — it is invisible on touch, gone the moment the pointer moves, and unreachable if it only opens on hover. The classic misuse is the icon-only button whose meaning lives entirely in its tooltip; that button needs an accessible name regardless, and the tooltip should repeat it rather than be it.

See also popover

A positioned panel anchored to a trigger that can hold real content — text, controls, links — and stays open until dismissed.

In practice — The distinction from a tooltip is interactivity: if there is anything inside worth clicking, it is a popover and it must open on click, not hover. The hard part is positioning — it has to flip when it would run off the bottom of the viewport and shift when it would run off the side, which is why this is the one overlay usually worth a library.

See also tooltip, modal, date picker

A short message that appears in a corner after an action and dismisses itself.

In practice — Toasts are for confirmation, not for errors that need a decision — anything the person must act on will be missed, because a toast leaves on a timer and is off-screen from wherever they were looking. The best ones carry an Undo, which is how you replace a confirmation dialog with something people do not have to read. Stack them; never queue them one at a time.

See also modal, error state, badge

Grey shapes standing in for content that has not arrived, laid out in the same positions the real content will occupy.

In practice — It beats a spinner because it makes the wait feel shorter and stops the page jumping when data lands — but only if the shapes match the real layout. A skeleton of three rows that resolves into eight is worse than a blank space. Do not show one for a wait under about 200ms; the flash costs more than the wait did.

See also shimmer, spinner, empty state

The band of light that sweeps across a skeleton to show the wait is still progressing.

In practice — It is the difference between “loading” and “broken” — a static grey block reads as a rendering bug after a couple of seconds. It also runs forever by definition, so it belongs behind `prefers-reduced-motion` and should stop when the content arrives rather than fading under it.

See also skeleton, spinner

A small looping animation shown while an operation of unknown length is running.

In practice — Right for a button that is submitting, wrong for a page that is loading — a full-screen spinner tells you nothing and a skeleton tells you what is coming. A spinner inside a button must also disable it, or the form gets submitted three times. If the wait exceeds a few seconds, replace the spin with words about what is happening.

See also skeleton, progress bar

A bar that fills to show how much of a task is done, out of a known total.

In practice — Determinate only. If you do not know the total, you have a spinner, and a fake bar that sits at 90% is the reason people distrust all of them. A bar that can go backwards should say why. For a quantity rather than a task — storage used, quota remaining — the same shape is a meter, and it needs a threshold before it means anything.

See also spinner, stepper, sparkline

What a list, table or dashboard shows when it has no data — because it is new, or because a filter matched nothing.

In practice — Those two cases are different screens and get built as one, which is the usual bug: a first-run empty state should teach and offer the action that creates the first record, while a no-results empty state should show what was searched and offer to clear it. Neither is a shrug emoji. The first-run one is also the most-seen screen in the product and usually the least designed.

See also error state, data table, skeleton

What a region shows when its data failed to load or an action failed to complete, in place of the content.

In practice — Three things or it is not finished: what failed, whether it was their fault, and a way to try again without losing what they had typed. Scope it to the region that failed rather than replacing the whole page — one dead chart should not take the dashboard with it. Put the technical detail behind a disclosure, not in the headline.

See also empty state, toast, inline validation

A small coloured label carrying a status, a category or a count, attached to something else.

In practice — Badges are cheap to add and quietly expensive: once a row has four of them nothing stands out, which is the opposite of the point. Colour must never be the only signal — the word is the content, the colour is emphasis. A numeric badge needs a cap (“99+”) or it eventually breaks the layout that holds it.

See also chip, toast

Rows and columns of records with per-column sorting, and usually selection, filtering and row actions.

In practice — The table is easy; the surrounding contract is not. Sort, filter and page state should live in the URL so a view can be shared and survives a refresh. Keep the header visible when the body scrolls, right-align numbers so digits line up, and never put a destructive action in a row without a confirmation — mis-clicks in dense rows are constant.

See also pagination, empty state, kanban board

Splitting a long result set across numbered pages, with controls to move between them and a page-size choice.

In practice — Choose against infinite scroll deliberately: pagination gives a stable position, a reachable footer and a shareable URL, and infinite scroll gives none of those. Always show the total, or at least the current range — “Page 3” with no end in sight is a corridor. Offset paging drifts when rows are inserted mid-read; cursors do not.

See also data table

Records as cards in vertical columns, where the column is a status and moving a card between columns changes it.

In practice — It works when there are few statuses and the transition is the main verb; it collapses when any column holds hundreds of cards, because a board has no equivalent of sort. Drag has to have a keyboard path — move-to-column on the card menu is the usual answer — and the state should update optimistically, because the drop is meant to feel like the change.

See also data table, timeline

Events in time order down a vertical line, each with an actor, an action and a timestamp.

In practice — The unit of value is the entry, and the entry is a sentence: who did what to which thing. Group by day so the line does not read as one undifferentiated stream, show relative time with the absolute time on hover, and resist making every entry expandable — a feed where everything is collapsed is a list of nothing.

See also kanban board, reasoning trace

A tiny chart with no axes, sitting beside a number to show the trend behind it.

In practice — It answers one question — up or down, and roughly how steadily — so stripping the axes is the design rather than a shortcut. That also means it cannot carry a value anyone will read off it; pair it with the number and the change. Fix the baseline across a row of them or the shapes are not comparable, which is the only reason to put them in a row.

See also progress bar, data table

A stack of headings that expand to reveal their content, usually with one or several open at a time.

In practice — Right when the headings are scannable and most readers want one of them — an FAQ is the archetype. Wrong for content everybody has to read, which it makes longer rather than shorter. Build it on `<details>` where you can: it is keyboard-operable and findable by the browser’s own find-in-page for free, which a div-based one is not.

See also tabs, carousel

A horizontal track of items showing a few at a time, advanced by arrows, dots, swipe or a timer.

In practice — Almost nobody sees slide two, which makes a carousel a good way to show that more exists and a bad way to show anything important — never put a single key message on a rotating slide. Auto-advance is the part to drop first: it moves content out from under a reader and is a `prefers-reduced-motion` problem. Let the track be a real scroll container so touch and trackpads work without any script.

See also social proof, marquee

Several profile images overlapped in a row, usually ending in a count of the ones not shown.

In practice — It compresses “who is involved” into about the width of two avatars, and the overflow count is doing most of the work — show three or four faces, then “+12”. Every avatar still needs a name available on hover and to a screen reader, or the row announces as a series of images.

See also badge, chip

A small removable element representing one selected value — a filter, a recipient, a label — usually with an ✕ on it.

In practice — The difference from a badge is agency: a badge is read, a chip is removed. So a chip needs a real button inside it with a name that says what it removes, and Backspace should delete the last one when the cursor is in the input beside it. A row of chips is also the clearest way to show which filters are currently applied.

See also badge, combobox

A surface treatment where a panel is translucent and blurs whatever is behind it, with a thin bright border to catch the edge.

In practice — It only reads as glass when there is something worth blurring behind it — over a flat background it is a grey box with a border. The two costs are real: text contrast depends on content you do not control, so it needs a tint under the blur, and `backdrop-filter` is recomposited every frame, which is why a page of frosted cards scrolls badly.

See also scrim, gradient border

A border whose colour changes along its length, often animated so the gradient travels around the shape.

In practice — CSS has no gradient border property, so every version is a trick: a gradient background with an inset mask, or `border-image`, or a rotating conic gradient behind a solid inner panel. The mask approach is the one that keeps a rounded corner clean. Animated ones loop forever, so gate the animation on `prefers-reduced-motion`.

See also glow, glassmorphism

Coloured light spilling out from an element’s edges, made with layered shadows or a blurred copy behind it.

In practice — It reads as light only against a dark surface — on white it is a coloured smudge. Tint the glow from the element’s own colour rather than adding a second hue, and keep at most one glowing thing in view: glow is an emphasis mechanism, and two of them cancel out. A pulsing glow is an infinite animation and needs the same reduced-motion guard as everything else here.

See also gradient border, focus ring

Layers that move at different speeds as the page scrolls or the pointer moves, so the nearer ones appear to sit in front.

In practice — The effect depends entirely on restraint — a few percent of differential reads as depth, and more reads as the page fighting the scroll. Anything tied to scroll position has to be cheap to compute, so drive it with transforms rather than layout properties. It is also one of the most reliable triggers of motion sickness, which makes the reduced-motion path mandatory rather than polite.

See also marquee, glow

A row of content that slides continuously in one direction and loops, commonly used for logo strips and testimonials.

In practice — The loop is built by duplicating the content and translating by exactly half, so the seam never lands on screen — get that wrong by a pixel and it visibly stutters once per cycle. Fade both edges or items get sliced by the container. Pause on hover, and stop entirely under reduced motion: text that never stops moving cannot be read by everyone.

See also carousel, social proof

The panel on a product page holding price, variant choices, stock status and the add-to-cart button.

In practice — Everything needed to decide has to be inside it, because on a long product page it is the only part that stays in view — which is why it is usually sticky on desktop. Variant selection is the fragile part: changing a size must update price, stock and image together, and an unavailable combination should be visibly unavailable rather than silently missing.

See also cart drawer, pricing table

A panel that slides in to show the basket after something is added, without leaving the page.

In practice — It exists so adding a second item stays cheap — sending someone to a full cart page after every add is how a two-item order becomes a one-item order. Confirm what was added, show the running total, and offer both “keep shopping” and “checkout”. Open it on add; do not open it on hover.

See also drawer, buy box

Plans side by side, each with a price, a short list of what it includes and its own call to action.

In practice — Three tiers with one visibly recommended is the shape that works, because the middle is chosen relative to the other two. Show the price — a table of “Contact us” reads as expensive — and state the billing period next to the number rather than in a footnote. Feature lists should differ by what is added at each tier, not repeat the same eight rows with ticks.

See also comparison table, call to action

A grid of features against plans or products, showing which rows each column includes.

In practice — It is the second screen, not the first: people come to it having narrowed to two options and needing one difference settled. So order rows by how often they decide it, keep the header row and the first column pinned while scrolling, and let a tick have a tooltip — “Included” and “Included, up to 5 seats” are different answers.

See also pricing table, data table

The scrolling transcript of a conversation, alternating between the person’s messages and the model’s replies.

In practice — The scroll behaviour is the hard part: pin to the bottom while a reply is generating, and release the pin the instant the reader scrolls up, or reading an earlier message becomes impossible. Every assistant message needs copy, and the useful ones need regenerate and edit-and-resend, because the second attempt is where most of the value is.

See also streaming response, reasoning trace

Rendering a model’s answer as it arrives, token by token, instead of waiting for the complete reply.

In practice — It is a perceived-latency fix rather than a speed one — the answer takes the same total time, but the wait before anything appears drops to almost nothing. The cost is that you are rendering half-finished Markdown: an unclosed code fence or table has to degrade gracefully rather than flicker. Always give a visible stop control; a long wrong answer is worse than a short one.

See also chat thread, spinner

The model’s intermediate steps, shown separately from the answer — usually collapsed, and expandable when someone wants to check the work.

In practice — Collapsed by default is the whole design: the trace is there to be audited when the answer looks wrong, and shown inline it buries the answer. Label it as working rather than as fact, because it is neither guaranteed to be faithful nor something to quote. Streaming the trace live is the honest way to fill a long wait.

See also tool call, timeline, streaming response

A record of the model invoking something outside itself — a search, an API, a file read — with its arguments and what came back.

In practice — Show the name and the arguments before showing the result, because that is the order in which someone checks whether it did the right thing. Collapse the payload but keep it reachable, mark running, succeeded and failed distinctly, and treat a failed call as content rather than an error state — the model’s next move usually depends on having seen it.

See also reasoning trace, human in the loop

A reference from a generated sentence back to the source it came from, usually an inline marker that opens the passage.

In practice — The value is in being checkable, so the citation has to land on the specific passage rather than the document — a link to a 40-page PDF is decoration. Attach them to claims, not to paragraphs, and make an uncited claim visibly uncited. This is the main interface-level defence against a confident wrong answer.

See also reasoning trace, chip

A checkpoint where an agent stops and asks a person to approve an action before it takes effect.

In practice — The gate is only worth anything if the request is specific: “Allow this action?” gets approved reflexively, while “Delete 412 rows from `customers`?” does not. Show exactly what will happen, make rejection as easy as approval, and give the person somewhere to say why — and decide up front which actions are reversible enough not to need a gate at all, because a flow that asks about everything trains people to stop reading.

See also tool call, modal