Design System — Cheat Sheet

Tags: design-system, tokens, figma, components, accessibility, storybook, css

Level: intermediate

TL;DR: Single source of truth aligning UX tokens, accessible UI components, and governance to eliminate UI drift across products.

Key concepts

Design tokens store atomic decisions like color, spacing, and typography as platform-agnostic values.

Three-tier token architectures separate global primitives, semantic alias roles, and component-scoped overrides.

Shared components translate semantic tokens into accessible UI elements using WAI-ARIA authoring practices.

Strict Semantic Versioning protects consuming micro-frontends and repositories from unexpected breaking visual updates.

Automated visual regression testing captures unexpected layout shifts using headless browser snapshots.

Multi-brand or theming architectures switch entire visual layers purely by swapping semantic token aliases.

Headless component primitives separate state machine logic and accessibility from opinionated styling.

Tooling like Style Dictionary transforms raw token dictionaries into CSS variables, iOS Swift, and Android XML.

Typical questions and ready answers

Q: How do you structure design tokens to ensure maintainability and theming support?R: I enforce a three-layer hierarchy: primitive values, semantic purpose aliases like surface and text, and component tokens. Rebranding or dark theme implementation requires changing only the semantic layer without touching individual component files.

Q: When should a UI element live in the core design system versus a feature repository?R: I apply the rule of three: components stay in local product code until three distinct features require identical behavior. Once extracted, the component must be generic, fully accessible, and backed by automated tests before publishing.

Q: How do you release breaking API changes across multiple consuming teams?R: I follow strict SemVer, deprecating old props with runtime warnings for a release cycle before removal. For larger migrations, I distribute AST codemods that automatically rewrite consumer components across downstream repositories.

Pitfalls and common mistakes

Hardcoding raw hex values or arbitrary pixel paddings directly inside feature component stylesheets.

Prematurely pushing bespoke, single-use product layouts into the shared core system.

Treating a design system as just a UI kit without documented usage guidelines and accessibility guarantees.

Ignoring keyboard navigation, screen reader announcements, and high-contrast mode requirements during design reviews.

Centralizing component approvals into a rigid bottleneck that discourages community contribution and inner-sourcing.

Snippets and commands

{
  "color": {
    "primitive": {
      "blue-500": { "value": "#0284c7" }
    },
    "semantic": {
      "surface-primary": { "value": "{color.primitive.blue-500.value}" }
    }
  }
}

TypeScript

```import styled from 'styled-components';

export const Button = styled.button<{ $variant?: 'primary' | 'subtle' }>`

padding: var(--space-inset-md, 8px 16px);

border-radius: var(--radius-sm, 4px);

font-family: var(--font-family-base, sans-serif);

background-color: ${({ $variant }) =>

$variant === 'subtle'

? 'var(--color-surface-subtle)'

: 'var(--color-surface-primary)'};

color: var(--color-text-on-surface);

border: none;

cursor: pointer;

&:focus-visible {

outline: 2px solid var(--color-border-focus);

outline-offset: 2px;

}

`;

```

To review

[ ] Token transformation pipelines using Style Dictionary for mobile and web targets.

[ ] Visual regression and snapshot diffing pipelines in continuous integration.

[x] WCAG 2.1 AA accessibility contrast standards and keyboard focus management.

[x] Package bundling and tree-shaking configuration for npm distribution.

References

Atomic Design by Brad Frost

W3C Design Tokens Community Group Specification

W3C WAI-ARIA Authoring Practices Guide (APG)

Style Dictionary documentation

Jarvis Interviews
Jarvis