Design systems engineer system design interview questions

As asked

A product has years of hard-coded colours, spacing, and typography. How would you migrate it to design tokens without freezing feature work?

Sample answer outline

Define token layers clearly: primitive values, semantic tokens, and component-level decisions. Start with high-impact surfaces and introduce tokens alongside linting, codemods, visual regression tests, and documentation. Avoid a single big-bang rewrite; migrate by component or route and keep compatibility aliases during the transition. Partner with design so tokens reflect decisions, not just renamed hex values. The senior answer treats this as a change-management problem with adoption metrics and escape hatches, not merely a CSS refactor.

Expect these follow-ups

• How do you handle a brand refresh during the migration?
• What is the difference between a primitive and semantic token?
• How would you measure adoption and remaining debt?

As asked

You're building a design system for a SaaS company that white-labels its product for enterprise customers. Each customer can set their primary brand color, and the product must also support light and dark modes for each brand. Design the complete token architecture, from the data model to the delivery mechanism, for this scenario.

Sample answer outline

The architecture separates brand tokens (primary color, font family) from mode tokens (light/dark surface colors, text colors). At runtime, a customer-specific brand layer sets the brand tokens, and a mode layer sets contextual semantic tokens using the brand color as input. CSS custom properties work well for this because they cascade. The delivery mechanism requires a server-side rendering step or a CSS injection endpoint that computes a customer's full token set and serves it as a style block or a link to a dynamically generated CSS file. Caching by brand+mode key avoids recomputing on every request.

Expect these follow-ups

• How do you ensure that a brand's primary color, when used as a button background, always meets AA contrast against white text without requiring the customer to manually pick a dark enough color?
• How do you store and manage 1000 enterprise customer brand configurations at scale?

As asked

Design the full CI/CD pipeline for a design token system that takes JSON source files checked into git, runs platform-specific transformations, validates token names and values, and publishes outputs to npm and an internal CDN. Include the stages, validation gates, and rollback strategy.

Sample answer outline

Pipeline stages: lint (token name format, required metadata fields), transform (Style Dictionary runs for each platform), validate (contrast checks on color pairs, unit tests on output files), build (bundle JS module, CSS file, iOS Swift file, Android Kotlin file), publish (npm with changesets for versioning, CDN upload). Validation gates should run in parallel to reduce latency. Rollback: npm allows deprecating a version but not deleting it, so a hotfix publish is always the rollback mechanism. CDN rollback is faster via a latest pointer update. The candidate should mention semantic release or Changesets for automated versioning based on commit messages or changeset files.

Expect these follow-ups

• How do you handle a pipeline where design tokens are owned by a design team with no git experience?
• How would you structure the pipeline to support multiple simultaneous release branches, like a v2 stable and a v3 beta?

As asked

You're starting a new design system that will ship packages for React, Vue, Web Components, iOS (Swift), and Android (Kotlin), sharing a common token layer. Design the monorepo structure, toolchain choices, and package boundaries.

Sample answer outline

Top-level packages: tokens (JSON source + build scripts), icons (SVG sources + build scripts), primitives (headless behavior hooks, framework-agnostic), react (React wrappers using primitives), vue (Vue wrappers), web-components (LitElement wrappers), ios (Swift package, may live in a separate native repo), android (Kotlin module). Toolchain: Turborepo or Nx for task orchestration and caching, Changesets for coordinated versioning, ESBuild for JS builds, Style Dictionary for token compilation. The candidate should explain why ios and android might better live in separate native repos with the token output published there, rather than in the same monorepo.

Expect these follow-ups

• How do you share TypeScript types for shared data structures (like component variants) between the React and Vue packages?
• How do you prevent one team from accidentally bumping the token package and breaking all downstream packages without testing?

As asked

Design a system that runs automated accessibility audits on every component in a design system's Storybook across every story, reports results in CI, tracks regressions over time, and surfaces a per-component accessibility score to the documentation site.

Sample answer outline

The pipeline uses Storybook's test runner with the axe-playwright integration to visit every story URL and run axe-core. Results are serialized to JSON and stored as a CI artifact. A comparison step diffs against the previous main branch baseline to detect regressions. The score per component is computed from the number of passing vs. failing rules weighted by WCAG level (A violations score worse than AA). A GitHub Action posts a summary comment on PRs with a diff table. The documentation site reads the latest artifact from CI storage to display live accessibility scores on each component page.

Expect these follow-ups

• How do you handle a story that legitimately has an accessibility violation because it is demonstrating an incorrect usage pattern for documentation purposes?
• How would you extend the pipeline to also run manual screen reader checks as a scheduled batch job rather than per-PR?

As asked

Design the full architecture for a documentation site that serves live interactive component examples, auto-generated prop tables from TypeScript, code playgrounds where visitors can edit and preview components, and design token reference pages that update automatically when tokens change.

Sample answer outline

The site is built with a static site generator (Astro or Next.js) that imports the component library directly and renders live examples via Storybook iframes or embedded story blocks. Prop tables are generated at build time from TypeScript declaration files using react-docgen-typescript. The code playground uses a sandpack or CodeSandbox SDK-based embed that loads the component library from a CDN URL. Token reference pages are generated from the token JSON source file at build time, with a rebuild triggered by any change to the tokens package. Deployment is tied to the component library release pipeline so docs always match the published package.

