Wayfair Tech Blog

Case Study: Using Storybook to Enhance our Frontend Developer Experience


Here at Wayfair Engineering, we're aggressively migrating our monolithic systems into decoupled (independent) libraries and microservices. Decoupled libraries and services allow us to build faster and deploy more frequently, but they can create discoverability and software testing challenges. In this blog post, we'll show you how we used Storybook to solve some of those problems for our frontend codebase.

When we chose to use Storybook, we knew it would greatly enhance our frontend developer experience. For example, Storybook provides hot reloading (i.e. reloading a UI component live as code changes are made) which increases developer velocity.

We also knew that Storybook has a large community backing, which allows developers to leverage guides written by that community. With big community backing, Storybook has various amazing addons built in that make it extremely customizable, such as Storybook Controls (see screenshot below) which allows live editing of React Component arguments in your stories.


Finally, one of the biggest benefits of Storybook is facilitating easy discoverability of frontend components across teams. As we thought about our long term vision for developing in our decoupled environment, we wanted to answer the following question:

How can we allow our QA, PMs, designers, and engineers to view our React components without needing a local development environment?

We knew that a viable answer to this question would further improve our software development in two ways: we could receive feedback as early as possible in the development process, and we could promote collaboration by allowing potential consumers of our library to view our components.

Given these potential improvements, we pushed forward with the idea of not just using Storybook for local development, but also deploying a functional Storybook site to a static site hosting service in an automated manner.  We’ve called that Automated Storybook Publish and considered it a requirement for completing our frontend decoupling work.

There were a few different steps necessary to unlock Automated Storybook Publish:

Step 1 - Build Storybook as a static web app

We needed to build Storybook as a static web app so that we could then deploy it to a static site hosting service in Step 2 below.  Luckily, the creators of Storybook already created and documented a workflow to Publish Storybook so we were able to leverage that.

Step 2 - Figure out where to host the static web app

By hosting Storybook, people wouldn’t need a local development environment to see our React components as they could just view our team’s Storybook online.  For this, we used Github Pages since every engineer at Wayfair has a Github account.

Step 3 - Automate deploying the built Storybook

Once we figured out the first two steps we were able to manually deploy a built Storybook to Github Pages, however, we wanted the Storybook Publish to be automated so that whenever we merged new code to our library our Storybook would get re-built with the latest changes we merged in.  For that, we were able to use Buildkite which is a platform for running continuous integration pipelines.

As a team, we love developing in our decoupled library compared to developing in the old monolithic application, and one of the main reasons is Storybook (plus Typescript, although that’s a discussion for another time 😄). 

Storybook usage has already made a significant positive impact on cross-team communication. We’ve easily demoed our team’s components to other teams from our production Published Storybook, which in a few instances has resulted in teams realizing that a component they might need in the future already exists in our library.  Additionally, having the ability to Publish Storybook for particular development branches has facilitated better collaboration with partner teams while we’re doing development.  For example, there have been times when we thought components from Wayfair’s central UI library were behaving unexpectedly, so we shared our Published Storybook development branch with those components’ owners who could then see what we saw without needing to check out our branch, launch Storybook locally, and comb through the site to try and find the issue.


Wayfair Testimonials: Using Published Storybook

From Engineers: 

“I dig it”

“Made setting up [feature in A/B test] really easy.  Big fan.”


From Design:

“I like being able to interact with [features].  Very helpful especially not being able to do OTS [over the shoulders] live.”


From QA: 

“It's been good to test on Storybook, it gives us a valuable head start to look at the design and functioning of components.  And it’s quite simple to use.”


Overall, using Storybook has been a huge plus both inside and outside our team so we highly recommend trying it out if you haven’t already.  Our future plans for Storybook at Wayfair involve looking into using Storybook Composition at a large scale, which would allow many teams’ UI components to be seen all in the same place.

Screenshot of our Sale Flag component in storybook