As design-system lead for a game companion app whose web teams use three UI frameworks, how do you decide whether to support all three, standardise on one, or deliver framework-neutrally?
answer
- support multiplies every cost
- surface share and framework lifespan
- the cost of saying no
- tiers of support, not all or nothing
- entry, exit and review triggers
basics
~20 sWeigh each framework's share of product surface and lifespan against the multiplied cost of supporting it, and the cost of teams rebuilding components if you do not. Usually the answer is tiered support with explicit entry and exit criteria.
solid answer
~50 sStart from the fact that each supported framework multiplies releases, tests, documentation and support. Then gather the inputs: how much product surface and how many teams each framework carries, how long each is expected to live, whether pages render on the server or have no framework, and what the system team can staff. Also price the **cost of saying no**: unsupported teams rebuild components themselves, and their screens drift visually and regress on accessibility. The answer is rarely all or nothing. A **tiered model** works well: full idiomatic support for the dominant framework, framework-neutral elements (custom elements or a shared behaviour core) for the others, and tokens plus specs only for short-lived or leaving surfaces — with written entry and exit criteria and a review trigger, so the decision can move as the estate changes.
go deeper
Know that supporting another framework is a real cost to the system team, and that teams left unsupported tend to build their own components.
Name the options — one framework, all of them, a neutral core, tokens and specs only — and what each gives product teams.
Gather the inputs for a real estate: surface share, framework lifespan, rendering needs and team capacity, and show how they point to an answer.
Own the call: price both supporting and not supporting, propose tiers with written entry and exit criteria, and set triggers for reviewing the decision.
## The decision in front of you A multiplayer game's companion app has grown three web front ends: the **clan portal** on framework A (six teams, the core of the product), the **match-stats dashboard** on framework B (two teams from an acquired studio), and the **seasonal esports event site** on framework C (one team, rebuilt every season). The native mobile apps consume tokens and specs already. The system team has five engineers. Every framework you support fully adds a wrapper or renderer to build, a test matrix to run, examples and docs to maintain, and a support queue to answer. There is no single right answer; there is a defensible one for this estate. ## The options | Option | What product teams get | What it costs the system team | Main risk | |---|---|---|---| | **Support one framework only** | Full support on A; B and C on their own | Lowest | B and C rebuild components and diverge | | **Full support for all three** | Idiomatic components everywhere | Highest: three layers to build and keep aligned | Wrapper drift, slow releases | | **Framework-neutral core** (custom elements or a shared behaviour core) | One implementation, uneven ergonomics | Medium | Integration friction, teams wrapping it ad hoc | | **Tokens and specs only** for some frameworks | A consistent look, no shared code | Low | Behaviour and accessibility vary | ## The inputs that decide it - **Surface share and headcount**: what fraction of users and screens each framework carries. - **Expected lifespan**: is B being migrated to A? Is C rebuilt every season anyway? - **Rendering needs**: server-rendered pages and pages with no framework favour neutral delivery. - **System team capacity**: whether it can afford a second or third per-framework layer and keep it aligned. - **The cost of saying no**: unsupported teams do not stop building buttons; they build their own, and the product's visual language and accessibility diverge where the system does not reach. - **Organisational history**: an organisation that changes frameworks every few years gets more from a neutral core than one that has used the same framework for a decade. ## A tiered answer for this estate 1. **Tier 1 — framework A**: full idiomatic support, the fastest fixes, and all new components first. 2. **Tier 2 — framework B**: the same components delivered as framework-neutral elements, with a thin generated wrapper if B's teams need idiomatic inputs; fixes arrive in the same release as tier 1. 3. **Tier 3 — framework C**: tokens, specs and the neutral elements where they work, with no framework-specific code from the system team. Write the **entry and exit criteria** down: for example, a framework moves up a tier when it carries a stated share of product surface or teams, and moves down when a migration away from it is funded. Those thresholds are the organisation's to choose; the point is that they are explicit. ## Revisiting the decision - **Review on triggers, not on a calendar**: a framework crosses a tier threshold, a migration is funded or cancelled, support load for one tier grows faster than its surface. - **Measure** adoption per framework, the number of locally rebuilt components, and support requests per tier. - **Announce changes with a runway**: moving a framework down a tier is a change teams must plan for. ## The mistakes to avoid - **Supporting every framework by default**, which quietly turns the system team into three teams. - **Refusing all but one** and expecting other teams to migrate on the system team's schedule, which it does not control. - **Choosing the neutral core as ideology** without checking what integration friction the consuming frameworks actually face. - **Deciding once and never revisiting** as the estate changes. The judgment a lead is expected to show is not a favourite strategy, but a decision that names its inputs, prices both supporting and not supporting, and says in advance what would change it.
- How do you measure the cost of not supporting a framework?Count what teams on that framework build themselves: components re-implemented locally, visual deviations found in audits, accessibility defects in those components, and time spent maintaining them. Compare that with the estimated cost of a per-framework layer. When the local rebuilds add up to more than the layer would cost, the framework has earned a higher tier.
- What would make you standardise the organisation on one framework instead?When the system's cost is dominated by per-framework work, the minority frameworks carry little surface, and engineering leadership is willing to fund migrations. The design-system lead can make the case with data, but standardising is an organisational decision, so it needs sponsorship beyond the system team and a migration plan the product teams own.
saying these in an interview costs you the question
- A design system should support every framework any team chooses to use.
- Refusing support for a framework forces its teams to migrate quickly.
- Framework-neutral delivery is always the correct long-term choice.
- Support decisions are made once and never need revisiting.
- Not supporting a framework costs nothing, since those teams simply build alone.