skip to content

In a design-system component library offering both primitives and prebuilt recipes, which should a product team reach for first, and why?

level: juniorimportance: should knowfreq 35%

answer

  1. decisions already made
  2. edge cases already handled
  3. upgrades flow in for free
  4. compose, never restyle internals
  5. tell the system team

basics

~20 s

Reach for the prebuilt recipe first: it encodes the approved layout, behaviour and edge cases for a common need and picks up fixes automatically. Drop to primitives only when no recipe fits, and compose them rather than restyling a recipe's internals.

solid answer

~40 s

**Primitives** are the small building blocks — layout stacks, text, media, buttons, behaviour-only parts. **Recipes** are ready-made compositions of them for common needs, such as a newsletter sign-up block or an author bio. On a news publisher's article page, I would use the newsletter recipe first: its layout, validation messages, spacing and accessibility are already decided and tested, and fixes arrive with each library update. Only if no recipe fits — say, a new live-election results strip — would I compose primitives, and I would tell the system team, because a need several teams share should become a recipe. What I would not do is copy a recipe's source into my app or override its internal styling: both break silently when the library changes.

go deeper

for a junior

Remember the rule: recipe first, primitives when nothing fits, and never copy or restyle a recipe's internals.

for a middle

Explain what a recipe carries — decisions, edge cases, accessibility, upgrades — and why a copy or an override breaks when the library changes.

for a senior

Spot compositions that several teams are rebuilding and push them into the library as recipes through the contribution process.

for a principal

Balance the recipe catalogue: too few recipes and every team becomes a design-system team, too many and the library turns into a set of one-off layouts nobody can maintain.

## Two kinds of building block A design-system component library often ships two levels of building block: - **Primitives** — small, general pieces with one job: a layout stack or grid, text with the system's type styles, a media frame, a button, and behaviour-only parts such as a disclosure. - **Recipes** — ready-made compositions of primitives for a recurring need: a newsletter sign-up block, an author bio, a story teaser, a related-articles list. | | Primitives | Recipes | |---|---|---| | Scope | one job each | one common need, end to end | | Decisions left to you | many: layout, spacing, order | few: content and a small set of options | | Edge cases | yours to handle | handled and tested by the system team | | Updates | pieces update, your composition does not | the whole recipe improves with each release | ## Why a recipe comes first On a news publisher's article page, a product team needs a newsletter sign-up at the foot of the story. The library has a recipe for it. Using it gives the team: 1. **Decisions already made** — layout, spacing, the order of heading, pitch, field and button, and how it collapses on a small screen. 2. **Edge cases already handled** — long newsletter names, error and success messages, what happens when the reader is already subscribed, right-to-left text. 3. **Accessibility already checked** — labels, focus order, announcements for success and error. 4. **Upgrades for free** — when the system team fixes a bug or refreshes the design, every page using the recipe improves on the next update. 5. **Consistency** — the sign-up looks and behaves the same on every article, which readers learn once. Building the same block from primitives repeats all those decisions, usually less thoroughly. ## When primitives are the right call - **No recipe fits** — a new live-election results strip has no precedent in the library. - **A genuinely one-off surface** — a special investigation page with bespoke layout. - **The system team building new recipes** — recipes themselves are compositions of primitives. When a team composes primitives for a need that is likely to recur, it should **tell the system team**. If several teams build the same composition, that is the signal for a new recipe; the contribution process decides how it gets in. ## What to avoid - **Copying a recipe's source into the app** to tweak it. The copy no longer receives fixes and silently drifts from the original. - **Overriding a recipe's internal styling** from outside. Internal structure is not a promise; the next release may rename or restructure it, and the override breaks without warning. - **Rebuilding an existing recipe from primitives** because it seemed quicker. The team inherits every edge case the recipe already solved. If a recipe *almost* fits, the right move is to ask for an option on the recipe, or compose primitives openly — not to bend the recipe from outside. ## A quick decision path 1. **Is there a recipe for this need?** Use it, with the options it offers. 2. **Does a recipe almost fit?** Ask the system team for an option before working around it. 3. **Is the need new?** Compose primitives, following the system's layout and spacing rules. 4. **Will others need it too?** Propose it as a recipe so the next team starts from step 1. ## Why libraries ship both Primitives alone make every team a design-system team; recipes alone leave teams stuck when their need is new. Offering both — recipes for the common case, primitives for everything else — is what lets a library be consistent and flexible at once.

  • A recipe almost fits but needs one extra line of text; what should a product team do?
    Ask the system team whether the recipe should offer that option, since other teams may need it too, or compose primitives openly if the need is one-off. Overriding the recipe's internals or copying its source are the options to avoid, because both break silently when the library updates.
  • Why is copying a recipe's source into an app worse than it looks?
    The copy stops receiving fixes, design refreshes and accessibility improvements, so it drifts from every other use of the recipe. Nobody tracks the fork, and when the library changes the underlying primitives, the copy may break in ways the system team cannot see or test.

A ready-made bookcase versus the planks and screws it was built from: take the bookcase if it fits the room, build from planks when it truly does not, and never saw pieces off the bookcase to make it fit.

saying these in an interview costs you the question

  • Primitives are always better because they give full control
  • Copying a recipe's source is a safe way to customise it
  • Overriding a recipe's internal styles is fine because it works today
  • Recipes are only for junior developers who cannot compose primitives
  • A one-off composition never needs to be shared with the system team