Lego, not photocopies – What composable actually means – The System – Decisions made once, used everywhere

This course starts with a correction, because one wrong model here quietly bends every component decision downstream. The word is composable, and the tempting reading is “portable” – a component you can copy-paste into any project. That reading feels right, it’s common in real teams, and it’s wrong in a way that matters.

Think of Lego. A single 2×4 brick isn’t valuable because you can hand it to a friend and it’s still a brick – though it is. It’s valuable because it snaps onto other bricks to build something neither brick could be alone. That snapping-together capability is composability. A wheel-brick, a window-brick and a flat-brick combine predictably into a car, a house, anything – because they share a connection interface, not because any one brick is impressive on its own.

The five levels of snapping together

The canonical framework is Brad Frost’s atomic design (2013, still the standard reference), which borrows chemistry on purpose. Atoms are the smallest indivisible pieces – a label, an input, a button; in Frost’s words, they “serve as the foundational building blocks that comprise all our user interfaces.” Molecules are atoms bonded into a simple working unit – label + search input + button become a search form, something none of the three could do alone. Organisms are molecules and atoms nested into full interface sections (a site header: logo atom, search molecule, nav links). Templates arrange organisms into a page skeleton; pages pour in the real content.

And it isn’t a one-way assembly line. Frost again: “The parts of our designs influence the whole, and the whole influences the parts” – composition is an iterative, two-way relationship, not a packaging step at the end.

Reference, not copy – the mechanism that makes it matter

Here’s the part that separates the right model from the tempting one. When a search form is composed from a button, it doesn’t contain a duplicate of the button – it holds a reference to it, the way a spreadsheet formula points at a cell instead of retyping the number. Change the button once and every molecule and organism built on it updates automatically, because nothing was ever copied.

Feel the difference rather than take it on trust:

Change the atom, watch what happens downstream

One Button atom. Everything on the right is built from it – the question is how.

Atom

Button

edits so far: 0

Built from it

Molecule – search form

Organism – header

One edit, every composition followed – nothing was re-copied, because nothing was ever copied.

How were the compositions built?

Edit the atom's accent

In the references world every composition holds a pointer to the atom, so one edit propagates everywhere – that relationship is composability, and it's the same mechanism tokens use for values. In the copies world each composition owns a duplicate, so every atom edit leaves the duplicates one change further behind, and "update the design" quietly becomes a manual find-and-replace across every screen. Portability – handing the atom to another project – is a side-effect of building it cleanly; the snapping-together is the point.

If composable meant “copy-paste portable”, a design system’s value would just be “components I can drag into a new project”. That’s a component library – a genuinely smaller and less valuable thing than a design system, and the difference is exactly the reference relationships you just watched. Portability is real, and it’s a side-effect: a well-composed atom probably is easier to reuse elsewhere, precisely because it was built with a clean, minimal interface. But the ease of reuse is downstream of good composition, not what the word means.

One boundary to draw before the course builds upward: a design system is also not the brand. Brand guidelines are the upstream “who we are” – rules; the system is the downstream “how we build it at scale” – tools. You already hold this distinction (the placement quiz confirmed it), so this course sharpens it rather than teaches it – the Aesop case study on the course landing page is the cleanest version in the wild: a world-class identity carried almost entirely by rules, with barely a component library in sight.

The correct model, running in production at scale, is Notion – where a paragraph, a to-do and a database row are all the same nestable primitive:

Case studyNotionEverything is a block – one primitive that nests into pages, databases and everything between. Flexibility as an architecture decision, priced honestly.The block model is composability running in production – combination and nesting, not copy-paste – and its costs are the half of the lesson most products skip.

“intuitive and user friendly… but takes away too much functionality for form.”
– you, in the placement quiz

Notion’s foundational decision: everything is a block. A paragraph, a to-do, an image and a full database row are the same underlying primitive, composable and nestable inside each other – which is why a “document” and a “database” aren’t structurally different kinds of thing there the way they are in most tools, and why users can blend them freely. This is composability in the exact sense this course corrects: the power isn’t that a block can be copied somewhere else, it’s that blocks combine and nest into structures no single block could be – Lego, not photocopies.

The flexibility is made discoverable by a single consistent trigger: typing / surfaces every block type available at that exact spot, so “what can I insert here” is always one keystroke away rather than living in separate toolbars for text, tables and embeds.

And the critique deserves centre stage, not a footnote, because it’s a real, well-evidenced tension rather than personal taste: the same block-based generality that makes Notion flexible makes genuinely common tasks – formatting a long-form report, say – comparatively laborious, and the power-user layer (relations, rollups, formulas) is reported to take teams roughly two weeks of daily use to become fluent in. Every unit of generality that enables a novel use case adds a small amount of friction to the common one. Flexibility is real, and it is never free – a trade-off every design-system decision eventually meets at smaller scale.

The moves, named – follow one into the glossary:

Blocks nesting into blocks
The data model is the design
Discoverability through one trigger – the slash menu
Flexibility priced in everyday friction

Recap

Composable = pieces combine and nest into things neither could be alone, through references – Lego, not photocopies.
Atoms bond into molecules, molecules into organisms – and influence runs both ways, per Frost.
Reference-not-copy is the mechanism: change the atom once, everything built from it follows. A pile of portable components is a library; the relationships make it a system.
Portability is a side-effect of clean composition – nice to have, wrong as a definition.

Terms you now owncomposabilityatomic designdesign system

In a review “Is this actually composed – will a change to the base piece propagate – or are these copies that will drift?”

To an agent “Build this as composed components – small pieces referenced into bigger ones, so changing an atom updates every molecule that uses it. No duplicated markup between them.”

This page practises it:The demo is built from one Button atom referenced twice – edit it under "copies" and under "references" and the drift you watch is the exact difference this lesson names.