Expect these follow-ups

• How do you handle versioned documentation for older major versions of the library that product teams are still using?
• How do you ensure the code playground sandbox uses the same version of the library as the documentation page it appears on?

As asked

A company has five products with inconsistent animation patterns. How would you create a motion system that teams will actually adopt?

Sample answer outline

Start with principles tied to product behaviour: feedback, continuity, hierarchy, and attention management. Define reusable tokens for duration, easing, delay, and choreography, plus patterns for common interactions such as navigation, disclosure, loading, and confirmation. Build examples in the design system and implementation libraries so teams do not have to translate abstract guidance by hand. Roll out through audits, templates, office hours, and a contribution model. The trap is making a beautiful motion deck with no engineering path or product-specific rules.

Expect these follow-ups

• What should be a token and what should stay bespoke?
• How do you measure whether the motion system improved the product?
• How do you handle a product whose brand needs a different motion feel?

As asked

Your design system ships CSS files, JS bundles, icon SVGs, and font files. You need to serve these globally with low latency, support versioned URLs so consumers can pin to specific versions, and allow hotfixes to the latest version without cache invalidation pain. Design the full delivery architecture.

Sample answer outline

Assets are stored in an object store (S3 or equivalent) under versioned paths like /v2.3.1/tokens.css and also aliased at /latest/tokens.css. CDN caches versioned paths with immutable headers (Cache-Control: max-age=31536000, immutable) since they will never change. The latest alias is cached with a short TTL or bypassed to always hit origin. A hotfix updates the patch version (2.3.2) rather than mutating the existing artifact. A publish pipeline uploads artifacts, updates the latest symlink, and invalidates only the latest CDN path. The candidate should mention integrity hashes (subresource integrity) for consumers who want to verify file contents.

Expect these follow-ups

• How would you handle a zero-day vulnerability in a widely adopted version of the design system's JavaScript bundle?
• How do you structure the CDN path so that consumers can subscribe to minor updates automatically but pin the major version?

As asked

Design a system that reads a Figma component specification and generates scaffolding for a React component, including the prop types from Figma variants, a Storybook story for each variant, and a placeholder test file. How would you build this, and what are the critical failure modes?

Sample answer outline

The pipeline uses the Figma REST API to read a component's properties and variants, maps Figma property types (text, boolean, variant) to TypeScript types (string, boolean, union), generates a component file from a handlebars template, a story file with each variant combination as a story, and a test file with a basic render smoke test. Critical failures: Figma property names with spaces or special characters that are invalid JavaScript identifiers, Figma components with hundreds of variant combinations generating an unmanageable story file, and the generator producing code that does not match the actual desired behavior (it scaffolds, not implements). The system should always be a starting point for a human, not a complete implementation.

Expect these follow-ups

• How would you handle a Figma component that has nested instances of other design system components?
• How do you prevent engineers from treating the generated scaffolding as production-ready without reviewing it?

As asked

You want to know, across 30 product repositories, what percentage of UI surface area uses design system components versus custom-built alternatives. Design a system that produces this metric automatically and keeps it up to date.

Sample answer outline

An AST-based scanner (using ts-morph or Babel) visits all JSX files in each product repo, counts all JSX element names, and categorizes them as: design system components (matched against the published package's exports), custom UI components (capitalized component names not from the system), or native HTML elements. The ratio of design system component usages to all component usages (excluding HTML elements) is the adoption rate. The scanner runs in a nightly CI job across all repos using a shared GitHub Actions workflow dispatched by the design system team. Results are stored in a time-series store and visualized on a team dashboard.

Expect these follow-ups

• How do you handle product teams who wrap design system components in their own abstraction layer, making the adoption appear lower than it is?
• How would you add token adoption scanning (percentage of CSS files using var(--ds-) tokens) to the same pipeline?

As asked

Your company has teams using React, Vue, Angular, and vanilla JavaScript. Design a design system built on native Web Components that works correctly across all of these. Address shadow DOM styling, form element participation, SSR support, and accessibility.

Sample answer outline

Web Components (CustomElement + Shadow DOM) are framework-agnostic by nature. For styling, expose CSS custom properties and CSS parts as the public theming API. For form elements (inputs, selects), use the ElementInternals API with setFormValue to participate in native form submission without wrapping in a native input. SSR with Web Components requires Declarative Shadow DOM (the shadowrootmode attribute on a template element), which is now supported natively in all modern browsers including Safari 16.4 and later, so a polyfill is only needed for older Safari. For accessibility, follow the ARIA Authoring Practices Guide for each widget, use internals.setValidity for form element validation state, and provide wrapper packages (react-wrap-wc or Lit's React package) for framework teams who need React-compatible synthetic events.

Expect these follow-ups

• How do you handle the lack of a stable SSR solution for Web Components in a Next.js context?
• How do you version a Web Component that is used as a custom HTML element, since the tag name must be registered globally and cannot be scoped?