Design Systems Cheat Sheet

Covers design tokens, component API patterns, governance and versioning practices, and documenting components with Storybook for a scalable system.

2 PagesIntermediateMar 12, 2026

Core Building Blocks

What a mature design system is made of.

Design tokens- Named, platform-agnostic values (color, spacing, typography) that are the source of truth for style
Component library- Reusable, tested UI components (Button, Input, Modal) built on top of tokens
Patterns- Documented solutions to recurring UX problems (forms, empty states) composed from components
Brand guidelines- Voice, tone, imagery, and logo usage rules that complement the visual language
Accessibility guidelines- Baseline requirements (contrast ratios, focus states, keyboard support) every component must meet
Documentation site- Living reference, often Storybook, showing component usage, props, and do's/don'ts

Design Tokens

Source-of-truth values transformed for every platform.

json

{  "color": {    "brand": { "500": { "value": "#6366f1" } },    "text": { "primary": { "value": "{color.gray.900}" } }  },  "spacing": {    "sm": { "value": "8px" },    "md": { "value": "16px" }  },  "font": {    "size": { "body": { "value": "16px" } }  }}

Component API Pattern

Variant/size props keep visual choices constrained.

typescript

type ButtonVariant = 'primary' | 'secondary' | 'danger';type ButtonSize = 'sm' | 'md' | 'lg';interface ButtonProps {  variant?: ButtonVariant;  size?: ButtonSize;  isDisabled?: boolean;  children: React.ReactNode;}function Button({ variant = 'primary', size = 'md', isDisabled, children }: ButtonProps) {  return (    <button      className={`btn btn--${variant} btn--${size}`}      disabled={isDisabled}      aria-disabled={isDisabled}    >      {children}    </button>  );}

Governance & Process

What keeps a design system healthy at scale.

Semantic versioning- Design system packages follow semver; breaking an API or visual contract is a major bump
Contribution model- Documented process for proposing new components/tokens, e.g. RFC + design + a11y review
Deprecation policy- Old components/props get a warning and a migration window before removal
Design-dev pairing- Designers and engineers co-own components so Figma and code never drift apart
Adoption metrics- Tracking which teams/products use which version, to plan safe rollout of breaking changes

Storybook Documentation

CSF3 story format for documenting a component's states.

typescript

// Button.stories.tsximport type { Meta, StoryObj } from '@storybook/react';import { Button } from './Button';const meta: Meta<typeof Button> = {  title: 'Components/Button',  component: Button,  argTypes: {    variant: { control: 'select', options: ['primary', 'secondary', 'danger'] },  },};export default meta;type Story = StoryObj<typeof Button>;export const Primary: Story = {  args: { variant: 'primary', children: 'Click me' },};

Pro Tip

Version design tokens separately from components — tokens change far more often (a single color tweak) than component APIs, and coupling their releases forces consumers to take unrelated breaking changes just to get a color fix.

Was this cheat sheet helpful?

CSS Custom Properties (Variables) Cheat Sheet

Figma to Code Workflow Cheat Sheet

Explore Topics

#DesignSystems#DesignSystemsCheatSheet#WebDevelopment#Intermediate#CoreBuildingBlocks#DesignTokens#ComponentAPIPattern#GovernanceProcess#APIs#CheatSheet#SkillVeris

Sri Hayavadhana Info-Tech

Professional Web Designing Services