Please note! This is a brief summary of my work. The images used in this case study are highly detailed, and difficult to consume in this format. I'd be happy to present a more detailed case study at your convenience! grgsmthdsn@gmail.com

I was part of the zero-to-one effort that built the first centralized, governed design system library at Walmart. I designed and documented a governance workflow to achieve two goals:

• Improve the agile collaboration process on our team.
• Socialize our team’s methodologies to manage user expectations.

When Walmart's design system team was new and growing, we needed to establish a defined set of processes that would add structure to our team, and serve as a public SLA (service level agreement) with our users. A few examples of the basic things we needed to define and document:

Internal

• What does it mean to design, develop and ship a reusable component on all platforms? How long should that take?
• What tools and artifacts will we use in our work? What are the expected deliverables?
• How are the collaborate methods and standards for design/eng/a11y?

External

• What is the design system team responsible for?
• How do I interact with the team when I need support?
• Will the team commit to my feature request? If no, why not? If yes, how long will it take?

The first process I defined and documented was the basic lifecycle of new work. Clearly defining the steps involved in zero-to-one work on library components would also help us define updates and iterations. It would help us educate users on the nature of feature requests and contribution, and it would help manage user expectations.

This is an excerpt of v1 of our team process. It became an artifact that we referred to as a team, to improve collaboration. We used it in communication with product teams, so they could understand what's involved when they engage us.

As the team took on more (and more complex) work, I continually iterated this documented process to add clarity and structure.

Again, the screenshot below is highly detailed, and difficult to consume in this format, but it's a good demonstration of how we were rigorous in the way we defined our work. I'd of course be happy to go deeper into the process and methodology defined below, directly in Figma, in a full case study. 🤓

A zoomed-in sample:

The cropped section below shows a bit more clarity. This represents our efforts to define every step in our team's process. The idea was that, if all steps could be accounted for, we minimize the chance of shipping artifacts that fail to meet user needs.

The intricacy of this workflow proved to be challenging in the course of a busy, demanding team sprint. It's important to find a balance between progress and process. Too much process can hinder progress.

Tested over time, individual sections of this documentation were helpful tools to introduce new team members to the intricacies of design system work. But, taken as a whole, it was difficult to use as a strict tool for team collaboration. Team members need to be trusted to manage their own individual tasks with a bit more freedom.

Simplified approach

As a design system (and its team) gains maturity, it's easier to embrace the progress-over-process ideal. Individual team members have a more concrete understanding of expectations. It's important that we hit key milestones in our process, but it's more important that we do so with realistic velocity.

Defining a process more simply allows the team to adhere to the most fundamental best practices, while not getting bogged down in micro-management of their work.

Modify for scale

A well-established design system process can be implemented in other parts of the business. One of my most impactful projects while at Walmart was to embed with an enterprise product team as the design system SME. I created a modified version of this process that conformed with the goals of that team.

Product designers can quickly and easily adhere to this workflow, with some design system oversight, and any system artifacts they deliver will be more likely to meet the established standards of the core design system.

Processes vary based on the project intention and the requirements of the product design directors, but if we adhere to the skeleton of the design system's methodology, we deliver reliable components and patterns, and our users have a clear understanding of our role and our timeline.

I welcome the opportunity to discuss this project in more detail, as well as more of my design system work! grgsmthdsn@gmail.com