Design System
Challenge:
How might we pay down our tech debt, increase design-to-dev parity, create standardization, and build products faster
Role:
Lead UX Designer
(ft. partner in crime, Sr. Software Engineer)
Solution:
Design system that consists of 523 components, 119 variables, 7 modes, 3 breakpoints, and 78 design tokens
Background
Scalable Commerce is a small but dynamic software company specializing in delivering public records information through multiple brands. Currently, the company operates under seven distinct brands, each targeting different audiences and market segments but accessing the same core API endpoints. Within each brand, there are two primary product offerings: a sales funnel and a member site.
The company
The problem
Our Technology Team faced several critical challenges with the member site product, including significant technical debt from an outdated codebase, where small changes often led to unintended consequences across the system. The lack of standardization resulted in inconsistent user experiences and an inefficient development processes. Additionally, the absence of documentation hindered onboarding and maintenance efforts, creating more questions than answers.
The Objective
How can we unify the user experience across all member site brands, streamline the design-to-development workflow, enhance consistency, and ensure scalable efficiency?
The Process
Audit & Define
build
Implement
scale & adopt
Phase 1: Audit & Define
During this phase, we aimed to audit our product from a holistic standpoint and performed a heuristic evaluation of our member sites. This approach helped establish a solid baseline, defining the project scope and ensuring we have a clear framework for measuring progress and success.
Before we began building, we needed to validate our assumptions and ensure we were on the right track. We asked ourselves whether a design system was the appropriate solution and if it justified the investment of time, energy, and resources. Additionally, we assessed whether a design system could meet the diverse needs of our cross-functional team and identified the key features required for the project’s success.
desired Outcomes:
Consistent user experience
Design efficiency
Streamline development process
Component library
Design tokens
Documentation
Reduce technical debt
Scalability
Enhanced brand consistency
Technical requirements:
Version control
Design/Code integration
Performance optimization
Improve accessibility and usability
Easier maintenance and updates
Improve cross-functional collaboration
Responsive design
Customized theming
Metrics and analytics
Phase 2: build
As a designer, one might assume that the build phase of a design system would be the most enjoyable and thrilling part—immersed in Figma, crafting components with auto layout, and applying variable properties. However, the reality is that starting the build process can be quite ambiguous and intimidating. Key questions arise: Where should I begin? Which elements should be turned into components? How do I establish the hierarchy of variable properties? Should I create multiple variants of a master component, or develop distinct components entirely? Ultimately, navigating these uncertainties made the build process both challenging and rewarding.
-
Icons
Buttons
Images
Tags
Counts
Monitoring toggle
Show More/Less
Logos
-
Container Titles
Report Titles
Download Report Hyperlink
Line Items
Data
Data details
Data titles
Data summaries
Data tables
Navigate to Section List
-
Report Summary
Containers
Forms
Footers
Headers
Modals
-
People Report
Property Report
Phone Report
-
Login
Log Out
Dashboard
Search Results Page
Cancel Funnel
IDP
I dove into the build phase using Brad Frost's Atomic Design Methodology. I started by creating the atoms—basic elements like icons, images, and tags—to lay a solid foundation. Next, I combined these into molecules, such as container titles and data line items, which start bringing functionality into play. Moving on, I put together organisms—more complex structures like headers or forms made from groups of molecules and atoms. With those done, I crafted templates to map out how these organisms would be arranged on a page. Finally, I built pages with real content to show how everything works together. This structured approach ensured a cohesive, scalable component library that maintains consistency and functionality throughout.
While I focused on defining the guiding principles and standardizations through component properties and variable modes, my partner in crime, Sr. Software Engineer Cody Swithenbank, started implementing a 1:1 design system in code. Cody translated these principles and tokens into reusable components and modules using React.js, ensuring that the design system’s elements were consistent with what we had in Figma and fully functional for integration into our products.
As the component library started to take shape, I realized that a design system isn’t just about assembling individual components—it’s fundamentally about creating a cohesive framework that includes standardization, principles, and guidelines to ensure consistency and efficiency across all design and development efforts. A design system encompasses not only the visual and functional elements but also the underlying principles, rules, and best practices that guide how components are used and how they interact, aiming to deliver a unified user experience and streamline processes across teams.
Phase 3: Implement
After months of hard work and dedication, we finally had a fully fledged design system built in both design and code. With this solid foundation in place, it was time for our design system to reach maturity and be integrated into a feature, putting our extensive effort to the test in a real-world application. We decided to implement our design system in the launch of our member site product utilizing a new Express framework. To ensure a controlled rollout and gather valuable insights, we opted to run this feature launch as an experiment, applying the build to only one brand under the Scalable Commerce umbrella—SpyFly.
M28 Control
Legacy experience
50% traffic
Cancel rate: 24.45%
M28 Variation 1
Express experience
50% traffic
Cancel rate: 25.73%
Before scaling and adopting the design system company-wide, we conducted a thorough gut check. We ran an A/B experiment to ensure that key metrics, such as cancellation and retention rates, remained unchanged. Additionally, we monitored user interactions closely through session recordings and video feedback using HotJar to confirm that users engaged with the product as intended.
Phase 4: Scale & Adopt
Encouraged by the positive data from the M28 experiment and with approval from our Data Science team, we began scaling the design system. As our company name suggests, scaling is a crucial aspect of our business, and this is where the true beauty of the design system shone. Its consistent, reusable components and standardized practices allowed us to efficiently expand and maintain quality across our various brands and products.
Figma’s variable modes enabled me to assign logic to both primitive and semantic variables, facilitating seamless brand theming across the design system component library. This approach allowed for easy customization and consistent application of brand-specific styles throughout the entire system.
As the solo designer on a team of 10, the adoption of the design system across our Figma ecosystem was remarkably smooth 😝. Fortunately, we also managed to onboard the entire engineering and quality assurance teams, enabling us to function as a cohesive cross-functional unit. This seamless integration allowed us to collaborate effectively and leverage the design system’s full potential.
REflections
The MEtrics
Reduced design time to market by 80%
50+ clicks per frame reduced to 3
development cycle reduced from 57 days to 10
cross-functional team collaboration
increased by 83%
The learnings
While this project can be considered a success, it also presented numerous learning opportunities. Many of these insights focused around refactoring both the components and the Figma file that housed the component library. I discovered that ongoing adjustments were crucial to optimizing the design system, improving its usability, and ensuring it remained effective as new requirements emerged.
As I completed the component library build, I realized that organizing components according to the Atomic Design Methodology wasn’t practical for adoption and reusability. Although this approach was useful for identifying all the necessary components, it created difficulties for other developers and designers trying to locate what they needed, as components were categorized by type—atoms, molecules, organisms, templates, and pages. This categorization system was more conceptual and didn't translate well into a usable structure. To address this, I decided to reorganize the library by creating a separate page for each component and arranging these pages in alphabetical order. This change allowed for designers and developers to find components by page or asset through a list and the corresponding component’s initial letter.
Another area that needed significant refactoring was the organization of component properties. Initially, the component side panel in Figma was chaotic, with variants, booleans, instance swaps, and text properties scattered without clear structure. This disorganization made it challenging to understand what properties existed and how to use them effectively. After researching and listening to design system podcasts, I determined that the best approach was to arrange component properties from generic to specific. This meant that generic properties, such as device, type, and state, would always appear first, followed by more specific properties like booleans, and finally, text properties at the bottom. This standardized organization improved clarity and consistency, making it easier to apply and manage properties across different frames and ensuring a more intuitive user experience.