Before getting into the details of how story.to.design works, we want to provide a few basic concepts and definitions that are key to why story.to.design exists.
What is a design system?
As defined by the Nielsen Norman Group:
A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.
Design systems are typically composed of 5 pillars: design tokens, UI kit (or design kit), component library, content design and a documentation site. They allow teams to build a consistent user experience, deploy features more quickly, make rebranding changes more efficiently and free-up time to address challenging UX issues.
What is a UI kit?
Also known as a design kit (or UI library), a UI kit is a set of patterns or components existing in design tools, such as Figma. The kit follows all design rules established by the design system, and is built using design tokens. It is what a designer uses inside their regular tool to use and apply the design system when designing new experiences.
For a UI kit to be efficient, it must always be up-to-date with the component library on the code side. However, depending on the size of the UI kit, it can often be costly and time-consuming to maintain in sync. It requires strong collaboration and communication between design and development teams, but even when this is the case, UI kits often need to be updated by hand, component by component, a task that takes designers away from what they do best: designing new experiences.
What is a component library?
A component library is the code side of the UI kit. It’s a list of reusable components that follow all the standards laid-out by the design system, and which developers must use when creating new experiences.
In order to document and visually preview this list of components, many development teams use a tool called Storybook.
What is Storybook?
As per the description on Storybook’s website:
Storybook is a free, open source frontend workshop for building UI components and pages in isolation. It streamlines UI development, testing, and documentation.
In other words, it’s a way to expose your design system’s components in a web environment where everybody can interact with. It’s often used to document the technical aspects of your coded components.
Within each component, Storybook uses something called stories. These are a fundamental part of story.to.design, and even inspired the name!
Are there alternatives to Storybook?
Yes! story.to.design also supports Backlight.dev and Histoire (https://histoire.dev/). They are platforms similar to Storybook that allow you to write stories to showcase and document your components.
What are stories?
According to Storybook’s documentation:
A story captures the rendered state of a UI component. Developers write multiple stories per component that describe all the “interesting” states a component can support.
Stories are written in Component Story Format (CSF), an ES6 modules-based standard for writing component examples.
For more details about stories, check out Storybook’s documentation.