Atomic Design

Bottom-up composition means larger interface parts are assembled from smaller ones: atoms into molecules, organisms, templates and finally pages. Frost stresses the levels are a lens for working on parts and whole at the same time, not five sequential steps.

A molecule is a small group of atoms working as one unit with one focused job. A ticket-search field qualifies because the combination links the parts: the label names the input and the button submits its query.

An organism is a relatively complex component, built from molecules, atoms or other organisms, that forms a distinct section of an interface. A flight-results list qualifies: one flight-option molecule repeated into a self-contained section of the booking screen.

A template is the layout skeleton that shows content structure; a page is one instance of it filled with real, representative content. Pages exist to show the final UI and to test whether the system's parts survive real content.

A template is a page-level skeleton that places organisms into a layout and shows the content structure, not the final content. A claim-detail template holds regions and placeholder shapes, never a real policyholder's claim.

An atom does one small job that usually only makes sense beside other elements: a label needs an input, an icon needs context. Alone, atoms serve as a reference for base styles and states, not as proof they work in context.

Usually not. A colour, type style or spacing value is a property that atoms use, not an interface element you can place and use. Keeping values separate from atoms stops the atom list filling with non-functional entries and keeps the indivisibility test meaningful.

Teams use renamed levels, three tiers such as foundations, components and patterns, ownership tiers, purpose groups, or plain component-driven practice with no level names. Choose by what the organisation most needs to communicate: scale, ownership or purpose.

Level boundaries are fuzzy and components drift between them, so level folders force classification debates, file moves that can break consumers, and poor discovery. Teams usually organise by component or purpose and keep the atomic words for design conversation.

Apply a written boundary test: does it split into atoms the system ships, does combining them add a new relationship, do callers vary the parts separately? A fixed icon-and-text signal is defensibly either; consistency matters more than purity.

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.

Common practice keeps molecules on display-ready values so they stay reusable, and lets the organism map domain objects such as flight offers onto them. A shared flight-results organism receives offers and reports selections; it does not fetch them.

Placeholder text has uniform lengths and no real data shapes, so it hides the breakage pages exist to find. Representative content mirrors production's formats and ranges, drawn from anonymised data, content designers and schemas, never raw customer records.

Build pages for the extremes real data produces: first use, heavy volume, shortest and longest strings, missing optional fields, partial failure, and each permission role. Each tests whether the template and its parts survive content they will actually meet.

It should specify what each region's content is made of: type, length range, count, image ratio, whether it is optional, and heading and landmark structure. Identical filler hides the long, empty and many-item cases that break real layouts.

Treat the level as a communication aid, not a fact to prove. Decide with a written heuristic on reuse, ownership and whether it forms a screen section, record the call, and keep labels out of names and paths.

It has become several components in one: its purpose needs 'and', its contract grew feature switches and unrelated teams edit it. Extract one focused molecule per job and compose them in a larger component that keeps the familiar layout.

Define the organism by its job — summarise one itinerary — and express genuine differences as a few meaningful variants such as density and action set, with layout adapting to available space. A context needing a different job gets its own organism.

Do not patch the pages. Fix the lowest level that owns the failing decision, usually the name cell's truncation rule; agree the content rule, document it, keep the long name as a permanent example, and recheck every page using it.

The template has absorbed business rules, so it cannot render with placeholders and changes whenever claim rules do. Let the template define regions and how an empty one collapses; the application decides which organism fills each region.

Share one template when the screens have the same skeleton — regions, order, roles and hierarchy — even if different organisms fill them. Give a screen its own template only when its structure differs, not merely its content.

The label was used as a badge rather than a granularity rule: compositions were promoted to atoms and properties were split into atoms. Re-run the indivisibility test, move compositions up, move properties into foundations, and record rulings for genuinely fuzzy cases.

Share organisms with the same stable job across products, such as a global header. Keep domain-specific or changing ones, like a seat map, in product code built from shared parts, and promote them when a second product needs the same job.