Case Study
Bringing System and Order to an Organically Grown Design System
Company:
Moss
Industry:
Fintech
Project type:
Design system, UI design, Design Ops
Duration:
6 weeks
My Role in this Project:
Current usage audit
Stakeholder interviews
Strategy and framework
Production (redesign/documentation)
BACKGROUND
“Web library or Web library 2.0. From which file should I take an input form component?”
I asked many questions similar to the one above several times a day when I joined the company in April 2022. While it is normal for a newly joined designer to ask how things work in the new environment, navigating the design system files at Moss was particularly complicated.
After discussing the issue with my colleagues, I discovered that everyone on the team, regardless of their tenure at Moss, shared the same frustration with the design system. As a leader in the product design team, I knew that we needed to prioritize untangling our design system to scale our design operations effectively.
In this case study, you will get a glimpse of how we embarked on a journey to overhaul our design system, with a focus on improving accessibility, usability, and scalability.
Phase zero: Understanding the situation
“What don’t you like about the Moss design system?”
I kicked off the project by interviewing designers. I focused on capturing pain points and shadowing how they currently use our Figma library files. By the time I completed interviews with all six designers, I was able to observe recurring sentiments towards the design system and common symptoms amongst the team:
Theme One
“Purpose of different design library files is not clear to me.”
↓
Jumping between many different files to find the right components and style.
—
Theme Two
“I have to think how to organize and document components when contributing to the design system because there is no standardized approach that we follow.”
↓
Contributing to the library is perceived as time-consuming and daunting.
—
Theme Three
“It’s hard to figure out what variants and options are available for each component.”
↓
‘Detaching’ and ‘remixing’ components.
Phase ONE
Untangling the Design Library Files
As a first step, I audited all design system files we had and mapped out their relationships to each other.
As you can see, our system lacked a designated location for where styles (color, text, effect) live. As a result, it was easy for our designers to get lost in the network of cross-referencing Figma libraries. Moreover, it wasn’t clear how changes in one library file affect others, making updates our the design system even more complicated.
For our revamped design system, I wanted to paint a clear picture of how designers can find components/styles and how library files affect each other. To achieve these goals, I’ve set the following principles to structure new Figma library files:
Next, I created a map of new file structure following the new principles.
This map helped the team understand the roles of each library file and their relationships with each other clearly. As a result, I got the support I needed from the team to leap into this new design system structure.
Phase TWO
Laying the Foundation
After agreeing on the file structure with the team, I set out to reorganize the file. I first gathered all styles and atoms used in our design and documented their usages in the “Foundation” File. During this process, I created a simple documentation template. Having a minimal yet flexible template allowed me to focus on capturing just enough details and make the overall documentation process faster and easier for the team members.
Phase Three
Defining the “Moss” way of building components
Daily challenges product designers at Moss experience with the current component libraries could be boiled done to the following three questions:
“Where can I find it?”
“What options do I have?”
“What can I do with it?”
To come up with a unified way of building components for our designers, I first interviewed each designer and shadowed how they work with our library files. As a result of this exercise, I discovered that there are mainly three types of designers and three different needs the new design system has to fulfill.
Introducing the Naming Convention
After experimenting with different ways of organizing Figma components, we concluded that we could achieve our goal of serving the three sets of needs by setting the new naming convention and rules on how we use pages/artboards to organize our components.
We then introduced the convention with principles our team should follow and examples screenshots demonstrating the benefit of adapting the new approach. By visually communicating changes and the benefits they could bring to our day-to-day work, we made our design team members also get excited about the adaption.
Phase four
On your mark, get set, produce🛠
After having all the foundational work done, it was time to reconstruct components. We identified all components that need refactoring and created a checklist to track the progress.
As we continued on with component refactoring, we checked with our engineering team to understand what information they would find it useful to be included in the design system files. We set the rule to make sure all components are reviewed with front end engineers and provide answers to any question they have raised during the review as a part of documentation.
Conclusion
Invest Time to Design the System that Optimizes for Efficiency
During this process, one of the most valuable lessons we learned was the importance of investing time in understanding the pain points and needs of the design team before making any changes. By doing so, we were able to demonstrate how the proposed changes would directly address the challenges our designers faced in their day-to-day work. Through a series of demos and feedback sessions, we worked closely with the design team to refine the new design system and turn our designers into advocates for the changes. This collaborative approach helped to build a stronger foundation for the team to work effectively, resulting in more scalable layout templates, an effective change management process for UI patterns, and a reduced learning curve for new team members to familiarize themselves with the "Moss way" of working.
—
Thank you for taking the time to read our journey.