Cross-platform Button API and implementation
WHAT IT TESTS: API parity vs platform-specific implementation. OUTLINE: 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.
A brand-only component consuming core tokens
WHAT IT TESTS: Layering brand-specific components. OUTLINE: Keep the unique component in a brand-specific package that depends on core tokens and primitives; do not add it to core.
Architecting density themes with tokens
WHAT IT TESTS: Density via token layering. OUTLINE: Components reference semantic spacing tokens; a density theme repoints those tokens via CSS variables on a wrapper, so one stylesheet adapts.
Breaking token changes across multiple themes
WHAT IT TESTS: Token change safety under multi-theme. OUTLINE: A change is safe if every theme still satisfies the token's contract and contrast; dangerous if it breaks one theme, like a value that fails contrast in high-contrast mode.
Automating a breaking design token rename
WHAT IT TESTS: Token migration automation. OUTLINE: Ship a codemod to rewrite old token references, add a deprecation alias mapping old to new during a transition window, document the change.
Backporting a critical fix to an older major
WHAT IT TESTS: Maintenance branch and backport strategy. OUTLINE: Backport the fix to the supported older major as a patch, leveraging a documented support window and maintenance branches.
Contribution model for a multi-framework system
WHAT IT TESTS: Multi-framework architecture and process. OUTLINE: Web Components core with thin React and Vue wrappers, shared tokens and spec, contribution rules requiring core-plus-wrapper changes, conformance tests.
Automated detection of deprecated component usage
WHAT IT TESTS: Deprecation auditing pipeline. OUTLINE: Machine-readable deprecation metadata, AST scanning across repos, scheduled jobs, per-team dashboards and PR-level warnings with codemod links.
Automating design system standards enforcement
WHAT IT TESTS: Shift-left enforcement tooling. OUTLINE: Custom ESLint and Stylelint rules for tokens and APIs, a11y testing with axe, editor and pre-commit hooks, blocking CI gates plus visual regression.
Managing cross-framework parity in a design system
WHAT IT TESTS: Cross-framework parity strategy. OUTLINE: Shared token and spec source of truth, optional Web Components core, per-framework wrappers, a parity matrix, coordinated releases.
Governance for a multi-brand design system
WHAT IT TESTS: Multi-brand architecture and governance. OUTLINE: Brand-agnostic core consuming semantic tokens, per-brand token themes, contribution rules blocking brand conditionals in core.
Challenges of a federated contribution model
WHAT IT TESTS: Federated contribution mechanics. OUTLINE: Federation scales velocity but needs governance, RFCs, contribution guidelines, automated quality gates, and core review.
Tracking design system health across the org
WHAT IT TESTS: Adoption metrics and tooling. OUTLINE: Static AST scanning for component imports and props, lint or detect-one-offs, parse package manifests for version drift, aggregate into a dashboard.
Repo and versioning strategy for multi-platform DS
WHAT IT TESTS: Multi-platform packaging. OUTLINE: Shared platform-agnostic tokens as source of truth, per-platform packages, independent semver, a monorepo with workspaces.
Centralized vs federated design system team models
WHAT IT TESTS: Org model trade-offs. OUTLINE: Centralized gives consistency and quality but bottlenecks; federated scales contribution but risks fragmentation; many teams use a hybrid with central governance.
Deprecating a widely used component gracefully
WHAT IT TESTS: Phased deprecation strategy. OUTLINE: Announce and document replacement, soft-deprecate with runtime and type warnings, ship codemods, remove only in a later major.
Versioned documentation site for a design system
WHAT IT TESTS: Versioned docs architecture. OUTLINE: Snapshot docs per release, version-prefixed routes, a version switcher, canonical latest. RED FLAG: Serving only latest docs from a single live source with no historical snapshots or version routing.
Architecting decoupled but linked Tabs components
WHAT IT TESTS: Compound components and shared state across the tree. OUTLINE: A Tabs context provider holds active state, TabList and TabPanel consume it anywhere inside the provider.
Designing a flexible yet usable DataTable API
WHAT IT TESTS: Component API design judgment. OUTLINE: Sensible defaults, compound or slot-based composition for flexibility, props for common cases. RED FLAG: Defaulting to one giant config object or exposing every internal as a flat prop without layering.
Explain token aliasing in design systems
WHAT IT TESTS: Layered token architecture intuition. OUTLINE: Primitives hold raw values, semantic tokens reference them by intent, components consume only semantic ones. RED FLAG: Hardcoding hex values in components or skipping the semantic layer entirely.