---
title: "Storybook | Skills We Assign For | Azendo"
description: "Storybook as the working design system — states, review and the Azendo roles assigned for frontend and design work."
url: "https://azendo.co/skills/storybook/"
---

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

# Storybook.

Storybook renders UI components in isolation, outside the application, so each one can be developed, reviewed and tested on its own. It is where a design system becomes something engineers actually use rather than something they refer to.

## Where Storybook fits on a long engagement.

A component in isolation forces the states to be considered: loading, empty, error, overflowing text, the longest label anyone will realistically enter. Those are the states that break interfaces in production and the ones nobody builds a page to demonstrate.

It is also the artefact that makes design and engineering agree. A designer can see what was actually built, an engineer can see what exists before building something similar, and a reviewer can check a change without running the whole application.

## What an assigned team does with Storybook.

A component catalogue is only trusted if it is current, and currency is continuous work that competes with feature delivery. Where it loses, engineers stop checking it and start building a fifth variant of something that already exists twice.

This is the clearest place design and frontend capacity have to be the same assignment. Both sit under [outsource UX design](https://azendo.co/services/ux-ui-design/) and development capacity on one agreement, at one monthly commitment.

## What we use Storybook for.

* States that would otherwise ship broken Empty, error and overflow states designed and built deliberately rather than discovered by users.
* Reducing duplicate components A visible catalogue, so a fourth button variant gets noticed in review.
* Visual regression testing Component snapshots that fail when an unrelated change alters something visually.

## How Storybook capacity is assigned.

This sits across design and frontend, assigned under outsourced design team capacity or software development depending on where the constraint is. The reasoning behind delivering this from Thailand is set out in [why we deliver from Thailand](https://azendo.co/why-thailand/).

## Roles we assign Storybook for

* [Frontend Developer Software development](https://azendo.co/services/software-development/frontend-developer/)
* [Product Designer UX/UI design](https://azendo.co/services/ux-ui-design/product-designer/)
* [UI Designer UX/UI design](https://azendo.co/services/ux-ui-design/ui-designer/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)
* [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

* [usability testing — skill we assign for](https://azendo.co/skills/usability-testing/)
* [design systems — skill we assign for](https://azendo.co/skills/design-systems/)
* [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/)
* [auto-layout and variants — skill we assign for](https://azendo.co/skills/auto-layout-and-variants/)
* [Sketch — skill we assign for](https://azendo.co/skills/sketch/)
* [Adobe XD — skill we assign for](https://azendo.co/skills/adobe-xd/)

## Tell us what your roadmap needs Storybook 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/)