Design Systems
204 bites tagged Design Systems — interview questions with model answers, and 60-second explainers.
Manage light and dark themes with Variables and Modes
Separate primitive and semantic variables, define light and dark modes in one collection, and bind UI fills to semantic tokens. token-driven theming in Figma. duplicating screens per theme or hardcoding hex values.
Limitations of Figma Dev Mode generated code
Dev Mode output is static, absolute-positioned, non-semantic, and ignores responsiveness, state, and your component system; use it for values and structure, then refactor to semantic, tokenized… Realistic handoff expectations.
Building a scalable icon system in Figma
Standardize a grid, size, and stroke; make each icon a component with consistent naming, use currentColor-friendly single-color paths, and export optimized SVGs. Systematic, dev-friendly icon design.
Shared component library versus per-product builds
Shared libraries cut duplication and enforce consistency but add coupling, versioning, and a coordination tax; per-product code is fast but drifts. reuse versus autonomy.
Cross-platform Button API and implementation
Shared semantic props like variant, size, disabled, loading, onPress; web renders a button element with focus and CSS, native maps to platform touchables and accessibility traits. API parity vs platform-specific implementation.
Challenges of a federated contribution model
Federation scales velocity but needs governance, RFCs, contribution guidelines, automated quality gates, and core review. Federated contribution mechanics.
Tracking design system health across the org
Static AST scanning for component imports and props, lint or detect-one-offs, parse package manifests for version drift, aggregate into a dashboard. Adoption metrics and tooling.
Centralized vs federated design system team models
Centralized gives consistency and quality but bottlenecks; federated scales contribution but risks fragmentation; many teams use a hybrid with central governance. Org model trade-offs.
Versioned documentation site for a design system
Snapshot docs per release, version-prefixed routes, a version switcher, canonical latest. Versioned docs architecture. Serving only latest docs from a single live source with no historical snapshots or version routing.
Designing a flexible yet usable DataTable API
Sensible defaults, compound or slot-based composition for flexibility, props for common cases. Component API design judgment. Defaulting to one giant config object or exposing every internal as a flat prop without layering.
Explain token aliasing in design systems
Primitives hold raw values, semantic tokens reference them by intent, components consume only semantic ones. Layered token architecture intuition. Hardcoding hex values in components or skipping the semantic layer entirely.
Challenges of breaking changes in a design system
Technical (semver, codemods, coexistence) and organizational (comms, migration support, timelines) challenges. managing breaking changes at scale. shipping a breaking major with no migration path or warning.
Governance to keep platforms from diverging
A federated model with central stewards plus platform reps, an RFC process, and contribution rules. cross-team design system governance. a single team dictating to all platforms or pure free-for-all causing drift.
Modeling a confirmation action for voice
Model confirmation as a modality-agnostic intent, add voice tokens (prompts, accepted phrases, reprompts, timeouts), and map intent to each modality. abstracting intent from visual UI.
Responsive Tabs with one consistent API
One stable public API (items, value, onChange), internal swap of presentation by breakpoint, and shared selection state. adaptive component design. exposing two different APIs or duplicating state logic per mode.
Sharing logic, native UI across platforms
Shared module (e.g. Kotlin Multiplatform) for state/business rules, platform-native UI consuming it, and a clean interface boundary. separating shared logic from native UI. forcing shared UI and losing native feel.
Pixel-identical modals across platforms
Raise back-button and gesture behavior, safe areas and keyboard insets, native dismiss patterns, and accessibility differences. knowing platform UX conventions. agreeing to pixel-identical without flagging native expectations.
Preventing theme flash in SSR apps
Flash comes from server not knowing client preference; fix with a blocking inline script setting the theme before paint. SSR hydration and theme timing. setting the theme only in a useEffect after hydration.
CSS custom properties versus Sass for theming
Custom properties are live and cascade for dynamic switching; Sass variables compile away. runtime versus build-time variables. claiming Sass variables can change theme at runtime without recompiling.
Architecting a themeable React component library
A ThemeProvider supplying tokens through Context, components reading them, and CSS variables for performance. theming React components via Context. prop-drilling the theme or putting fast-changing state in Context.
Structuring tokens for brand and sub-brand inheritance
Tiered tokens (primitive, semantic, component), sub-brands override only semantic aliases, and references keep inheritance live. layered token architecture. copying the full token set per brand and diverging.
Implementing light and dark mode on the web
CSS custom properties for color tokens, a data-theme attribute toggle, and prefers-color-scheme as default. practical theming with CSS. hardcoding two full stylesheets or only relying on JS to recolor.
Automated enforcement of deprecated component removal
Lint rule failing new usages, codemods for existing ones, and a usage dashboard gating removal. automating deprecation governance in CI. hard-failing builds day one with no migration path.
Coexisting major versions during migration
Scoped aliases or namespaced packages, isolated token scopes, and incremental migration. running two breaking versions side by side safely. ignoring duplicated CSS, global token collisions, and bundle bloat.
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.