Everything was new so we were feeling out the best tools to use for our process.
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.
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.
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.
Write up is currently in progress.