In a design system for an online learning platform, how do you decide whether one team's lesson countdown timer stays local or joins the system?
answer
- one-offs are normal
- evidence of recurring need
- strip out the business logic
- settled design before a shared contract
- promote the generic core only
basics
~20 sKeep it local unless several teams need the same thing, it can be specified without one feature's business logic, and its design has settled; otherwise it stays a documented local component, built from system parts, that can be promoted later.
solid answer
~40 sI start from the view that one-offs are normal: the system should own **recurring** decisions, and a single-use component gains little from centralising while adding years of ownership cost. Then I ask whether other teams need a countdown, whether it can be specified without quiz-specific logic like auto-submit, whether its design has settled, and whether it fits the system's tokens and accessibility bar. Often the answer is a **split**: a generic countdown display with a configurable warning point joins the system, while auto-submit stays in the assessments code that composes it. If the evidence is not there yet, the timer stays local, built from system tokens and primitives so it is cheap to promote, with a recorded trigger to revisit when another team asks.
go deeper
Recall that a snowflake is a component built for one context, and that it is often right for it to stay in the product rather than in the shared system.
Explain the criteria: evidence of reuse, separable from business logic, a settled design, fit with the system's tokens and bar, and shared benefit that exceeds ownership cost.
Show the split move: promote the generic core, keep domain behaviour local, build snowflakes from system parts, and record a trigger for revisiting the decision.
Weigh promoting too early, an awkward shared API the system cannot shed, against promoting too late, duplicated and drifting implementations that cost more to consolidate.
## Snowflakes are not failures In design-system language, a **snowflake** (or one-off) is a component built for a single product context that the shared system does not provide. Snowflakes are normal. A design system exists to make **recurring** decisions once; a component that recurs nowhere else gains little from being centralised, and centralising it has real costs. The question is rarely 'how do we eliminate one-offs' but 'which one-offs have earned promotion'. Take an online learning platform where the assessments team built a **lesson countdown timer**: a ring that counts down the remaining time on a timed quiz, switches to a warning color in the last minute, and auto-submits at zero. Should it become a system component? ## The questions that decide Work through these roughly in order; a clear 'no' early on usually ends the discussion. 1. **Is there evidence of reuse?** Is anyone else building, or about to build, the same thing? A common heuristic, sometimes called the rule of three, is to wait until a pattern has appeared in about three places, because by then its real shape is visible. It is a heuristic, not a rule; two teams with a clear shared need may be enough. 2. **Can it be specified without one feature's business logic?** A system component must make sense to teams that know nothing about the originating feature. Auto-submitting a quiz is assessment logic; a countdown display with a warning threshold is not. 3. **Has the design settled?** A component still changing weekly in its home team will churn the system and every consumer with it. Let a pattern stabilise before freezing it into a shared contract. 4. **Does it fit the system's language?** It must be expressible with the system's tokens, states and naming, and be able to meet its accessibility and documentation bar. 5. **Is the ownership cost worth it?** Every system component needs design assets, code on each supported platform, documentation, tests and support for years. The shared benefit must exceed that cost. ## Applying it to the countdown timer | Signal | Points to staying local | Points to joining the system | |---|---|---| | Reuse | Only the assessments team uses it | Live-session and exam-scheduling teams need countdowns too | | Logic | Auto-submit and grading rules are baked in | A generic display taking a time value and a warning threshold | | Stability | The design changed twice this month | The design has held for several releases | | Fit | Uses raw colors and custom motion | Built from system tokens and motion guidelines | A frequent outcome is a **split**: the generic part, a countdown display with a configurable warning point, may be worth promoting, while the auto-submit behaviour stays in the assessments code that composes the system component. ## The middle options The choice is not binary: - **Local, but built from system parts.** The snowflake uses tokens and primitives, so it stays visually consistent and costs little to promote later. - **A documented pattern instead of a component.** The system publishes guidance or an example showing how to compose existing parts into the pattern, without owning new code. - **Extract only the generic core.** The system owns the reusable part; domain behaviour stays with the product team. - **Revisit on a trigger.** Record the decision and reopen it when a second or third team asks for the same thing. ## Mistakes in both directions Promoting too early produces a component shaped around one team's needs, whose options multiply as other teams try to bend it to theirs; the system then carries an awkward API it cannot easily change, because every change now reaches every consumer. Refusing too long produces three slightly different countdown timers, each with its own accessibility gaps and visual drift, and a later consolidation that costs more than an earlier extraction would have. The judgement is to promote when the evidence arrives, not when the first team asks. The urgency of the originating team is not evidence of shared need, and neither is the quality of its implementation: a beautifully built snowflake is still a snowflake if nobody else needs it. Conversely, two independent implementations of the same pattern are strong evidence, even if neither is ready to adopt wholesale. The same reasoning applies on every platform the system supports. A native mobile team's one-off is judged by the same questions, and a pattern that recurs on web but not on mobile may justify a system component on one platform and guidance only on the other.
- How do you keep a local snowflake cheap to promote later?Build it only from system tokens and primitives, follow the system's naming and state conventions, and keep domain logic outside the visual part. Promotion then means moving code and writing documentation, not a redesign. A snowflake built on raw values and custom styling has to be rebuilt before it can join the system.
- Two teams built similar countdown timers independently. What do you do?Treat it as evidence of shared need, not as proof that either version is right. Compare them to find the common core and the real differences, propose a generic component covering both, and plan how each team migrates. Adopting one team's version wholesale usually imports that team's assumptions into the system.
saying these in an interview costs you the question
- Every component that looks reusable should enter the system immediately.
- A one-off component always means the design system has failed.
- The system should accept a team's component to reward the contribution.
- Promote the timer with its auto-submit rule so other teams get it free.
- The requesting team's deadline is evidence that the component is shared.