Building Momentum through Atomic Design
Project Summary
Part of core team that rebuilt the Momentum Design system from the ground up, moving away from legacy structures to a a modern, flexible system that scales.
Conducted discovery work to identify areas of improvement for our existing design system
Applied Atomic Design principles to create modular components that would stay consistent across the Webex Admin ecosystem.
Facilitated design reviews with Webex Admin leads to ensure functional logic met the needs of 17+ product teams.
Navigate legacy technical constraints.
Impact
Unified the design toolkit for 150 designers across over 17 admin products, including Control Hub and Partner Hub.
Used Atomic Design to create modular building blocks, providing feature designers with a scalable framework while simplifying maintenance for the core Momentum team.
Cut manual component overrides by 60% by replacing static rigid layers with dynamic boolean toggles and interactive properties
Role
Product Designer working with 3 product designers
Tools
Figma, Jira, Confluence, Webex
Timeline
May - Dec 2022
The Problem
As Webex Admin grew, design and engineering teams were plagued by UI inconsistency and development silos.
Fragmented Figma files led to significant design debt, slowing down the shipping cycle for design hand off and implementation of new features.
Legacy assets were static, forcing designers to “break” components to accommodate new use cases
A lack of centralized standards caused friction between design and engineering.
The Challenge
Rebuild the Momentum Design System Figma library from the ground up.
Transitioning from legacy, static assets to a dynamic, scalable system.
Creating a system flexible enough to support diverse Webex product suites (Control Hub, Partner Hub, Contact Center)
Ensuring parity between Figma components and production code.
The Discovery Process
Before building, I followed a strategic process to ensure we were solving the right problems for both designers and developers.
Performed deep-dives into our current products and industry competitors to identify where our existing system was breaking and where we could improve
Facilitated design reviews with admin leads to confirm our component logic worked for the unique needs of over 17 product teams.
Competitive Analysis of several progress bar components in competitor design systems.The Atomic Process
Utilizing Atomic Design principles to ensure every component was modular, maintainable, and logically structured.
Utilized a tiered structure to ensure the library was both modular and maintainable.
Atoms: Defined foundational styles — Momentum color tokens, typography scales, spacing, and iconography.
Molecules: Combined atoms into simple functional groups, such as buttons, input fields, and tooltips
Organisms: Built complex UI patterns like navigation bars and data tables by nesting atoms and molecules together.
Components were built using Auto Layout, Properties, and Variants to maximize designer efficiency and minimize manual pixel-pushing.
The Results
The design system is now being used by over 17 teams in the Webex Admin space with over 40 components and counting.
Scalable and flexible components provided a larger amount of customization and configuration for feature designers, while making it easier to update and manage for the design system team.
Minimized visual and functional bugs during the implementation phase by ensuring parity between the design toolkit and the live build, leading to faster approvals and more predictable release dates.
Significantly reduced design-to-dev handoff time by aligning Figma component properties with production code, eliminating the need for custom local components for every design.
Takeaways
Lesson
A tiny error in an Atom becomes a massive headache in an Organism. Precision scales and due diligence at the start will create a strong foundation to build your work upon.
Growth
Aligning component naming conventions with designers and engineers early on is critical to avoid "lost in translation" moments during handoff. Precision at the start is non-negotiable.
Change
Large-scale system changes require consistent, proactive effort to maintain alignment. I prioritized continuous syncs with stakeholders to ensure our component logic remained functional across every product vertical.
Atomic breakdown of the progress bar component.The Problem
One thing to note about this project: I didn’t go into it planning to redesign the component itself. The original objective was actually to add a thicker variant of the existing progress bar within our design system for the Webex Experience revamp project.
Ask
“We would like a thicker variant of the Progress Bar component for use in the Webex Experience (Control Hub as a Coach) project.” - Product Designer on Webex Analytics Team
In order to get a better idea of the expectations for the larger variant, I wanted to explore the root cause for its need so I conducted an internal audit of their project and early explorations of other admin applications as well.
Internal Audit
Revealed a large amount of variance in the progress bars being used in Webex revamp project with inconsistencies in the sizing, color patterns, and even component anatomy.
Audit showing the different progress bar designs being used in the Current Control Hub redesign files.Additional Explorations
To see if this was a common occurrence in our other projects, I conducted explorations of other admin applications.What I realized was that the underlying challenge went beyond a single variant, and spanned across multiple teams and screens with over 17+ variants not being covered by our existing component and sizes ranging from 4px to 20px.
Progress bar variants throughout the Webex Admin applications that are not covered by our current component.Goal Statement
Design a new progress bar that can adapt to multiple applications and user needs so that features are delivered faster and with a consistent experience.
Competitive Analysis
To ensure the new component could handle our current use cases, as well as potential future use cases, I conducted a competitive analysis of the component in other design systems.
What I learned is that to ensure their components were sustainable and manageable long-term, they had 3 features in common:
Responsive Sizing: Having multiple sizes allows more flexibility across devices and since we currently only have 1 size, we’re limiting designers in their work and potentially impacting users ability to quickly digest data.
Configurability:Configurable elements allows more consistency in how we customize the component. In addition to the 1 size, we only had 2 variants of the existing progress bar.
Structured guidelines: To provide designers a concise breakdown of the component and usage documentation.
Competitive Analysis of several progress bar components in competitor design systems.UX Goals for Redesigning the Progress Bars
Based on my research, I decided to focus my redesign strategy in 3 areas for how we might design the new component.
Customization vs. configurability : By striking the fine line between giving designers more control over the customization while standardizing common properties such as size and alignment.
Accessibility enhancements: Through the usage of accessible colors with sufficient color contrast for progress bar elements such as the track, fill, and text.
Comprehensive documentation: So designers are able to spend less time figuring out how to use the component, and more time building products and features with our design system.
Design Solutions for the New Progress Bars
With my redesign strategy as my direction, and my research and early explorations as my evidence and guide, I felt confident moving on to some design work.
Anatomy and Atomic Breakdown
When looking at the anatomy of the over 17+ variants currently found in our apps, and those of other design systems, I noticed a pattern in their structure, they all had a variation of the following 5 features:
Anatomy of the new progress bar features based on early research.Visually breaking down UI components makes it easier to manage the design system while keeping it flexible for designers to use. For our progress bars, we have the following atomic breakdown:
Atoms: As our building blocks, we have the track, fill, and text styles.
Molecules: Using those atoms, we create our base progress bar and data labels.
Organisms: Using our atoms and molecules, we create our main component variants.
Atomic breakdown of the progress bar component.Outline Accessible and Cohesive Colors
I identified that the 3 states a progress bar can be in are Active, Error, or Success. Based off the Momentum Core color token library, I documented which colors be used for each state as a way to align their usage and semantics.
Accessible Color breakdown for the updated progress bar component.Unify Sizing Breakdown
One of the most common reasons designers detached or created new progress bars in their work was the lack of size flexibility. To make each size more meaningful, I started with retaining the original 4px size to accommodate designs using the current component.
Additionally, the most commonly used sizes we didn’t cover were the 8px and 12px with a majority of designs. As a result, 60% of progress bar usage today comes from the Medium(8px) and Large(12px) variants.
Final Progress Bar design sizing breakdownComponent Customization and Configuration
When approaching the component structure, I wanted to give designers more control over the progress bar component when using it in their designs.
Utilizing component properties, we reduce the number of variants that need to be created and maintained, while providing designers with a more structured approach to customization and configuration options.
Standard Progress Bar properties breakdownInline Progress Bar properties breakdownDocumentation and Guidelines
To be proactive in assisting designers in case they run into trouble using the component, while also developing a shared language when working cross-functionally with stakeholders, I wrote out and updated the documentation and guidelines.
Outcomes
The progress bar component is now being used by over 17 teams in the Webex Admin space with over 3000 instances.
The scalable and flexible progress bar component for the Momentum Admin Design System provides a larger amount of customization and configuration, while making it easier to update and manage for the design system team.
Next Steps
Moving forward,the goal is to evangelize the new component and design system whether that be in office hours or meeting with specific teams and syncing with their work. In doing so, we can better ensure that progress usage across the board is consistent and cohesive.
Lessons Learned
It is not a designers 2nd job to learn how to use our work.
Designers are busy people so it’s important you make your work as simple and easy for them to adopt into their workflow so they can spend less time figuring out how to use it, and more time creating designs.
Get feedback early and often!
It’s critical to understand how each step in the design process ensures that you are staying on track, and that you’re keeping your users at the core of your work. Whether that be getting stakeholder feedback or design reviews with the team to get another perspective on your work.
The importance of thinking intentionally about design decisions.
Designing with intentionality and understand that working on design systems, your deliverables impact the work of the many teams that use your components so it’s important to make sure that the decisions you make, are made with intention and reason.
