Design Systems
204 bites tagged Design Systems — interview questions with model answers, and 60-second explainers.
Designing a Card component's configurable API
Expose content via composition (slots/children), expose constrained variants as enums, lock spacing and brand tokens. API design judgment for reusable components.
What problem do CSS Cascade Layers solve?
Layers create explicit priority bands, layer order beats specificity inside, and you control override without selector hacks. understanding of the cascade beyond specificity.
Cross-platform themeable token system
Tier tokens with semantic theme sets that remap primitives per mode, transform to each platform's theme mechanism, and deliver versioned packages. combining theming with cross-platform delivery.
Structuring docs for multiple audiences
Layer docs by audience, give developers API and code, designers usage and design guidelines, PMs principles and coverage, with shared foundations like tokens and accessibility. audience-aware documentation strategy.
Delivering an urgent design system hotfix
Branch from the released tag, apply a minimal fix, add a regression test, ship a patch version, then forward-port to main. hotfix release process. releasing unreleased work from main or skipping the patch and regression test.
Contributing a new component variant
Align with maintainers first, follow guidelines, implement with API and tokens, add stories, docs, and tests, then open a PR for review. understanding of design-system contribution flow.
The role of Storybook in a design system
Storybook renders components in isolation across states, serving as living documentation, a development sandbox, and a base for visual and accessibility testing. understanding of component workbenches.
Architecting multi-brand, dark-mode theming
Tier tokens into primitive, semantic, and component layers; components consume semantic tokens; themes swap by remapping semantic-to-primitive on a scope like data-theme. scalable theming architecture.
Versioning and distributing token updates safely
Publish tokens as a semver package, bump major on breaking changes, deprecate before removing, communicate via changelogs and migration guides. release discipline for shared tokens.
What design tokens are and why they matter
Tokens are named, platform-agnostic design decisions stored centrally, enabling consistency, theming, and one-place updates. grasp of design tokens as a single source of truth.
Building a container-query-driven card component
Declare a wrapper container with container-type, query it with @container, restyle the card's internal grid by container width, optionally use cqi units. applied container query mechanics.
Why Oklch beats HSL for color variations
HSL lightness is not perceptually uniform so equal steps look uneven, Oklch keeps perceived lightness consistent across hues, giving predictable hover and palette scales. knowledge of perceptual color spaces.
A federated design system governance model
Let the product team own the component as maintainers, with the core team setting standards, reviewing against a checklist, and owning the platform and tokens. Scaling contribution via federation.
Driving and measuring design system adoption
Lower friction with migration paths and great docs, incentivize over mandate, and measure adoption via package usage, component coverage, and code analysis. Strategy plus instrumentation for adoption.
Governance for design system contributions
A clear intake and proposal step, review by core maintainers plus design, and criteria covering accessibility, API consistency, tokens, tests, and docs. Designing a contribution and review process.
Classifying a Card change under SemVer
Removing a prop is breaking so the whole release is major, document and migrate, and release the highest applicable level. Applying SemVer rules to a mixed change.
Documenting a single UI component
Purpose and when to use, a props API table, live examples of variants and states, accessibility notes, and do and don't guidance. Knowing what good component docs contain. documenting only the prop list with no usage guidance.
CI/CD pipeline for a design system monorepo
Install and cache, then parallel lint, type-check, unit and visual tests, then build, and on main a release job bumps versions and publishes. Designing release automation for a monorepo. publishing before tests pass.
Releasing a breaking Button change with SemVer
Bump the major version, write a changelog and migration guide, deprecate before removing where possible, and communicate clearly. Handling breaking changes responsibly under SemVer.
Automated visual regression testing for components
Render components in known states, capture screenshots, diff against approved baselines in CI, and require human review of differences. Catching unintended visual changes automatically.
Packaging a design system as an npm dependency
Publish to an npm registry, with package.json holding the version, entry points, and dependencies, and version it via SemVer. Distributing shared code as a versioned package.
Why design systems use Sass or PostCSS
Sass adds variables, nesting, mixins, and functions for reuse; PostCSS transforms CSS via plugins like autoprefixer. Knowing what preprocessors add over plain CSS. claiming native CSS variables make them entirely obsolete.
Respecting prefers-reduced-motion in a design system
Gate CSS animations behind the media query, read the same preference in JS via matchMedia, and centralize motion tokens. Building motion accessibility into system architecture. killing all motion instead of reducing it.
Controlled vs uncontrolled Modal component
Uncontrolled is convenient but inflexible, controlled gives parent full power and predictability, and a hybrid supports both. API design judgment for component state ownership. claiming controlled is always better.
Get Design Systems bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.