Key problems

The lack of a design system caused 3 major issues for WorkRamp.

Inconsistent product experience

Multiple variations of the same components and foundational elements (e.g., color, typography), and different layouts for similar functionality created a fragmented user experience. Each page looked and behaved differently, increasing the cognitive load for users and undermining trust in the interface.

No Source of truth

The lack of systems impacted both design and engineering. Without a centralized, reusable library, components were repeatedly redesigned and rebuilt, leading to duplicated work, longer design and dev cycles, inconsistent interactions, and missing component states. All of which contributed to the discrepancies across the product.

accessibility Gaps

Since components and pages were built from scratch for every project, corners were cut to speed up development, and WCAG compliance was often overlooked. As a learning platform, accessibility is essential for delivering an inclusive experience, and the platform did not achieve that standard.

How we built WRDS

Note: The majority of this work occurred from self initiative. There was no leadership-driven push to build this. It’s development occurred along side all other feature work. 

Goals 

1. Build a reusable, scalable, accessible design system 

2. Achieve product consistency by updating existing experiences to comply with system patterns

Looking back, the development of WRDS fell into four different, and sometimes overlapping, phases. 

Phase 1: Develop a scalable, accessible, reusable design system

Audited the platform
I reviewed and documented component usage across the entire platform, including the LMS (admin and learner consoles) and the academies admin console. This surfaced inconsistencies and informed design system scope.

Audited existing design system libraries
I assessed three partially built Figma libraries. While they explored foundational elements (like color) and iconography, they lacked reusable components.

Reviewed components to keep or phase out
To reduce disruption and promote consistency, I prioritized retaining widely used patterns, especially from newer features. I also leveraged the “Foundations” library, which provided accessible color palettes, type scales, and spacing rules.

Built identified components in Figma
We were a small design team (2 designers vs. a much larger engineering team), so I took a designers-first approach. I focused on building high-impact, reusable components (buttons, inputs, etc.) and interaction states to establish the first version in Figma. This approach enabled me to move quickly and to see results immediately.

By the end of phase one, the library consisted of 15 components. Our design team shared a visual language, increased output speed, and improved design consistency across handoffs. Even before engineering adoption, the product UI became more unified. This consistency helped secure buy-in to develop a coded design system.

Phase 2: Build the system with engineering 

This phase began in tandem with Phase 1. While the push started as a design-led effort, engineering was also interested in building a reusable component library.

Partnered with engineering
I collaborated closely with our other designer and a front-end engineer to align on building a reusable library. Design continued leading component creation (visuals, states, interactions), while engineering owned implementation in Storybook and ensured WCAG compliance.

Created a development pipeline
I created detailed Jira tickets for each component, outlining design specs and interaction behavior. These were picked up during feature work or as bandwidth allowed. We established a post-build design review to catch gaps early and minimize rework after components entered production.

Documented usage guidelines
I wrote usage documentation in Figma (for designers) and Confluence (for cross-functional teams). This included best practices, specs, interaction states, and real examples. I maintained a component status tracker to improve visibility into what was in progress, up next, or available to use—helping engineers and designers plan effectively.

Implemented in the product
Reusable components were rolled out gradually, primarily through new feature work. Due to team constraints and a complex codebase, we deprioritized retrofitting legacy pages—unless they were being actively updated.

Outcome (Feb–Jun 2022)

• Design: 15 components designed, 2 in progress

• Engineering: 12 components built, 1 in progress, 8 queued up*
  *While Figma used one component for multiple uses (eg, the input component covered forms, search, etc.), they needed to be separate entities in Storybook to ensure correct interactions.

Phase 3: Drive Adoption and Scale Usage

With the system in progress and early components in place, the next phase focused on increasing awareness, usage, and team adoption.

Surveying usage to establish a baseline

In June 2022, I distributed a usage survey to the engineering team to gather baseline data. While usage was expected to be low—given that the system was still in ddevelopment and only applied to new feature work—the goal was to understand the current landscape and track future growth.

While the results were expected, we used this data to expand the library, build awareness, and advocate for deeper adoption across the team.

