Pattern Library Workflow
Just about a year ago, I started working at Allstate. Myself and my team of two UI Engineers and a Design Lead established a Pattern Library that has been very successful. With the success I decided that it would be a good idea to share our workflow in an article.
For starters we have the four segments that every Pattern Library is structured with. These start with fundamentals that translate into the coded components and then we bundle together those components into templates. Finally the production ready pages built from the templates and are distributed inside of apps.
- Fundamentals: Colors, Iconography, and Typography
- Components: Buttons, Form Fields, Accordions, etc
- Templates: Starter Kit and collections of Components
- Pages: Implementations of the Templates with integration with the backend and the final copy ready for production.
These segments really help isolate the inner linking dependencies on each-other. Where if we were to update a component we’ll most-likely need to update some templates and so on.
The Governance Model
Our governance is structured to have different practices branch off but come together as a community for contributions directly to the Pattern Library. The Pattern Library’s Style Guide or Sketch file is maintained and managed by the Designer Librarian role while the Code Base, Deployments, and Bug Tracking is maintained by the UI Developer Librarian role.
The Pattern Library is the source of our tools, our “Life Blood” if you will. The Librarian’s are constantly collaborating on introducing enhancements to the Pattern Library and making the hard decisions when it comes to introducing new Patterns to the library, thus that’s why their called “Librarians”.
The responsibilities of both Librarian roles aren’t just limited to maintenance and actually have a lot of support and training efforts. Let’s say a team is interested in using the Pattern Library’s resources, they’ll likely need questions answered or on boarding to the resources. The Librarians both work with project teams on that.
Our Workflow is similar to any other design process. The “Discover” phase is a collaborative effort between the design teams and the Designer Librarian. They will focus on delivering what’s needed for the project to the Developer Librarian/s. The output of the “Define” phase is to produce the Pattern in the Sketch Style Guide. Once that’s completed the Pattern will go into the “Develop” stage. This is where the Developer Librarian will code and document the Pattern in the Living Style Guide producing something that can be consumed by the project team and others.
Establishing Patterns
To produce Patterns we use a lot of tools to gather requirements for each Pattern. It usually starts with a designer reaching out to the Designer Librarian on the dedicated Pattern Library Design Slack channel with a need for a new Pattern. It will also come from designers directly where they create a new design and then submit it as a future Pattern in Trello or Slack. The last place we get them is from unmet needs from the developers on project teams. They’ll submit a request into the Github Issues instance for the Pattern Library source code.
Once everything is centralized to the Sketch Style Guide it will get deployed out to Zeplin, Invision, and for designers the Pattern Library document where they can download the Sketch file to start using in their own projects.
After we have the design we stage them with our internal stages.
- Snowflake: A single instance of a component or design that isn’t recognized as a Pattern for the foreseeable future.
- Submitted Design: A design that has been recognized as a future Pattern
- Refinement: The stage that the creator/inventor of the Pattern will participate in with the Designer Librarian to add any missing requirements and match up with the fundamentals of the Pattern Library.
- Pattern: The stage where the design has become a Pattern and can start being developed into code if it hasn’t already started.
Snowflakes won’t always stay snowflakes and we regularly keep a list of all instances so when we produce a new Pattern or have a business need where that Snowflake could help we’ll start the Pattern process on that Snowflake. Once that process is complete we’ll take the Pattern and go back to any teams that could use it and remediate the existing Snowflakes.
Code Features and Bugs
For the development it’s a lot more straight forward. The Developer Librarian will collect the new Patterns from the Sketch Style Guide and add them to the Pattern Library through a Github Issues backlog. The Librarian will also get requests to resolve bugs from project developers in the Github Issues backlog and through the Pattern Library Developer Slack channel which will be prioritized and addressed in the Pattern Library.
The Patterns are then all deployed out to developers through a Node Packages where they can update their projects to the latest version and start using them.
Pattern Library Deployment Process
The code for the Pattern Library is all hosted on a Github Enterprise repository that holds a Github Issues backlog. That backlog is broken down into semantically versioned release names using Github’s milestones.
Once a milestone is reach by the end of the week it it will be consumed by Jenkins. Jenkins will build the code and deploy it out to a private Node Package registry called Artifactory. It will also deploy the document site on to our host Cloud Foundry.
The code can then be consumed through all different sets of tools including NPM (Node Package Manager), Yarn, and Javascript by just including it into a projects HTML script tag. The favored route is to install the package to a project using NPM through Artifactory.
The coded Patterns are produced using Facebook’s React library and are components that can be consumed by our other projects using React. It’s also important to note that we break out our SVGs into a separate Node Package called “Icon Library” because it’s a lot easier to have them isolated then in the same Package.
Additionally we internally consume the coded Patterns identically to the way our developers do in the Pattern Library Living Style Guide to prevent any issues where our Patterns would work in our instance but not theres. We achieve this by maintaining them as isolated projects within the Github repository but consume them as symbolic links instead of through the registry for development.
For a detailed look at the way we have this working here are all of the technologies we have to build our Node Packages.
The Pattern Library Living Style Guide is also a React project and uses Webpack to build all of the documentation for deployment.
Going Further
With the experience that we’ve gotten within the year it makes sense to us to expand our governance model to include a coach role. These designers and developers will contribute their time for support and being a voice for the Pattern Library initiatives. They can help with refinement of Patterns, Snowflake remediation, or help with the issues developers might have integrating the Pattern Library code into their projects.
Additionally I’m really interested in producing Patterns for multiple frameworks such as AngularJS while also theming the coded Patterns so that they can be more versatile.
It takes a lot to be a Librarian for a Pattern Library and some would call us Unicorns. Unfortunately Unicorns don’t exist, but Narwhals do.
If you’d like to read more about this project I wrote another article going over the process of setting the Pattern Library up.
