WestRock Design System

Design Operations / Component Library / Styleguide Documentation
The Situation
With so many products in the production pipeline, there needed to be a resource for everything to align around. A “North Star” to point the way acting as a single source of truth.
There are at least eight different products in the works that the UX CoE is touching. The purpose of this design system is to provide templatization of both a component library for prototyping and ideation purposes, matching documentation, and codebase to reduce build time, implementation, and training turn over.
This benefits product teams at scale.
My Contributions

Sketch Component Library

I created and organized a Sketch library to share with the rest of the design team that contained components with approved branding applied to Material-UI.
Along with this, we created a documentation site for the Material UI side and a code base site for all of the WestRock specific molecules, organisms, and patterns.

Developer Portal

The portal is a web-based documentation site providing visualization and code base to all of the UI components contained in the library and style guide. It also aides development with a guideline for responsive design cues and accessibility.
The portal will scale as use cases expand. In the beginning, we were working with React specifically.
My contribution to the portal side was updating metadata where needed. Most of it stayed out of the box. We didn’t get a chance to write material for our specific items like data-table treatments.



Everything was new so we were feeling out the best tools to use for our process.

Typography Scale & Rendering

Selecting the appropriate fonts to go with universally was an issue from a performance standpoint.

Rendering was misleading between Sketch and the browsers. To address this everything was pulled into a project called BlueSky that represented the design system as an end product. All of our commonly used components could be seen rendered on a page. Ultimately, the Sketch file is a means to an end but the code rendering in the browser is the real end product, the moment of truth.

Ultimately, the Sketch file is a means to an end but the code rendering in the browser is the real end product, the moment of truth.

Cross-Functional Teams

Teams within the business who own digital experiences in other places in the company structure (apart from the enterprise product lines) already kept a digital style guide as they were trying to address problems we were addressing. But, it was unclear how much they knew about the UX CoE and if there was a working relationship. We were solving the picture with a 30,000 foot perspective vs their 1,000-foot perspective. There was communication that had to occur to paint a picture of what the design system included outside of a Sketch file, style guide, etc. and why it was different from their “static” document.


Azure User Stories

I used Azure to manage updating the team when each component was complete or in progress. There were also story points associated to gauge the importance of task prioritization.  In the comments field, I could leave development a note to where they could find the components in both the Sketch file as well as the Invision Inspect view for code or asset access.

Sketch File

Design systems are a living, breathing product all on its own. Maintenance and further build out never ends as best practices, patterns, and even brand treatments may change over time. And it is essential to collaborate and help contribute to its growth by preventing a siloed design model.

We decided that our products would have a Google Material flavor and the development strategy was to do everything in React. My mission was to match all of the React components out of the box with our branding within Sketch. This file was shared using Sketch Teams, Microsoft SharePoint, and Invision (for static and CSS code view). I used these methods because we were basically beta-testing Sketch Teams in our workflow and SharePoint was essentially a “free” access point since we use it heavily throughout the enterprise.

The design system should always be tech agnostic and visually match and hold the same UX regardless of language. Our decision to choose React was just a starting place.

The Sketch file contained the standard core portion of the UI, and then we had WestRock specific components and patterns. This file also contained designer specific information as well and was uploaded to Invision.

The WestRock specific components are informed by federating the design system out to all product lines and creating a feedback loop. But the design system was sort of siloed, to be honest. I don’t recommend this. It’s better to make things globally accessible and federate the design system with all of the various products we have going on.

Documentation Sites

Things were new so we were trying to feel our way through as we started up. For documentation, we had our Material UI documentation which was a cloned Github repro that we modified. Storybook is what we use for the WestRock specific components and pattern code base.


Version 1.0 and 1.5 Releases

Write up is currently in progress.