A streaming startup with one TV app, one web app and two product teams wants a design system while still pivoting its product; would you build one now?
answer
- count the consumers
- is the product still changing shape
- what is actually being rebuilt twice
- lightweight shared foundations first
- name the trigger to revisit
basics
~20 sProbably not a full system yet: two teams, an unstable product and little proven duplication mean fixed costs outweigh reuse. Share lightweight foundations, such as a small token set, a design-editor library and conventions, and name the triggers for investing further.
solid answer
~40 sI would treat it as probably **premature**. The signs are few consumers (two teams), a product still changing shape, so components would be redesigned before they are reused, little evidence of the same parts being built twice, and no capacity to maintain a system as a product. Also, TV and web differ enough, for example remote-control focus navigation versus pointer and keyboard, that fewer components are shareable than the request assumes. Instead I would share the **cheap, stable layer**: a small set of named colour, type and spacing decisions, a shared library in the design editor, and conventions for naming and accessibility. Then I would name explicit **triggers** for a real investment: a third team, another TV platform, the same component rebuilt repeatedly, or a rebrand.
go deeper
Recall that a design system has fixed costs and that its value grows with the number of teams and platforms reusing it.
Explain which signs make a system premature, such as few consumers or an unstable product, and why shared decisions travel across platforms better than components.
Show how you would check the duplication claim with evidence, propose a lightweight shared layer, and set concrete triggers for a real investment.
Weigh the option value of starting early against the waste of building during a pivot, and decide what minimum shared layer keeps the future system cheap to start.
## What the question is really testing Interviewers ask this to see whether a candidate can say “not yet” to a popular idea and explain why, without dismissing the underlying need. A design system has **fixed costs** (a team, maintenance, documentation, migration) and **variable value** (reuse multiplied by consumers). When there are few consumers and the product keeps changing, the value side is small and unstable. ## Signs that a system is premature | Sign | Why it matters | In this startup | |---|---|---| | Few consumers | Reuse value multiplies per consumer; two is a small multiplier | Two product teams | | Unstable product | Components get redesigned before they are reused, so the build effort is wasted | Still pivoting | | Little proven duplication | Without repeated builds there is nothing to save | Unknown; must be checked | | No maintenance capacity | A system without upkeep decays and loses trust | Everyone is on product work | | Very different platforms | Fewer components can be shared | TV and web interaction models differ | | Unsettled brand | Visual decisions will change soon | Likely at this stage | Not every sign has to be present, but several together make a full system a poor bet. ## Why TV and web share less than expected A television app is driven by a remote control: users move focus between items with directional keys, read the screen from across a room, and rarely type. A web app is driven by pointer, touch and keyboard at close range. The two can share **decisions** such as colours, type choices, spacing steps, voice and iconography far more easily than they can share **components**, whose behaviour, sizing and focus model differ. A business case that assumes one component set for both overstates reuse. ## What to do instead A premature system is not an argument for doing nothing. The cheap, stable layer is worth sharing now: 1. **A small set of named design decisions** (colour, type, spacing) stored as data both apps read. These are cheap to create and cheap to change during a pivot. 2. **A shared library in the design editor**, so designers do not redraw the same tile twice. 3. **Conventions**: naming, accessibility baselines, content voice. 4. **Opportunistic sharing**: when both teams need the same thing, build it once in a shared place without promising it as a supported product. This costs little, keeps options open, and becomes the seed of a system later. ## Triggers to revisit Replace a vague “later” with named triggers, so the decision is revisited deliberately: - a third product team or another TV platform is funded; - the same component is rebuilt, or diverges, in two or more places; - a rebrand is planned; - an accessibility review finds the same defect repeated across apps; - onboarding new designers or engineers is slowed by inconsistent parts. ## Checking the duplication claim Before either building or declining, test the belief that effort is being duplicated. A few hours are enough for a first pass: - list the interface parts each app has built and mark the ones that exist in both; - note which of those behave the same way and which only look similar; - ask each team which parts they expect to build in the next few months; - check whether recent visual or accessibility fixes had to be made twice. If the overlap is small, the lightweight layer is the right answer. If it is already large, the case for a staffed system is stronger than the team size alone suggests, and the decision can change. ## Answering without sounding dismissive - Acknowledge the real pain behind the request, usually inconsistency or duplicated effort. - Separate the need (share decisions, avoid duplication) from the solution (a staffed, versioned system). - Propose the lightweight version and the triggers in the same breath. - Offer to check the duplication claim with evidence before either side commits. ## Common mistakes - Building a large component set before the product has settled, then rebuilding it after the pivot. - Assuming TV and web can share the same components one-to-one. - Saying “never” instead of “not yet, and here is when”. - Starting a system with nobody allocated to maintain it, which produces a stale library teams stop trusting.
- What would change your answer to building a system now?Evidence that reuse is already large or imminent: several more teams or platforms funded for the next months, the same parts clearly being rebuilt and diverging, a settled brand, or an accessibility problem repeating across apps. Any of those raises the value side enough to justify a small staffed effort, still starting with shared decisions and the few components most duplicated.
- Why share design decisions before components in this situation?Named decisions such as colours, type and spacing are cheap to create, cheap to change during a pivot, and shareable across very different platforms like TV and web. Components are expensive, encode interaction models that differ between those platforms, and are likely to be redesigned while the product is still moving. Decisions give most of the consistency benefit for a fraction of the cost.
saying these in an interview costs you the question
- Says every product should start with a full design system from day one.
- Assumes TV and web apps can share one component set unchanged.
- Rejects any sharing until the organisation is large.
- Plans a system with nobody allocated to maintain it.
- Defers the decision with no named trigger to revisit it.