Advocacy and awareness
To promote adoption, I regularly advocated for using the design system in meetings, feature planning and execution, and one-on-ones. I shared survey findings and system goals at PDE all-hands and company-wide all-hands, positioning the system as a strategic investment in speed and consistency.

Sustained growth
Over the next year, we

• completed the initial component backlog

• expanded both Figma and Storybook libraries by adding new components

• ensured all new features used system components and patterns

Additionally, I developed copy guidelines for voice and tone, language and grammar, and writing empty state copy to achieve consistent communication within our product.

As a result, the product UI became increasingly unified in look and behavior. This phase marked a turning point—moving from setup to momentum.

Phase 4: Achieve Visual Consistency by Updating Legacy UI

By mid-2023, our platform footprint expanded significantly, supporting two "learning clouds" (each with admin and learner experiences), plus two new products (Communities and CMS) were in the works. As WRDS adoption grew across these areas, visual inconsistencies between updated and legacy pages became more pronounced. As a result, we revisited our initial stance on retrofitting legacy pages with the new UI and determined it was time to tackle those areas.

UI audit and discrepancy tracking
In July–August 2023, I led a deep UI audit of the Employee Learning Cloud Admin—a high-traffic area with the most inconsistencies. The stark contrast in page backgrounds, combined with non-system colors and mismatched components, made it feel like users were navigating two entirely different products. These inconsistencies not only affected user trust, but also posed challenges internally, making it difficult to confidently demo the platform to prospective clients.

I captured screenshots and interaction flows for each page and modal in Figma, and documented update requirements in Google Docs. I collaborated with a front-end engineer to define the effort level to update, and then categorized each page by tier:

• Tier 1: Basic modal swaps

• Tier 2: UI-only component updates

• Tier 3: Minor UX enhancements (e.g., validation)

• Tier 4: Major UX changes or full redesigns

Define a strategy
We evaluated multiple approaches (component-by-component, page-by-page, or a single release). Due to resource capacity, codebase complexity and risk, we chose page-by-page updates.

Working with product and engineering leadership, I proposed dividing the work into four phases based on effort and product impact:

• Phase 1: Simple page updates (components, colors, typography)

• Phase 1.1: Replace tables with WRDS table component

• Phase 2: Update simple modals

• Phase 3: Update complex modals

• Phase 4: Evaluate Tier 4 (full redesign) updates case-by-case

We started with phases 1 and 1.1, with the caveat that this was not a project to fix major UX issues. We wanted to deliver visual alignment quickly, and a redesign would slow it down.

Mocks, tickets and execution
I created Figma mocks for each page/modal, built an epic and 30+ Jira tickets for phases 1 and 1.1.

Although this work was not prioritized over feature development, I continuously advocated for it—embedding WRDS updates in new feature work and collaborating with PMs and engineers to incorporate these changes when possible. In many cases, switching to WRDS components actually saved engineering time due to the complexity of legacy code.

Eventually, contractor support helped accelerate page updates. Some engineers also took initiative to make updates independently, further expanding adoption.

By January 2025, 85% of the platform (across all product areas) utilized WRDS components and patterns.

Examples of legacy pages and corresponding WRDS updates

Additional platform progress

• Learner Platform: While not formally audited, ~90% of it used WRDS by January 2025, thanks to updates made through new feature development.

• Academies Admin: With a smaller scope, I worked directly with engineers and created UX tickets. The admin side was fully updated by Q3 2023.

Learnings

• Teamwork makes the dream work. Cliche, but true. This project wouldn’t have gone anywhere without engineering team members who had the same goals and self-starting initiative to make it happen. 

• Take the small steps where possible. In the end, they add up to larger change and impact.

• Always be advocating. The more people that get on board, the easier it will be to gain traction and achieve change. 

• Documentation is key. With longtail projects like this, the more thorough documentation, the better. I can’t remember everything all the time, and having clear documentation makes it easy to refer back to make decisions. 

• Remember to appreciate all the hard work. Since this was (and still is) an on going project, it’s easy to get stuck on what’s not done/what’s still wrong. Reviewing this entire journey makes me realize how much we have achieved and how far we came.  

Special thanks to designer Daniel Chae and front-end engineers Andrew Barnhart, Jibin Mathew, Alex Morrise, and Thibaut Delille. WRDS would not be the same without them.