Tighten the Feedback Loop with Published Storybooks

On a recent React web project, we updated our continuous integration server to automatically publish Storybooks. It’s been an exciting change. If you aren’t familiar with Storybook, you can check out any of these other Spin posts for an intro. Short version: It’s a tool that lets your development team build pieces of a web app in isolation with way less overhead. But, as we discovered, when you combine Storybooks with a continuous integration pipeline, you create a tool that can speed up design review, business review, and visual testing. Here’s how we’re leveraging Storybook on my team.

How We Publish Our Storybooks

Publishing a Storybook in CI is insanely easy. You have to run one shell command:

yarn build-storybook -c .storybook -o dist/storybook

Then you can copy the resulting static website files from dist/storybook onto any web host. For my current project, we’re using
AWS S3 and CloudFront for static asset hosting, so we run one more shell command to upload everything:

aws s3 sync dist/storybook "s3://our-development-assets-bucket/storybook"

With those two lines in our continuous integration configuration, we were able to add privately published Storybooks to our project.

Benefits for Developers

The development advantages of using Storybook are thoroughly documented, so I won’t bore you with platitudes here. But our team has reaped some unexpected benefits by publishing Storybooks. In the past, our code review cycle went something like this:

As the developer

1. Write a new feature.
2. Publish a branch to GitHub and write testing instructions.

As the reviewer

1. See that a new feature has been published.
2. Read through the testing instructions.
3. Download the code.
4. Realize that you have unstaged changes.
5. Stash your changes and check out the new feature branch.
6. Run Yarn to install any new dependencies.
7. Hope that nothing else conflicts.
8. Run a command to serve the app and the Storybook.
9. Launch a web browser and try out the new feature in the app.
10. Launch a web browser and try out the new feature in Storybook.

With automatic Storybook publication, the new process is more like this:

As the developer

1. Write a new feature.
2. Publish a branch to GitHub and write testing instructions.

As the reviewer

1. See that a new feature has been published.
2. Read through the testing instructions.
3. Click a link to open the Storybook.
4. Click a link to open the app.

Benefits for Designers

Because our Storybooks are now just a click away, getting early feedback from our designers is easier than ever. Instead of waiting until a feature has been fully developed to get design feedback, we can trivially send a direct link to the in-progress build over Slack. With that link, a designer on the team can play around with the new feature in isolation. They can see how it feels in a real browser without having to set up an entire development environment. On my team, this has led to faster feedback and easier collaboration between devs and designers.

Benefits for the Business Team

Historically, business review has been one of the last phases in a story’s lifecycle. Because it requires using the actual production application, it only really made sense to integrate the business team when a feature was fully tested, built, and deployed to a staging environment. Even then, business review often involves many manual interactions.

With published Storybooks, we can bring members of the business team into the process sooner. Because it’s so easy to set up many configurations of a visual component, we can work with the business team to set up visual test cases for common kinds of data.

Recently, for example, we were building a new chart to visually represent each piece of a product’s cost structure. As a development team, we worked with folks on the business team to identify a few common situations for the component: revenue-positive, revenue-negative, and not-enough-information.

Publishing your project Storybook helps developers build visual components faster, designers give feedback quicker, and business operatives give input faster. Our team has been able to move forward together with less friction and tighter collaboration. With those examples in mind, we were able to build Storybook stories for each case and directly link those stories from within our testing instructions. Instead of clicking around the application to find real data that fit every test case precisely, our business team was able to click a few links to see how the new component would behave in each situation.