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.
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.
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.
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.
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.
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.
A collection of core components ready to be used in WestRock internal applications when building inside of Sketch synced with Storybook.
These were loaded into Sketch Cloud giving the UX team and stakeholders access to all of the components to be used as a Library. It essentially included a small collection of common form elements. Most of these items would be considered what you would see in a Core component file. There's a lot of lessons learned on this project. I will add a section covering my reflection on this project since I've had four years of design system experience since creating this.
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.
If you like what you see and want to work together, get in email@example.com