Our Storybook is finally organised
The sidebar and tags lesson cleaned up years of clutter. Designers actually use it now.
Browse
Write stories, generate docs, run interaction, accessibility and visual tests, and publish a Storybook your designers and engineers trust
Created by Ana Sousa
Storybook has become the workshop and showroom for component libraries. Engineers use it to build components in isolation, designers use it to review real behaviour, and product teams use it as living documentation. Set up carelessly, though, it becomes a cluttered gallery of outdated examples. This course shows how to use Storybook as the backbone of a design system.
Starting from a small React and TypeScript component library, you will add Storybook, write stories in Component Story Format, generate documentation and set up a full testing workflow.
This course is for front end engineers working on shared components and for design technologists who maintain a design system. You should be comfortable with React and basic TypeScript. Designers who review components in Storybook will find the documentation and review sections useful too.
The course uses a current Storybook release with the React and Vite setup. Storybook evolves quickly, so where package names or configuration have changed between major versions I note the difference and link to the official migration guides.
Design systems lead teaching tokens, components and governance that scale across teams
I have led design system work for product teams where several squads ship to the same interface. My job sits between design and front end engineering: defining tokens, designing and building components, writing documentation and setting up the process that keeps the system alive after launch.
I teach design systems as a product with users, not as a style guide. That means audits, roadmaps, contribution models and versioning, along with the hands on parts like Figma variables, token pipelines, Storybook and accessible component APIs.
My courses suit designers who want to understand the code side and developers who want to understand the design side. I explain the trade offs honestly, including when a team does not need a full system yet.
The sidebar and tags lesson cleaned up years of clutter. Designers actually use it now.
We added long text and right to left stories and found four layout bugs in a day.
The documentation and design review sections are as valuable as the testing ones. Nice balance.
Interaction tests felt intimidating before. The select keyboard test example made it straightforward.
Accessibility and visual tests on every pull request was easy to set up after this. Some config paths differed in my version.
Content is solid, but I had to adjust imports for my Storybook version. The notes pointing to migration guides helped.