Experiences Developing a Pattern Library
Just about a year ago I joined Allstate and was given the task of assembling a way for developers to collaborate and share code. After a few conversations and some digging through the source code it was understood that the development being produced couldn’t easily be used project to project because of it’s loose standards and narrow implementation.
On my second week I decided that the best strategy was to establish a Pattern Library with my colleagues by using what existed but refining it into reusable components. Centralized to me was a team of two UI Engineers and a Design Lead, which is small but could accomplish the task.
Together we spent our first few weeks dedicated to putting together the Pattern Library’s living style guide codebase, gathering requirements from existing designs, and establishing nomenclature with all of the designers in two workshops. Once names were established for every component we started to add them into a living style guide and a Sketch document allowing us to start building out components.
The cadence we decided on was to release weekly Node Packages from the code base, update the Pattern Library site, distribute the new Sketch Style Guide, and document the new designs from the Sketch document into a Github Issues backlog every Friday. Starting Monday every product team could update their codebase with the new updates and we could start working on the Github Issues backlog for that upcoming Friday.
We also built the Pattern Library with an InnerSource model in mind and allowed for everyone to contribute code, submit bugs, and request new features.
Some of the challenges we faced through-out the year specifically pertained to the following.
- In the first couple months we had growing pains with developers adopting the code but not having enough from it to build something useful.
- Setting the standards and expectations for our team so that we’re helping communicate what’s needed to be in the documentation and included in the code.
- Setting expectations with the developers and designers on the product teams so that they could know when to expect their contributions in a release.
- Developing a governance model that would allow for remediation of larger collections of components in the developed products.
We resolved our growing pains by prioritizing better with the teams so that we could deliver what they needed when they needed it. This also helped resolve the expectations we were missing with our product teams as well. Our standards took a short while but we had a few conversations and documented them and it wasn’t to terribly hard to get everyone on the same page. The governance model is something we’re constantly working and hope to get it a less iterative state but it’s a lot like the Agile methodology and how you’re constantly improving on it.
With all of this it’s been very successful and we’ve gotten more than twenty development teams using it today and more on their way. It’s truly been a thrilling ride and we have plans to grow further from here.
