---
title: "design systems | Skills We Assign For | Azendo"
description: "Design systems — shared components, drift between design and code, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/design-systems/"
---

[Skills](https://azendo.co/skills/) Design and research 

# design systems.

A design system is the shared set of components, tokens, patterns and usage rules that a product is built from, existing in both the design files and the code so the two describe the same thing.

## 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](https://azendo.co/services/ux-ui-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](https://azendo.co/pricing/).

## Roles we assign design systems for

* [Product Designer UX/UI design](https://azendo.co/services/ux-ui-design/product-designer/)

## Service lines it sits in

* [UX/UI design](https://azendo.co/services/ux-ui-design/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in design and research

* [Figma — skill we assign for](https://azendo.co/skills/figma/)
* [Storybook — skill we assign for](https://azendo.co/skills/storybook/)
* [Maze — skill we assign for](https://azendo.co/skills/maze/)
* [Hotjar — skill we assign for](https://azendo.co/skills/hotjar/)
* [usability testing — skill we assign for](https://azendo.co/skills/usability-testing/)
* [design tokens — skill we assign for](https://azendo.co/skills/design-tokens/)
* [component libraries — skill we assign for](https://azendo.co/skills/component-libraries/)
* [Figma Dev Mode — skill we assign for](https://azendo.co/skills/figma-dev-mode/)

## Tell us what your roadmap needs design systems for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)