QuestionsSystem Design

Design a shared component library

Component LibraryHardSystem Design

Design a component library adopted by multiple product teams. Apply RADIO; cover theming, versioning, a11y.

What it tests

Architecture at the org level — governance, DX, theming, and adoption. Your headline Domo achievement.

Approach & answer

Requirements: consistent UI across teams, themeable/brandable, accessible by default, great DX, backward-compatible releases. Architecture: design tokens (color/space/type as CSS variables) at the base; primitive components consume tokens; composite components build on primitives; ship as a versioned package. Data model: components are stateless/controlled where possible; tokens are the single source of truth for theming. Interface: minimal, composable prop APIs (composition over boolean explosion), TypeScript types as the contract, documented with Storybook. Optimizations & governance: WCAG-compliant primitives (keyboard, ARIA, contrast) so every team inherits a11y; tree-shakeable exports; semantic versioning + changelog + deprecation path; visual regression + unit tests in CI; a contribution/review process. The org-level win is that accessibility and consistency are solved once and inherited by all — exactly the duplication-cutting outcome you drove at Domo. Design tokens as the single source of truth: express color/space/type/radius as CSS custom properties so theming and white-labeling become a token swap, not a component fork — primitives read tokens, composites read primitives. DX is a first-class requirement: minimal composable prop APIs, TypeScript types as the enforced contract, and Storybook as living docs so teams discover components instead of rebuilding them. Governance is what makes adoption stick: WCAG-compliant primitives so every consumer inherits accessibility for free; semantic versioning with a changelog and a deprecation path (deprecate → warn → remove across releases) so upgrades don't break teams; visual-regression + unit tests in CI; and a lightweight contribution/review process so the library scales beyond its original authors.

Use this technique when

Design-system / platform prompts, and 'how would you cut duplicated UI across teams' questions.

Code

Design tokens (CSS vars: --color-primary, --space-2, --font-body)
        │  single source of truth for theming
        ▼
Primitives (Button, Input, Text)  ── stateless, controlled, WCAG built-in
        ▼
Composites (Modal, Card, DataTable) ── composed from primitives
        ▼
Package  ── TS types = contract · Storybook docs · tree-shakeable
        ── semver + changelog + deprecations · visual + unit tests in CI

References