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. The core tools for this were Sketch and Invision. Figma could just as easily been used as well which we were using on the eCommerce side of the house. Some practices will have assets available in both formats to share out based on need. I've noticed some moving to only support Figma if most of design team is distributed.

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.

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

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

A collection of core components ready to be used in WestRock internal applications when building inside of Sketch synced with Storybook.


This was my first dive into design systems and my knowledge has deepened quite a bit. It's a bit embarrassing but it's a great thing to look back on my journey from where I am now to where things first started.

This system was intended to support a handful of products. The design system needs to be established as a product in its own right. Complete with its own marketing, onboarding, tooling, education, and communication funnels. Additionally, a funnel for adoption is necessary. Not all teams will want to use it as was the case at WestRock. Some products were already being built so a strategy for adoption for them would need to be taken into consideration. The design system team needs its own dedicated engineering team to be successful. It takes a village!

If doing this again, I would establish feedback loops for all consuming product teams. Establish office hours so teams with questions could get some time with us every week. Run a UI audit across the entire landscape of internal applications and tools that are effected, consider if both a Sketch and a Figma library are needed, establish a component design and build process including an Accessibility team or devote a step to it, do not include components that are not yet identified as a need to prevent boiling the ocean, get early and often feedback from all product teams, and much more.

Things need to be more of a stand alone product that makes the lives of designers and developers easier. The team supporting this was incredibly small. We would have needed a larger group in the end. The teams at Vanguard and Walmart are much larger and building their design systems on a full-time basis. In some cases, they are getting strategy guidance from outside luminaries in the field because not all of the knowledge always exists internally. But the internal team can work with these luminaries and execute internally as they learn. Everyone is on a journey!

In the end, I was grateful for this experience but I definitely would not do this the same way again. But, I did learn that I enjoy design systems work. It's definitely something that could be a specialization.