Project Vision
ProgressUI is a collection of multiple design systems that support EveryAction. Comprised of four different versions, each with its own level of fidelity, ProgressUI V.4 represents the system at its most modern and refined. My primary responsibility was to maintain the system—answering questions and providing support to designers who relied on it.
As a designer using ProgressUI daily, I was already familiar with its inefficiencies. Gaps in documentation, non-functional components, and inconsistencies made it feel clunky and incomplete. Teammates frequently voiced frustrations about the system, as its shortcomings often extended their workloads. Recognizing these issues, I took it upon myself to modernize the system and make it truly work for the designers who depended on it.
Responsibilities
I took full ownership of maintaining the existing design system. In addition to providing ongoing support, I focused on improving file organization, component construction, and documentation.
My Role
Design System Manager
Tools Used
Figma
THE GOAL
Design Debt
When I inherited the project, documentation about the design system’s elements was scattered across two main resources:
A Figma Library – A repository of components organized across multiple subpages. However, ProgressUI hadn’t been updated in some time, leading to outdated information and missing components that existed in EveryAction’s codebase. It wasn’t uncommon for designers to need to break or rework components to make them usable.
A Guidelines Document – A visual reference meant to provide usage instructions and best practices. While this document was intended for stakeholders and developers, it was largely ignored by development teams. Many designers knew of its existence but didn’t treat it as a go-to resource when crafting experiences. This lack of adoption led to project launches with system mistakes, undermining the purpose of the guidelines.
Both of these issues resulted in the same problem: designers spent more time reworking components instead of learning how to use them properly. Our team wasn’t proud of the mistakes being made, but we also didn’t feel like we had the time to fix them. I had been guilty of this myself!
In conversations with my teammates, I discovered that designers rarely referenced the guidelines in their workflow. Instead, they returned to the design system to find and acquire components. So, why not include documentation alongside each component’s construction? Even if designers weren’t actively seeking it, they’d at least see it in passing—potentially leading to greater adoption.
Voilà! Now, all relevant information about a component—its construction, usage, and more—could be found in one place. This was a simple but effective change: I imported guideline standards directly into the component library.
To further improve fidelity, I added links to the codebase so designers could easily share specifications with developers. Where documentation was incomplete, I referenced well-known design systems like Google Material Design and Apple’s Human Interface Guidelines to fill in the gaps.
Component Construction
A frequent complaint from teammates was that components were poorly constructed. Previous versions of ProgressUI had been imported from Sketch—a transition that was far from seamless. ProgressUI V.4 was built while designers were still learning Figma, resulting in components that lacked auto-layout and contained unoptimized (or unnecessary) frames, making them frustrating to use
Some components inevitably needed to be broken, but ideally, that should be a rare occurrence—especially for something as simple as an input field. I focused on simplifying and optimizing each component so that designers wouldn’t be burdened with unnecessary system-related tasks while designing.
Additionally, many components lacked prototyping functionality, making them ineffective in presentations. Part of my optimization work involved ensuring components functioned properly in all relevant use cases.
Documentation Gaps
While improving the system, I asked my teammates what they felt was missing or frustrating about the design library. This sparked a discussion about the distinction between a guideline document and a component library. While the Figma library was fairly up-to-date with the guidelines, it still lacked essential elements needed for designers to work efficiently. Some components simply didn’t exist, while others were so complex that designers intentionally broke them for efficiency.
Net-new components would need to be crafted to close these gaps in documentation. Along with this, I reworked components that were at high-risk for breaking to account for data variability. By installing a pre-filled data set as a placeholder for content, designers do not need to detach the entire component to account for their data.
A Living Document
I was enjoying the process of refining and fixing the system, and my teammates were thrilled with the improvements. Great! But something still felt missing. The components and guidelines felt like just one piece of a larger puzzle. Things like color codes, typography decisions, spacing rules, and links to additional learning resources—all of these elements connected designers, managers, and developers into a broader ecosystem.
Curious, I started asking questions:
How would a new designer engage with this file?
Does a design system start and stop at just its components?
How could this file be a resource for leadership, recruitment, or even system-related tasks like QA?
These questions led me to incorporate essential elements that leveled up our design system thinking and redefined what ProgressUI could be.
NEW! A time-stampable change log, to easily understand what I (or any other designer) was adding and improving.
NEW! A high-level overview and introduction to the design system, included links to confluence documentation, bug reporting, and an internal tracking system to better understand the fidelity of an element's page.
Design foundations, including existing guideline details around color usage, typography, data visualizations, and more!
NEW! A place to track and log UX patterns which lacked proper documentation. Now we can begin to understand and conceptualize micro-UX patterns within our product!
Existing onboarding existed in all different places - but are essential for understanding our system's standards when passing off the design system. I included details for figma file construction(NEW!), developer handoff, and our QA process for easy-access when learning how to use ProgressUI v.4
So, how'd it go?
This project wasn’t just about fixing broken components—it was about making the system work for the designers using it. By refining documentation, optimizing components, and integrating the system into a broader design ecosystem, I helped turn ProgressUI from an obstacle into a true asset.
Not only was my work validated and championed, but it also sparked long-overdue conversations about system thinking. My teammates were incredibly appreciative of the improvements, and the project was ultimately a huge success. It aligned best practices, improved workflows, and set the stage for even better design system processes moving forward.
Improvements & Impact
✅ Unified documentation and component construction in Figma
✅ Optimized components for usability and prototyping
✅ Improved file organization and eliminated outdated elements
✅ Created a living design system that better supports designers and developers
As I mentioned before, ProgressUI is in it's fourth iteration - but it is not the ONLY design system used at EveryAction.
Version 1, 2, and 3 require similar file improvements to meet the new standards in the modern iteration.
What I learned
I LOVE DESIGN SYSTEMS! The process of treating my fellow designers (and myself) as a user of a product was such a fun process.
Professionally, the power of bring through in your work can have ripple effects that can improve the lives of others AND yourself. In a way, design system work is advocating for YOURSELF as a designer. A refreshing reframing of the essential skill of empathy!
