Introducing the Mode Design System
Building a shared experience language at Stitch Fix
Mode
1. a way or manner in which something is experienced, expressed, or done.
2. a fashion or style in clothes, art, literature, etc.
3. the design system that supports our digital product at Stitch Fix
The Mode Design System was created to support higher quality digital products that are compelling, consistent, and inclusive for everybody. The Stitch Fix client experience is the heart of this goal, but the design system is used and informed by product teams who create these wonderful digital products.
Our company culture is guided by a set of principles called the Stitch Fix OS. When we set out to create a design system, we knew that our product teams were already operating under these principles as business units. But even though individual teams exemplify these values, we lacked a larger community across our product teams which made it difficult to share knowledge and partner cross-functionally. As designers, we found ourselves creating bespoke solutions far more often than was necessary.
But — rooted in these values — our teams were beyond ready to accept a new way of working together under guidance from the Mode Design System.
It’s been my privilege to help create, kick off, and grow the Mode Design System over the past year. In this article, I’d like to share some of personal takeaways over the past several months of creating and developing Mode at Stitch Fix.
A Brief History
The design system was an idea in the making for years before the true problem to solve coalesced and before we were given the runway to make it a major strategic initiative. Eventually, with the support of leadership, we were able to form a new team called the Design Platform team. Design Platform would focus on scaling the design of Stitch Fix products by providing product teams with systemic guidance, tooling, automation, and process improvements. The design system would be our primary product.
So What Problem Are We Trying to Solve?
How will we continue to design and build consistent, engaging products at scale?
You could outline our org chart in the inconsistencies between product experiences.
Over time, our customer experience had become fractured. There were unintended, yet noticeable, differences between interface and interaction design depending on what part of Stitch Fix you were experiencing. You could essentially outline our product org chart in the inconsistencies between product experiences. Systemic changes needed to happen to the ways our teams designed and built product.
It was an ambitious goal that couldn’t be solved by any single framework or library. What we were actually talking about was fundamentally changing how our product teams communicated about design. If we could set up the foundation for standards and practices, communication, and feedback, we could develop the experience language of Stitch Fix.
The Experience Language
In one way or another, we had already known for years that we wanted a design system. Maybe we didn’t know what to call it or what to build, but we had been collecting the evidence for a long time in the forms of tech debt, inconsistent UX, and knowledge silos² between teams. These barriers would surface as low quality UI, inconsistent design and code, and inaccessible digital content.
Without a design system, the system designs itself.
The experience language would be how we communicate and collaborate within the design system and how those guidelines create a consistent voice for our clients. It would be a set of guidelines that influenced all of our product design and delivery. In practice, this meant that we would constrain the many different ways we communicate design, standardize our UI, limit design choices, and set rules for the design system so that we could all “speak the same language.” Because without a design system, the system designs itself³.
We needed to ask ourselves “Did we already solve this before?” If the answer is “yes,” then: cool, let’s move on to bigger problems to solve. If the answer is “no,” then we now we would have a framework for responsibly designing a solution.
Transforming the Way We Work Together
We’d gotten buy-in, formed a team, gathered evidence, and defined the problem. Now we had a world of options in front of us. Where to begin? How do we start tearing down those barriers?
It isn’t the mountains ahead to climb that wear you out,
it’s the pebble in your shoe.⁴
Like every major initiative at Stitch Fix, we wanted to break it down into smaller parts and begin testing our assumptions. At first, we focused solely on the customer-facing product design team. Over the past 6+ years, the design team had accumulated mountains of designs that have existed across cloud servers and hard drives galore (Box, Dropbox, Google Drive, Zeplin, Invision, Sketch, and more). How might we unify our workflows? Bring order out of chaos?
Our explorations led us down many paths of tooling options. In the end, we decided we would be best served by hosting our shared design assets in one place: Figma. We immediately began building a library of shared design elements that would exist in one cloud-based location and be accessible by anyone with a Stitch Fix email. Our hypothesis was that—even though we were introducing a new workflow—we would see efficiency gains across both design and development via the collaborative nature of the tool.
We introduced this tool to our customer-facing product design team first (about 8 designers). The experiment for each design: use this tool in your design workflow, collaborate with your eng partners in Figma, lean on the Design Platform team for help along the way, but avoid falling back to other tools so you can identify pain points. It didn’t take long to hear positive reinforcement of this change, so we were quick to make a company-wide decision to adopt Figma as our design tool of choice. Software adoption at a company the size of Stitch Fix is no small feat, so this was a big win.
Baby Steps Up the Mountain
We had successfully begun to transform our multitudes of UIs into shared libraries in Figma. This was part of our goal to design and build consistent, engaging products at scale, but we still needed our customer-facing engineering teams to stop developing ad hoc UI on a per-team and per-product basis.
The Horizontal Slice Project
Our team was small and our needs were large, so we continued on the way we knew best: iterate, learn, repeat. The horizontal slice project introduced a single component, served via npm package, across multiple customer-facing applications. Our goal was to receive feedback on the process of introducing a single-source component to teams of differing levels of front end experience across different front end architectures.
And so, the Mode Style System was born.
The Mode Style System is a library made up of mostly Sass mixins and variables. It is a part of the larger Mode Design System and is responsible for generating the reusable digital assets, components, and design tokens that make up the visual UI of our products.
We initially envisioned a “vertical slice” project that would entirely decorate a single page/experience on the site with coded components from the library. This was a heavy lift with potentially low value, so we scrapped it in favor of the horizontal slice project, which showed us that we were on the right track and we did have a path in front of us.
The meaning behind “style system”
We take a lot of care in how we name things. For example: we go through great lengths to make sure our Figma library components share the same conventions as the code, because we know that it’s an important part of communicating across teams.
“Style system” is how we choose to differentiate the CSS components from the Figma components or the React components. Even repeating “components” in that sentence confused me, so it’s important that everyone involved in building product can understand the context with as little information as possible.
Tailored to Stitch Fix
There is no universal approach to design systems. A lot of our hypotheses for success are conceptually based on the work of others, then modified to be specific to the design principles and strategic goals of Stitch Fix. I’d like to share a few key takeaways I learned while retrofitting a design system to an enterprise product suite:
- 🏁 A Design System is never “done” — it’s a living product and holds the same high-quality standards that any of our other products hold⁵. Prioritize it on your product roadmap alongside other strategic initiatives.
- ❄️ A Design System should draw inspiration from the work of others, but be specially curated for your users’ needs. Every step forward is prioritized by feedback (direct and indirect) from our product teams.
- ⛰ When facing a mountain of possible solutions, focus your energy on smaller, incremental improvements and rely on user feedback to help you prioritize next steps. Test the design system with your users like you would any other high-impact product design.
A lot of amazing work has gone into Mode since its conception. We’ve expanded the breadth of our tooling and the depth of our libraries and still there’s always a higher mountain ahead. However, based on the feedback we’ve received—qualitative and quantitative—we’re making huge leaps forward. Other improvements are subjective, immeasurable, or just hard to capture, but the great thing about a living design system is that, without a finish line, it can always be improved upon! Our path forward is definitely a mountain, but we’ve secured our tools, we’ve identified our objectives, and we’re all bought-in; we’re now more confident than ever in our ability to scale our designs amidst an ambitious product roadmap.
Design Platform at Stitch Fix is Brian Cleveland & John Voss
In partnership with Torunn Skrogstad, Rob Wierzbowski, and Ben Ilegbodu
A huge thank you to the folks who contributed to the success of this system thus far. You’re too many to list, but this couldn’t have happened without you. I look forward to the future of the Mode Design System and the new experiences that it has helped unlock at Stitch Fix!
- (Original definition edited out of final draft, but here is a solid definition of “design systems”) Defining design systems via Introducing design systems
- Listen to Diana Mounter talk about design silos at designbetter.co
- I attribute this to John Voss from our first tech summit talk about design systems at Stitch Fix
- Attributed to different sources, popularized by Muhammad Ali
via Quote Investigator - Nathan Curtis says that A design system isn’t a project. It’s a product, serving products.
- Our color system was influenced by Stripe’s article Designing accessible color systems
