Design Engineering
Date: 2026-08-16
The seam between a design and a running interface. Design engineering owns the layer where visual decisions become system constraints — tokens, components, states, motion and accessibility — so the same decision doesn’t get remade on every screen.
A cross-domain view. Ordered from the primitives outwards, because a component system built before its tokens will be rebuilt.
Draws on Web Development and User Experience.
Everything here is filed elsewhere: CSS in Languages/CSS/, accessibility in User Experience/, the performance section in Performance/, and the design-system cluster in Web Development/Design Systems/.
1. The primitives
Decisions made once, referenced everywhere. Getting these wrong is the expensive mistake, because everything above encodes them.
- Design Tokens — named values for colour, space, type, radius, shadow. The contract between design and code
- Colour Systems — palettes, semantic naming, and why
--colour-dangeroutlives--red-500 - Type Scale — a ratio-based scale, and choosing sizes from it rather than by eye
- Fluid Type and Space —
clamp()and scaling between breakpoints instead of stepping - Spacing Systems — one scale, applied consistently, which is most of what “looks designed” means
- Theming — light, dark and brand variants as token swaps rather than parallel stylesheets
- Colour Contrast — the ratios as a constraint on the palette, checked at token level rather than per screen
2. CSS as an engineering discipline
- The Cascade and Specificity — origin, layer, specificity, order
- Cascade Layers — controlling override order deliberately instead of by escalation
- Custom Properties — runtime variables, and how they differ from build-time ones
- CSS Architecture — BEM, utility-first, CSS-in-JS: what each optimises for
- Utility-First vs Semantic CSS — the argument, stated fairly
- Grid · Flexbox — two-dimensional and one-dimensional layout, and choosing correctly
- Container Queries — component-scoped responsiveness, which removes most breakpoint logic
- Positioning and Stacking Contexts — the actual reason
z-indexdoesn’t work - Logical Properties — writing-direction-aware CSS, and why it’s the better default
3. Components
- Component API Design — props as a public interface: naming, defaults, and what not to expose
- Composition over Configuration — slots and children rather than a fortieth boolean prop
- Component States — default, hover, focus, active, disabled, loading, error, empty. The set that’s always incomplete
- Variants and Modifiers — a component’s axes of variation, kept orthogonal
- Polymorphic Components — changing the rendered element without changing the API
- Headless Components — behaviour and accessibility without styling, and why the pattern won
- Web Components — the platform’s own encapsulation, and when it beats a framework’s
- Component Documentation — the prop table, the states, and the usage guidance that stops misuse
4. Design systems
- Design Systems — what one actually is: tokens, components, patterns, guidance, and governance
- Design System Governance — who decides, how contributions work, and how it stops being one person’s project
- Design System Adoption — the real problem, which is social rather than technical
- Component Inventory — auditing what exists before building what’s missing
- Design System Versioning — shipping breaking changes to consumers you don’t control
- Design Tokens in Practice — a token pipeline from design tool to CSS to platform
5. Accessibility as implementation
Not a review stage. It’s a property of the component, decided when the component is written.
- The Accessibility Tree — what assistive technology actually reads
- Semantic HTML — the elements that give you behaviour and accessibility for free
- ARIA — what it adds, and the first rule: don’t, if a native element will do
- Keyboard Navigation — focus order, focus visibility, and focus traps
- Accessible Forms — labels, error association, and required-field semantics
- Focus Management — where focus goes after a modal, a route change, or a deletion
- Accessibility Testing — the share automated tools catch, and the larger share they can’t
- WCAG — the standard’s structure, and what conformance requires
6. Motion
- Motion and Transitions — motion explaining what changed, not decorating it
- Animation Performance — compositor-only properties, and diagnosing when you’ve left them
- Easing and Duration — the values that read as natural, and why linear rarely does
- Reduced Motion —
prefers-reduced-motionas a requirement, not an enhancement - View Transitions — the platform API for animating between states and pages
7. The design-to-code seam
- Design Handoff — what a developer actually needs, and what gets sent instead
- Figma to Code — the workflow, its automation, and where generated output stops being useful
- Visual Regression Testing — screenshot diffing, and managing its false positives
- Responsive Design — breakpoints as a last resort, intrinsic sizing as the default
- Progressive Enhancement — a working baseline first, capability layered on
- Browser Compatibility — feature detection and reading support data properly
8. The performance of an interface
- JavaScript Execution Cost — the price of a component library, measured rather than assumed
- Cumulative Layout Shift — reserving space, and the image and font causes that dominate
- Font Loading — FOIT, FOUT,
font-display, subsetting - Image Optimisation — responsive sources and modern formats
- Code Splitting — shipping less per route
- Loading and Perceived Performance — skeletons and optimistic UI, and where they mislead
The tension worth naming
Design engineering sits between two groups with incompatible defaults. Design optimises for the specific screen; engineering optimises for the general case. A system that’s too rigid gets bypassed, and a system that’s too flexible stops being a system. Most of the discipline is arbitrating that, per component, on evidence — which is why Component Inventory and Design System Adoption matter more than any individual component does.