In a design system shared by several airline product teams, which organisms belong in the shared library and which should stay in product code?
answer
- organisms carry domain assumptions
- same job in two products?
- stable structure versus experimenting
- shared molecules, local organisms
- promote on evidence, not hope
basics
~20 sShare 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.
solid answer
~40 sOrganisms are where a shared system starts to carry **domain assumptions**, so I would not ship them by default. I share an organism when several products need **the same job with the same structure**, and that structure is **stable**: the global header, footer, a generic filter panel or data table. Organisms that encode one product's domain or are still being experimented with — a seat map, the fare-family comparison — stay in product code, built from the shared atoms and molecules so they still look and behave like the system. A common heuristic is to promote once a second product needs the same job, with an interface inventory as evidence. Sharing too much makes the system team a bottleneck and spreads breaking changes; sharing too little leaves every team rebuilding headers slightly differently.
go deeper
Recall that organisms are big enough to carry product-specific knowledge, which is why not all of them belong in a shared library.
Explain the criteria — same job, stable structure, real consumers, an owner — and why local organisms should still be built from shared parts.
Show how you would decide for real candidates, run an inventory before promoting, and handle a domain organism the system team cannot own.
Weigh consistency and saved effort against coupling and bottlenecks, and when a domain pattern layer between system and products is worth its overhead.
## Why organisms are the contested level In **atomic design**, atoms and molecules are small and generic: a button, a label, a search field. **Organisms** are larger components that form distinct sections of an interface — a header, a results list, a seat map. The bigger a component gets, the more it knows about **one product's domain**: which fields a flight offer has, how cabins are arranged, which fare rules matter. That makes organisms the level where a shared design system has to decide deliberately what it owns. Picture an airline with three product teams: booking on web, the native mobile app, and the airport-kiosk check-in flow. All three build on one design system. ## A decision table | Candidate organism | Same job in several products? | Structure stable? | Domain-specific? | Where it lives | |---|---|---|---|---| | Global header with logo, navigation, account menu | yes | yes | no | shared library | | Generic filter panel | yes | yes | no, configured by the caller | shared library | | Flight summary | yes | mostly | yes, but common across all three | shared, with a domain-aware owner | | Seat map | kiosk and mobile only | changing with each aircraft rollout | yes | product code, promote later | | Fare-family comparison | web booking only | under A/B experiments | yes | product code | ## Criteria for sharing an organism Share it when most of these hold: - **The job is identical** across products, not just similar-looking. - **The structure is stable** — no weekly experiments changing what it contains. - **Two or more consumers exist today**, not hypothetically. - **Someone can own it.** A domain-aware organism needs an owner who understands the domain; if the system team cannot, a product team may own it inside the shared library under the system's rules. ## Why not share everything - **Domain coupling.** A shared seat map forces every consumer onto one data model for cabins and seats. - **Breaking changes ripple.** A change one product needs becomes a release every other product must absorb. - **Bottlenecks.** Product teams wait for the system team to change a section they alone use. - **Premature abstraction.** A component shaped around one product's needs grows switches for the second. ## Why not share nothing above molecules - **Inconsistency returns at the section level.** Three teams assemble three slightly different headers from the same molecules. - **Accessibility work repeats.** Landmarks, heading order and keyboard flow of a header are solved three times, sometimes differently. - **Duplicated effort** on sections that really are the same. ## A promotion path A common heuristic — not a rule — is to wait for the second real consumer: 1. The first product builds the organism in its own code **from shared atoms and molecules**, so it already looks like the system. 2. When another product needs the same job, run a quick **interface inventory** of both versions to confirm they are the same job. 3. **Generalise** only what differs for real, keeping domain mapping at the organism, and document the contract. 4. **Move** it into the shared library with a named owner, and have the first product switch to the shared version. Some organisations add a middle layer: a **domain pattern library** for airline-specific sections, owned jointly by the product teams, sitting between the generic system and product code. ## Common mistakes - Treating 'shared' as the goal, so every section is pushed into the library on day one. - Treating 'shared' as the system team's job alone, so domain organisms have no qualified owner. - Keeping everything local and accepting headers that differ in spacing, order and keyboard behaviour. - Promoting a component while it is still under experiment, then shipping breaking changes every week.
- The kiosk team built a seat map and the mobile team now wants one; what do you check before promoting it?Whether the job and the data are really the same: kiosk seat choice may add accessibility seating rules, touch sizes and time limits the app lacks. Inventory both needs, agree on one seat model, name an owner, and only then generalise. If the jobs differ, share the seat and legend molecules, not the organism.
- What does a middle domain-pattern layer cost?Another owner, another release stream and another place to look. It pays off when several products share one domain, such as flights, and the generic system cannot own domain decisions. It is overhead for a single product.
saying these in an interview costs you the question
- Every organism a product builds should go into the shared library at once.
- A design system should never ship anything larger than a molecule.
- Product teams may build local organisms from their own private atoms.
- One product using an organism is enough evidence to share it.
- Shared domain organisms need no owner who understands the domain.