An airline's flight-summary organism must appear in search results, the seat-selection sidebar and the mobile trip list; how do you make it reusable without per-screen flags?
answer
- define it by its job, not its screen
- few named variants with meaning
- adapt to space, not to page
- different job means different organism
- document each context as an example
basics
~20 sDefine 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.
solid answer
~50 sFrost's product grid is reusable 'anywhere a group of products needs to be displayed', and that is the test: an organism is defined by its **job**, not its screen. Flags like 'is sidebar' or 'is trip list' leak screen knowledge into the component and multiply with every new screen. Instead I name the real axes of variation — **density** (full or compact), **actions** (select, change, none), **detail** (fare breakdown shown or not) — and let the internal layout respond to the **space it is given** rather than the page it is on. I document each context as an example in the component workshop. When a context needs a different job — the confirmation screen needs booking reference, passengers and baggage — I build a separate organism from the same molecules instead of adding flags until the summary does everything.
go deeper
Recall that an organism is reused wherever the same job is needed, like Frost's product grid appearing in several listings.
Explain why screen-named flags break reuse and how named axes such as density and actions express the real differences between contexts.
Show how you would audit an organism with growing flags, redesign its variation axes, adapt layout to available space, and split off contexts with a different job.
Discuss how variant policy for shared organisms balances product teams' speed against long-term consistency, and who approves new variation axes.
## The reuse promise of organisms In **atomic design**, an **organism** is a relatively complex component, composed of molecules, atoms or other organisms, that forms a distinct section of an interface. Brad Frost stresses reuse: his product-grid organism 'can be employed anywhere a group of products needs to be displayed, from category listings to search results to related products'. The promise holds only if the organism is defined by **what it does**, not by **where it is**. In an airline booking product, the **flight-summary organism** — outbound and return legs, times, stops, duration, fare class — is needed in three places: each item in search results, the sidebar during seat selection, and the trip list of the native mobile app. ## The anti-pattern: screen flags The tempting implementation adds one switch per screen: is-results, is-sidebar, is-trip-list. It fails in predictable ways: - **The organism learns the product's screens.** Every new screen means another flag and another code path. - **Combinations explode.** Two screens with overlapping needs set several flags at once, producing states nobody designed. - **Nobody else can reuse it.** A partner team cannot tell which flag gives them the look they need, because flag names describe places, not behaviour. - **Documentation rots.** The flag names describe screens that get renamed or removed. ## The alternative: named axes of variation Ask what actually differs between the contexts, and name those differences in the organism's own terms: | Axis | Values | Search results | Seat-selection sidebar | Mobile trip list | |---|---|---|---|---| | **Density** | full, compact | full | compact | compact | | **Actions** | select, change, none | select | change | none | | **Detail** | fare breakdown shown or hidden | hidden | shown | hidden | Each axis means something without knowing the screen, so a new screen picks values instead of adding code. Keep the axes few; if a fourth or fifth appears, check whether a second job has crept in. ## Adapt to space, not to page The sidebar and the trip list are narrow, the results column is wide. Rather than switching layout on the screen's identity, let the organism rearrange itself according to the **space its parent gives it** — stacking legs vertically below a certain width, for example. On the web that is often expressed with container-size rules, and on native mobile the parent passes its available width to the view; either way the organism stays ignorant of which page it is on, and a new placement with the same width behaves correctly without a change. ## When reuse is the wrong goal The booking-confirmation screen also shows flights, but its job is different: confirm what was bought, with booking reference, passenger names, seats and baggage. Stretching the flight summary to cover that requires detail axes nobody else uses. Better: 1. Keep the flight summary focused on summarising an itinerary. 2. Build a **booking-confirmation organism** that reuses the same leg and fare molecules and adds passenger and baggage molecules. 3. Share the molecules, not the organism, when the jobs differ. The signal is the same as at every level: if describing the organism's purpose now needs 'and', it has two jobs. ## Making reuse visible - Document each real context as a named example in the component workshop, with realistic content, so teams see the variants they may use. - Record which screens use which variant values; it tells the system team what a change will affect. - Review new variant requests against the axes: a new value on an existing axis is cheap, a new axis deserves discussion, a screen-named flag is rejected. ## Common mistakes - Adding a screen-named switch for each new placement. - Letting the organism read global page information to decide how to look. - Forcing every flight display, however different its job, into one organism. - Forking a copy per screen, which trades flag sprawl for drift between copies.
- A team asks for a 'hide price on the trip list' flag; is that a screen flag or a legitimate variant?Rephrase it without the screen. If it becomes 'show fare: yes or no' and other contexts could plausibly use it, it is a legitimate axis value. If it only makes sense as 'the trip list mode', it is a screen flag in disguise, and the trip list may deserve its own organism.
- Is forking a copy of the organism for one screen ever acceptable?Briefly, as an experiment a product team owns, with a plan to merge back or promote it as a separate organism. A permanent silent fork drifts from the original, misses fixes and accessibility improvements, and makes the system look reused while it is not.
saying these in an interview costs you the question
- A flag per screen is the simplest way to reuse an organism.
- The organism should read which page it is on to pick its layout.
- Every flight display should share one organism, whatever its job.
- Copying the organism per screen is safer than adding variants.
- Reuse means one component must look identical everywhere.