design systems.

Where design systems fits on a long engagement.

A design system pays off through consistency and speed at once. A new screen is assembled from reviewed components rather than designed from scratch, which means it is faster to produce and correct by default — accessibility, states and responsive behaviour already handled in the pieces.

Drift between the design file and the code is the failure that makes a system stop being one. A component updated in one and not the other means designers and engineers are working from different definitions, and within a year neither is authoritative. Preventing it needs a process rather than good intentions.

What an assigned team does with design systems.

A design system is a product with internal users. It needs versioning, a changelog, documentation, and someone accountable for it — treated as a project that ships and ends, it degrades into a component library people work around.

That ongoing ownership is why design and frontend capacity are scoped on the same agreement under outsource ux design rather than handed between them.

What we use design systems for.

• Screens assembled rather than designed Reviewed components, so new work is faster and correct by default.
• One definition across design and code A process that prevents the drift which makes neither authoritative.
• Accessibility solved in the component States and contrast handled once rather than per screen.

How design systems capacity is assigned.

Design system work is assigned as standing capacity, because a system without an owner stops being a system. What that commitment covers is set out in how the monthly fee is built.