A product-driven approach to building a design system that designers love and trust
Company
Walmart
Product
Me@, mobile app for Walmart Associates
My Role
Product designer, design sub-system creator & manager
Timeline
March to August 2024
Background
All of Walmart’s digital products are governed by a master design system called Living Design, which close friends refer to as LD.
To ensure brand and design consistency, foundational elements from LD, such as atoms and molecules, flow downstream into Walmart’s various sub-systems.
Foundational elements from LD are used to build additional molecules, organisms, and templates within each sub-system.
This case study focuses on how I created and refined the Associate Experience Sub-System, which supports the Me@ mobile app used by over 1.5M Walmart Associates to assist them in their daily work.
Pain Points
1. Too many library files
Designer searches for home screen component.
There are 5 different files with published Me@ components. No one knows what the source of truth is.
Opportunity
Create a single library file with colors, text styles, and components specific to the Me@ app.
I address this pain point in Foundations.
2. Instances are not intuitive to update
Designer doesn’t understand what can be updated in the instance.
“Can I change the store number? How about today’s date?”
Opportunity
Leverage Figma’s component properties, instance swaps, and nested instances to surface updatable elements in the Properties panel.
I address this pain point in Updating Instances with Ease.
3. Components are not responsive
Designer resizes instance for a larger device. Mobile-first? More like mobile‑maybe...
4. Library updates cause anxiety
Designer accepts a library update. Fingers crossed...
This is one example of how most designers were eventually conditioned to never accept library updates.
Opportunity
Build robust components and thoroughly stress-test them before publishing.
I address this pain point in Ensuring Robustness.
5. The design system is getting in the way
I can work faster if don’t have to use the design system.
Opportunity
Ouch... This, along with the other pain points inspired the goal below, which became my work-life’s mission.
I address this pain point in Birth of the 10X Designer.
Credit: Character illustrations from Open Peeps.
Goal
Enable designers to work efficiently, stay on-brand, and maintain design consistency with a trusted and robust design system
Foundations
To solve the chaos of multiple library files from pain point #1, I started by creating a single source-of-truth library. The first step? Tackling the basics: color tokens and text styles.
Color Tokens: Simplifying the Rainbow
231 LD color styles
346 LD color tokens
Very specific but complex token structure:
While technically sound, this structure was built for design system experts. Its complexity could easily leave designers with analysis paralysis.
57
color styles used in Me@
based on thorough audit of key screens
68 Me@ color tokens
Streamlined token structure:
Under the hood, the new Me@ tokens reference LD tokens, keeping the colors in perfect sync, but on the surface, they’re far easier for designers to use.
My proposed user-friendly structure neatly categorizes color tokens into four simple buckets:
Guiding designers from color styles to variables
Since many designers I spoke with are intimidated by variables and tokens, I created a detailed guide to help them transition smoothly from the old color styles they’re used to into the new variables and tokens.
Text Styles: Less Is More
58 LD text styles
covering the gamut from mobile to desktop
21 Me@ text styles
trimmed down to mobile only
To ensure integrity with LD, the new Me@ text styles are linked to LD’s variables for font family, font weight, text size, and line height. This means that any updates at the enterprise level will automatically cascade down to Me@, keeping everything beautifully in sync.
Building Blocks: Molecules & Organisms
After establishing the foundations, I moved on to building molecules and organisms: reusable components tailored for the Associate Experience. These include key elements like the app header, bottom navigation, and various page and section headers.
Updating Instances with Ease
Remember in pain point #2 when our designer struggled to figure out what could be updated in an instance? That’s now a thing of the past. By leveraging Figma’s component properties, I made essential fields easily accessible directly in the Properties panel.
I applied the same approach to these components too so designers can now update key content quickly without having to dig into nested layers. No more guesswork!
Component Testing
To ensure the new components meet designers’ needs, I set up weekly feedback sessions. These meetings became a crucial part of the process, allowing me to fine-tune components and build trust in the system.
Here’s a template I used during these sessions:
Playground Area
This is where I drag in the component under review and demonstrate how it works. I go over the variants and show what can be updated in the Properties panel so designers can see in real-time how changes affect the component.
Changes from Old Component
This is where I highlight any differences between the old and new components, inviting designers to weigh in on whether the updates improve or complicate the design, and ensuring we’re all aligned.
Fine-Tuning
This section addresses remaining tweaks. Do we need more variants? Another size option? Designers can suggest adjustments to make sure the component meets all their needs.
Naming & Searchability
Designers cast a quick vote on the component's name (thumbs-up or thumbs-down). I also collect alternate names and keywords that I add to the component configuration to improve searchability, ensuring no component gets lost in the system.
Ensuring Robustness
In addition to gathering feedback from designers, I thoroughly tested how instances behave when used outside of the library file. I’m hoping this extra step will help alleviate designer anxiety from pain point #4 and convince them that library updates are not evil.
Icon color is preserved?
Text overrides are retained, even after switching variants?
Component resizing works as expected?
Auto-layout settings are preserved?
Nested components retain their state?
Ready-to-Use Screen Components
Now that the foundations and building blocks are in place, it’s time to assemble them into app-specific screens for the Me@ app. These screens serve as the source-of-truth, always reflecting the latest and greatest version, and are ready to be used in flows or as a starting point for new features.
Responsive & Prototype-Ready
In pain point #3, resizing components was like trying to stuff a square peg into a round hole. Well, problem solved! The screen components I created are not just responsive but also prototype‑ready.
As a bonus, I set up device modes for seamless switching between XCover, Android, and iOS. With one click, the screen resizes itself and the device artifacts are updated. It’s pure magic!
Change the device to see the magic happen
Modular Approach
Each screen component is made up of stacked sub-components, just like legos. Here’s why that approach is so powerful:
Designer inserts an instance of the home screen into an exploration file.
Designer detaches instance to insert a brand new section (yes, it’s ok to detach in this case).
Designer makes a bunch of awesome changes to the new section (feeling creative today).
Everything else on the screen stays linked to the original sub-components while providing flexibility to work on the new section.
Streamlined Library Structure
With the foundations, 10 screens, and 48 components all in one file, things could easily spiral into chaos. Not under my watch! I developed a meticulous system to keep everything neatly organized.
Each component is placed in its own page (left panel below), doubling as a table of content for the library file and an organized reference for external files that link to the library. Here’s a closer look at how each page is structured:
This component sheet neatly showcases the final component.
Who to contact? The name hyperlink opens a new Slack message for questions about the component.
Indicating that this component has modes and interactive elements when used in a prototype.
Clearly labeling each variant for easy identification.
Supporting components used in the main component above, but not meant for standalone use. To avoid cluttering the library, these are not published.
The component sheet neatly showcases the final component.
Who to contact? The name hyperlink opens a new Slack message for questions about the component.
The tags indicate that this component has modes and interactive elements when used in a prototype.
Clearly labeling each variant for easy identification.
Supporting components used in the main component, but not meant for standalone use. To avoid cluttering the library, these are not published.
“Automagic” Organization
Manually organizing all of this? No thanks! I used the Scripter plugin to write and run automation scripts, cutting hours of tedious work down to just seconds. Check out the demo video below to see how I transformed a messy pile of freshly built components into a setup Marie Kondo would approve.
Inspiring Innovation
The impact of this organized system extended beyond just efficiency. Other designers took notice and began applying similar structures to their own work.
Hello there! I’m a designer on the data experiences team. I’ve been stalking your subsystem file 👀 It is SO GOOD. I just started working on a new customer data platform and building out a whole new subsystem library for it so I went to your file for inspiration.
Utility Library: The Indispensable Companion
The Component Sheet above is a perfect example of what the Utility Library offers: a collection of must-have resources that empower designers to move from idea to execution with maximum efficiency.
Here are a few designer and engineer favorites:
Callouts
This versatile little gem is by far the most popular component among designers.
Great for documenting design decisions for a new feature:
... or for annotating specs in a development hand‑off file:
Project Management Templates
Giving designers a consistent framework to quickly get started on new projects and stay organized, without having to re-invent the wheel.
Versioning Template
This is like a time machine all bundled up in a neat little table, giving designers a snapshot of the entire history of a screen or feature while clearly highlighting the most current version.
VQA Template
Engineers especially love this template because it provides a clear overview of all issues by priority level and saves time compared to live review sessions.
Birth of the 10X Designer
Between the Utility Library and the revamped Associate Experience sub-system, designers now experience the system as a support tool that enhances creativity rather than being a blocker, as was raised in pain point #5.
Impact
Although the Associate Experience sub-system is just on the verge of being officially released, its impact is already clear:
Creating Buzz
Designers who have been involved in testing the sub-system are eagerly waiting for its full release. This excitement has spread across the entire Associate Experience team, generating anticipation for the broader rollout.
Cross-Team Influence
Other teams are already using the Associate Experience sub-system as a model for their own libraries, reflecting the effectiveness of its structure and the thoughtful organization of components. Even before its official publication, the sub-system is shaping the way other designers work.
The Utility Library is another example of the growing impact:
Widespread Adoption
Despite the fact that it hasn’t been publicized, the Utility Library is already in use by 18 teams across the organization, well beyond its original scope. Designers who see these utility components in presentations or feedback sessions often request to use them in their own files.
Feedback from Engineers
Engineers have praised the clear design-to-development handoff. They especially appreciate the effectiveness of the VQA template in ensuring perfect alignment between design and code.
Retrospective & Learnings
Too Many Cooks in the Kitchen
The original open-source sub-system suffered from inconsistencies and lack of structure. With too many contributors and no clear guidelines, the components weren’t built properly. Establishing structure and a streamlined process was essential for success.
Designer Feedback Is Crucial
Involving designers early on not only ensured that they would actually use the new components, but also boosted excitement and buy-in. Their feedback was pivotal in refining the system and tailoring it to their needs.
Quality Over Quantity
In an earlier attempt to revamp the sub-system, the focus was on building everything at once under a tight deadline: all components from the old sub-system plus documentation. That spread us too thin and affected quality. As a lead on the second attempt, I prioritized key components first, leaving documentation for later. This shift resulted in better quality, stronger designer buy-in, and ultimately a more successful system.
The Right Amount of Documentation
Dense, text-heavy documentation from the old sub-system was intimidating and rarely referred to. Keeping text to a minimum supported by visual examples resulted in more engagement and better usability.