More in Design & UX — page 5
CSS custom properties versus Sass for theming
WHAT IT TESTS: runtime versus build-time variables. OUTLINE: custom properties are live and cascade for dynamic switching; Sass variables compile away. RED FLAG: claiming Sass variables can change theme at runtime without recompiling.
Architecting a themeable React component library
WHAT IT TESTS: theming React components via Context. OUTLINE: a ThemeProvider supplying tokens through Context, components reading them, and CSS variables for performance. RED FLAG: prop-drilling the theme or putting fast-changing state in Context.
Structuring tokens for brand and sub-brand inheritance
WHAT IT TESTS: layered token architecture. OUTLINE: tiered tokens (primitive, semantic, component), sub-brands override only semantic aliases, and references keep inheritance live. RED FLAG: copying the full token set per brand and diverging.
Implementing light and dark mode on the web
WHAT IT TESTS: practical theming with CSS. OUTLINE: CSS custom properties for color tokens, a data-theme attribute toggle, and prefers-color-scheme as default. RED FLAG: hardcoding two full stylesheets or only relying on JS to recolor.
Automated enforcement of deprecated component removal
WHAT IT TESTS: automating deprecation governance in CI. OUTLINE: lint rule failing new usages, codemods for existing ones, and a usage dashboard gating removal. RED FLAG: hard-failing builds day one with no migration path.
Coexisting major versions during migration
WHAT IT TESTS: running two breaking versions side by side safely. OUTLINE: scoped aliases or namespaced packages, isolated token scopes, and incremental migration. RED FLAG: ignoring duplicated CSS, global token collisions, and bundle bloat.
Tracking design system component usage and versions
WHAT IT TESTS: building adoption telemetry across many apps. OUTLINE: static scan of code or lockfiles, a central reporting store, and a dashboard; data drives deprecation and roadmap. RED FLAG: only counting npm downloads as real usage.
First steps to deprecate a legacy component
WHAT IT TESTS: knowing how to signal deprecation without breaking users. OUTLINE: add a JSDoc @deprecated tag and IDE/console warning, document the migration, and keep the component working. RED FLAG: deleting it immediately.
SemVer bump for a non-breaking bug fix
WHAT IT TESTS: Whether you know SemVer's three levels. OUTLINE: A backward-compatible bug fix is a PATCH, the third number; major is breaking, minor is new compatible features. RED FLAG: Calling a fix a minor or bumping major out of caution.
Quantifying the cost of a missing component
WHAT IT TESTS: Whether you justify investment with evidence of waste. OUTLINE: Scan repos for duplicate hand-rolled tables, count implementations and lines, estimate redundant build and maintenance hours plus defect rates.
Isolating the design system's velocity impact
WHAT IT TESTS: Whether you can argue causation, not correlation. OUTLINE: Use comparison groups, difference-in-differences or before-after baselines, and control for confounders; cite mechanism data like component reuse.
Constructing a design system ROI formula
WHAT IT TESTS: Whether you can frame the system as an investment. OUTLINE: ROI equals (benefits minus cost) over cost; benefits from time saved, defect reduction, and faster onboarding; gather data via analytics and tickets.
Quantifying migration cost for a major release
WHAT IT TESTS: Whether you can estimate and measure migration effort. OUTLINE: Pre-release, scan codebases for affected usages and estimate engineer-hours; post-release, track actual upgrade lead time and effort.
Designing a UI consistency score
WHAT IT TESTS: Whether you can quantify consistency objectively. OUTLINE: Combine signals like token vs hard-coded values, design-system vs off-system components, and override rates, then automate via AST scans and CI.
Tracking design system adoption technically
WHAT IT TESTS: Whether you can instrument adoption with real data. OUTLINE: Scan codebases for component imports via AST, compute adoption versus off-system usage, and aggregate into a dashboard over time.
Governance model for specialized contributions
WHAT IT TESTS: Whether you can govern contributions of varied scope. OUTLINE: Define a governance model, RFC and shared-need gate, tiered intake (core vs community), CI and CODEOWNERS review, then versioned release.
Essential docs for onboarding a new team
WHAT IT TESTS: Whether you can make a system self-serve. OUTLINE: Getting-started guide, per-component API and usage docs, design guidelines and tokens, plus changelog and migration notes.
Bug report to deployed fix workflow
WHAT IT TESTS: Whether you have a disciplined bug-fix pipeline. OUTLINE: Triage and reproduce, write a failing test, fix it, pass CI gates and review, then patch-release and notify.
Designing a component deprecation process
WHAT IT TESTS: Whether you can retire a component without breaking consumers. OUTLINE: Announce with a replacement and timeline, mark deprecated with runtime and lint warnings, provide codemods, then remove only in a major release.
Classifying a visually breaking padding change
WHAT IT TESTS: Whether you grasp that visual changes can be breaking. OUTLINE: A layout-shifting padding change is effectively breaking, so major; release with visual diffs, a migration note, and a token or opt-in path.