HTML in Design Systems

A design system is a shared library of components, tokens, patterns and guidelines used across an organization's products. The HTML side of the system encapsulates markup conventions so every product renders consistent button, modal, form and card structures.

Tokens are atomic design values (color: blue-500, spacing: 16px). Components are reusable HTML+CSS+JS units (Button, Modal, TextField). Patterns are higher-level compositions (login form, content card with avatar). The HTML structure is fixed at the component level; patterns combine components.

Components encode best practices: every Button uses the <button> element (not a div) with proper type attribute. Every Modal traps focus, supports Escape, and has the right ARIA roles. Adopting components avoids re-implementing accessibility for every product feature.

Storybook renders each component in isolation with various props and variants. Designers and PMs see the available components without reading code; developers see usage examples without searching the source. It is the de facto standard for design system docs.

Treat the design system as a semver-published package. Breaking HTML/CSS changes (renaming a CSS class consumers depend on, removing a component slot) bump the major version. Consumers update intentionally on their schedule, not as a surprise.

Component props, slots and exposed parts are the public API. Once shipped to consumers, treat them as expensive to change. Deprecate gradually: add the new API alongside the old, log warnings for old usage, remove only after a measured period.

Tokens enable theming: swap the color token map, and every component picks up the new palette. White-labeling (different brands sharing components with different visuals) becomes trivial when tokens drive everything and components reference tokens instead of hard-coded values.

For organizations using multiple frameworks (React, Vue, Angular), web components offer one implementation that works everywhere. Build with Lit, FAST, or vanilla; consume identically in any framework. The HTML structure is the contract, not the framework.

Design systems bake accessibility into every component once: keyboard handling, ARIA roles, focus management, color contrast. Product teams adopting the system inherit accessibility instead of building each feature from scratch — measurably reduces accessibility bugs across the company.

Track which products use which version of the design system. Tools like Backstage's component catalog, custom Slack bots monitoring package.json, or simple internal dashboards reveal where the latest version has not yet landed. Adoption metrics justify continued investment.

Decide who can add components: a central design systems team only? Federated contributions from product teams? Each model has trade-offs. Central teams ship slower but maintain quality; federated teams move fast but risk fragmentation. Pick consciously based on the org's scale.

Design systems are living products. Add components as new patterns appear in products, deprecate components that no longer fit, refactor when fundamental decisions need to change. Treat the system as software with a roadmap, not a finished artifact.

Why are design tokens (like color: blue-500, spacing: 16px) preferred over hard-coded values inside components?

Design systems package tokens (atomic values), components (reusable HTML units) and patterns (higher-level compositions) into a versioned library shared across products. Use Storybook for documentation, web components for cross-framework consumption, semver for stability. Bake accessibility into every component, track adoption, and evolve the system as a living product.