skip to content

In a design system, which inputs should a ticket-search molecule of label, input and button atoms expose to callers, and which fix internally?

level: middleimportance: should knowfreq 40%

answer

  1. the molecule's public contract
  2. vary per use versus define the unit
  3. relationships stay inside
  4. name inputs by purpose, not atom
  5. required label and button name

basics

~20 s

Expose what legitimately varies between uses — label text, hint, current query, submit and change notifications, busy state, density — and forward each to the right atom. Fix the relationships that make it one unit: label names input, button submits.

solid answer

~50 s

A molecule's inputs are its public contract. I sort each atom input into three buckets: **exposed and forwarded** (label text, placeholder hint, the query value and its change and submit notifications, busy state, density), **fixed inside** (the label is the input's accessible name, the button submits the input's value, Enter submits too, order and spacing), and **not reachable** (atom colors and type the system already decided). I name exposed inputs by the molecule's purpose — a 'submit label', not 'the button's text' — so the atoms can change without breaking callers. The label and the icon button's text alternative are *required*: WCAG 2.2 3.3.2 and 4.1.2 (both Level A) expect labels and names, and a placeholder is only a last-resort fallback. Finally, one owner for the query value — the caller or the molecule, never both.

code

pseudocode · 19 lines
pseudocode
molecule TicketSearchField
  exposed:
    labelText: text          // required; may be visually hidden
    submitLabel: text        // required; accessible name of the button
    hint: text               // optional placeholder, never the name
    value: text              // owned by the caller
    onValueChange(text)
    onSubmit(text)
    busy: boolean
    density: compact | regular
  fixed inside:
    label.names(input)
    button.onActivate  -> onSubmit(input.value)
    input.onEnterKey   -> onSubmit(input.value)
    order, spacing     -> system defaults
  forwarded to atoms:
    label  <- labelText
    input  <- value, onValueChange, hint, density
    button <- submitLabel, busy, density

go deeper

for a junior

Recall that a molecule passes some settings through to its atoms and keeps the links between them fixed, and that its label is never optional.

for a middle

Explain the three buckets — exposed, fixed, unreachable — and why inputs are named by purpose. Cite why the label and the icon button's name are required.

for a senior

Show how you review a real molecule contract: spot re-exported atom inputs, overrides that bypass the theme, and ambiguous value ownership, and explain the breakage each causes.

for a principal

Discuss how contract strictness trades caller flexibility against consistency and accessibility guarantees, and how that choice shapes support load for the system team.

## The problem a molecule's inputs solve In **atomic design**, a **molecule** is a small group of atoms that works as one unit with one focused purpose. Take the ticket-search field in a customer-support ticketing tool: a label atom, a text-input atom and a button atom. Each atom already has its own inputs — the label takes text, the input takes a value and a size, the button takes a label, an icon and a busy state. When the three are combined, the molecule must decide which of those inputs its callers may set and which it sets itself. That decision is the molecule's **public contract**, whether it is written as a web component's attributes, a native view's parameters or a design editor component's exposed properties. ## Three buckets Sort every atom input into one of three buckets: | Bucket | What goes in it | Ticket-search examples | |---|---|---| | **Exposed and forwarded** | things that legitimately vary between uses of the same job | label text, placeholder hint, current query, change and submit notifications, busy state, density | | **Fixed inside** | the relationships that make the atoms one unit | label names the input; button submits the input's value; Enter in the input also submits; order and spacing | | **Not reachable** | atom styling the system has already decided | colors, corner radius, typography of each atom | The middle bucket is the molecule's reason to exist. If callers can remove the label-to-input association or wire the button to something other than submitting the query, the component is no longer a search field; it is three atoms in a box. ## Name inputs by purpose Expose inputs in the **molecule's vocabulary**, not the atoms'. A caller of a search field should set a 'submit label', not 'the button atom's text'. Naming by purpose does three things: - It hides which atom implements the behaviour, so the team can later swap an icon-only button for a text button without breaking callers. - It keeps the contract short. A molecule that re-exports every atom input wholesale ends up with dozens of settings, most of which are ways to break it. - It lets the same contract appear on every platform: a native mobile implementation and a web implementation can share the names even though their atoms differ internally. ## Required inputs that protect users Some inputs should be **required**, because the atoms cannot fill them in sensibly and leaving them empty harms users: 1. **A label for the field.** WCAG 2.2 success criterion 3.3.2 Labels or Instructions (Level A) asks for labels when content requires user input, and 4.1.2 Name, Role, Value (Level A) asks that every user interface component have a name that can be programmatically determined. The molecule can let callers hide the label visually in a crowded toolbar, but it should still demand the text and wire it as the input's accessible name. Placeholder text is not a substitute: the accessible-name rules treat it only as a last-resort fallback, and it disappears as soon as the agent types. 2. **A text alternative for an icon-only submit button.** A magnifier icon alone gives assistive technology nothing to announce, so the molecule should require a submit label and apply it as the button's accessible name. Making these required moves an accessibility rule from a review comment into the contract, where nobody can forget it. ## One owner for the value The molecule forwards the current query to the input atom, but someone must own that value. Either the **caller owns it** — passing it in and receiving change notifications — or the **molecule keeps its own draft** and reports only the submitted query. Both are defensible. What breaks is a molecule that accepts a value from outside **and** keeps its own copy, because the two drift and the field shows text that is not what gets searched. Pick one model per molecule and document it. ## Across platforms On the web the fixed label relationship is often expressed with a label element's `for` attribute pointing at the input; a native mobile platform expresses it by setting the text field's accessibility label. The mechanism differs; the molecule's contract — 'label text is required and becomes the field's name' — is the same, and that is the level a design system should specify. ## A review checklist - Does each exposed input vary legitimately between uses of the same job? - Could a caller use any exposed input to break the relationship between the atoms? - Are the field label and the button's accessible name required? - Is it written down who owns the current value? - Would the exposed names survive swapping one atom for another?

  • A product team needs the search button hidden on one screen and asks for a show-button switch; what do you do?
    Ask what job the screen needs. If search runs as the agent types and Enter still submits, the button's absence may be a legitimate variant of the same job, and a documented variant is fine. If they want a bare input with no submit relationship, that is a different component — the input atom with a label — not a switch that dismantles the molecule.
  • Why not let callers override the button's color through the molecule for a special campaign screen?
    Because color is the system's decision, made once in its tokens and atoms. A per-call override bypasses the theme, breaks when themes or modes change, and spreads inconsistency one exception at a time. If a real need exists, it becomes a named variant of the atom that every caller can use and that the theme can remap.
  • Should the molecule validate the query, for example reject empty searches?
    Only where the rule belongs to the search job everywhere, such as not submitting blank text. Rules that depend on the screen — minimum length for one index, permitted filters — belong to the caller, which the molecule notifies on submit. Putting screen rules inside makes the molecule less portable.

A molecule's contract is like a car's controls: the driver chooses the destination and the speed, but cannot rewire which key starts which engine. Callers set what varies; the wiring between the parts stays fixed.

saying these in an interview costs you the question

  • Expose every atom's inputs unchanged so callers keep full flexibility.
  • The label is optional whenever placeholder text is shown.
  • An icon-only button needs no text alternative because the icon is obvious.
  • Callers should be able to restyle atom colors through the molecule.
  • The molecule should keep its own copy of the value and also accept one from callers.