For those who aren’t familiar with the concept of Pattern-Lab (or a Pattern Library), it’s essentially a living style guide; a common tool in modern web development. At their most basic, they are continuously updated documents that help documenting common design styles for web components, bringing together the intended look & feel with the images and codes to build them.
I started to look into this idea around a year and half ago because I found that each time a new project started, I needed to redo much of the same styling work. Even worse, when the main project was still in development, it was hard to keep an eye on the minor changes that affected other projects, so they would quickly get out of sync with each other. There wasn’t a centralised place to store reusable components. Unfortunately, my initial attempt to push a “shared Pattern-lab” idea didn’t work too well because we had difficulties integrating with various tools and workflows across teams.
Our Pattern-lab reduced duplication of effort as it’s ensured we have a library of reusable components that are common through all our main products. Additionally, this is giving us more consistency in our newer sites therefore reducing the time it takes for us to deliver. It also means that we now have a one-stop reference guide for both designers and developers working on all our projects.
To summarise, the Pattern-Lab is built on Node and using NPM, with the styles themselves being written in SASS and style guide generated by KSS. Every time a pull request is opened on Github, a preview version of the Pattern-lab is deployed to Netlify with Visual Regression tests run with Travis. Once code has passed review and been merged into the master branch, the latest release is automatically pushed to NPM and deployed to production by Concourse.
More details and documentation can be found here:
One stand out feature for me are the visual regression tests we put in place. These make sure that existing styles aren’t accidentally changed unintentionally when we add a style or make a breaking change. A big benefit of this is that now they’re integrated into our CI pipeline, if the tests fail, the code will not be released. It’s particularly important to make sure that we don’t break one product’s styles while trying to fix another!
One of the potential future additions is to extend this to include automated accessibility checks. These would ensure we do our best to make all our sites fully accessible while we can also add unit test coverage reports so we can make sure we cover any areas that have been missed by our regression test suite.
For me, it’s taken a long time to get this far, but I’ve been really happy with how various teams were able to work together to make the idea into reality. We’re getting a lot of great use out of our Pattern Lab and I hope it helps you if you ever encounter any similar issues.