Storybook is certainly a tale of a phoenix rising from its ashes. Once an inactive app, it now is one of GitHub’s 2019 fastest growing open-source projects with 7 million monthly downloads and is a great, stable, and reliable open-source tool for developers, designers, and QA testers. Yet, for all its popularity, I’ve only recently started interacting with it professionally. In the spirit of sharing, here are my top five facts to know and love about Storybook. Imagine the following:
You’re working on a new element of a web application, perhaps a new page, button, or form. To get to where that element will be added, you have to sign in, create a user with the appropriate permissions, trudge through the steps to properly interact with the UI to finally get to where this element is visible. Make the change, rebuild the app, and repeat this scenario 10-50 times, and that’s building front-end UI.
But fortunately, Storybook holds all of your application’s UI bits and bobbles in one place, like a tacklebox, and makes sharing and reusing pieces across the application easy. Put simply, it’s an app about an app. The form can submit, and we know it works because it looks and feels just like the last form we used successfully!
Storybook has its own Storybook containing their design system, which is a great resource you can follow along with while going through my tips.
1. It’s useful… as a developer
It is very compatible
Storybook is cleverly built to play nice with popular front end tools like React, Vue, Angular, Web Components, and more. It has, for example, documentation on how to get started for React, Vue, and Angular apps. Whatever you’re using in the front-end, Storybook will most likely complement it (especially since HTML is also supported).
Also, there are many add ons to keep your software best practices consistent and strong.
It gives direct access to front-end code
A team can create workarounds with an “admin view” or certain build-time configs, but there’s always a need to interact with the application while making the thing. Storybook gives you the ability to build components in isolation. Now you can make the visual of something without the fuss of integrating it into the necessary page, or you can have the opportunity to temporarily scaffold the data and leave the business logic to another time.
2. You can build enduring documentation
As mentioned before, there are many add-ons available. When you install Docs, for example, a DocsPage will be available for every story (each representing a single visual state of a component). A lot is available by default, built by sourcing information on these components so a team can build front-end features confident that it’s maintaining consistency. DocsPage requires zero configuration for building a page, so it lowers the burden and responsibility of typing it all out. Iconography and color themes can live in one place, right next to how it’s coded. This aids a team in consolidating documentation, removing bookmarks from our bar, promoting the healthy practice of accurate and dependable engineering notes.
However, testing is available in Storybook with a level of flexibility that allows a developer to focus on different aspects of the UI, such as structural, interaction, and testing the styling; here’s a great tutorial on learning how to leverage your testing within Storybook.
4. Compatibility with design tools
There are add-ons available for design handoff with Figma, InVision, Zeplin, and Abstract, which connects design to what components resemble within Storybook. This helps make it a one-stop-shop for developer and designer collaboration. Some, like Zeplin, adds linking between itself, Storybook pages, and other useful tech tools like GitHub and Confluence. Having this kind of closely coupled team keeps the feedback loop active and collaborative. Which, when your team is at its most effective with their design, all these ideal practices and tools become a design system.
Design systems are the infrastructure of a front-end application; it encapsulates the evolving map of a brand to keep it centralized in one place. If your team is building a design system, Storybook offers an excellent open-source solution that can help improve code reuse by 41-80%. In essence, if you find all the previous points worth jamming to, you’re already in the process of creating a design system! Check out this blog post by Storybook which highlights a few well-known companies using Storybook for their design systems.
5. But it’s not good for every app or project
You need to begin Storybook with a strategy
Beginning with Storybook means you’re building a system and building an application. It’s essential to plan out how your team will begin working with it. I work on a large engineering team, and a separate team from mine set this up and maintain it. Therefore I have established support and assistance whenever I run into trouble, which not everyone will have. I’m not learning about this app from its inception, so my experience has been with an existing Storybook system. Ultimately, adopting Storybook means another app to maintain along with whatever else you or your team is tasked with, so having a strategy and system of how to support Storybook is recommended before diving in.
Storybook’s contributor’s have themselves identified common pitfalls and frustrations, which they feel are necessary to be aware of.
For example, three places people tend to get stuck when working with Storybook are:
- New Storybook apps can be difficult to set up because of the overwhelming possibilities. Your team should want to explore a design system or at least discuss the current pain points of its front-end dev work.
- Teams can become frustrated with the process of keeping everything up to date and integrated. Having a team dedicated to owning Storybook is beneficial, and can serve as a go-to for leveraging the add-ons available.
- The need to customize Storybook is sometimes a frustration for teams using Storybook. However, there has been a lot of progress to add more customizable features. Here are some tools I know about that give you flexibility. For example, you’re able to use the theming add-on to do much of the overhaul. Additional customizations may be helpful for configuration presets as documented by the Storybook Preset API. But perhaps, this also lends your team the opportunity to build a cool new add-on for Storybook enthusiasts to try out!
Not for hobby projects
My experience with Storybook comes only from a professional setting, but if I ever develop a personal project complex enough to need a well-developed design system, then I would adopt Storybook. As for now, for my usual hobby programming projects, Storybook is excessive. Hobby projects might not need Storybook.
Front-end development has a lot of moving pieces; keeping them in order will provide a benefit to your user’s experience. Oftentimes, the work to unify the efforts of design and developers adds to the confusion, like a game of hot potato over a brick wall, where eventually the potato turns into a green ball, a pineapple, or never returns at all. It can be overwhelming to maintain excellent UI, and bugs can come from surprising places.
When your engineering department wants to invest in a tool to use, folks certainly want a tool to stick around. While it was once an abandoned project, Storybook is now a funded and maintained open-source tool with an active community and a guided steering committee. It receives regular sponsorship from well-known companies, and your company can even help keep the spirit alive if you like it enough to sponsor it!
Storybook gives structure to the front end development as well as creating a place for design systems and documentation to live. As a software engineer, I live with wild stories of design and development inconsistencies, but Storybook helps to eliminate many of them from being a problem in the future.