CASE STUDY 03 · DESIGN SYSTEMS
One design system for 20+ HR products: 80+ components, documented in code, and themeable for every client’s brand.
OVERVIEW
PrismHR’s products span HCM, ATS, Payroll, Talent Management, Performance, Onboarding, Report Center and Employee Management. Under the Unified User Experience initiative, they need to look and behave like one platform.
I started the design system in 2022 with one other designer, during the HCM overhaul and build. It makes that possible: an 80+ component Figma library, matching Angular components, and design tokens that carry each client’s brand and accessibility needs through the whole platform.
THE PROBLEM
The HCM overhaul started in 2022 with a very short timeline, and we were pushed to move fast. Handoffs from design to engineering were slow, and engineers kept rebuilding the same components. Each engineer built them their own way, so the same piece could look and behave differently from one screen to the next.
At the same time, the platform kept growing through new products and acquisitions, each with its own workflows and interface patterns.
White-labeling was a product team decision, both for a better experience and for sales. Many of our customers have clients of their own, and they don’t want those clients to know they’re using a third-party platform. Swapping the logo in the header wasn’t enough: the product had to feel like their own proprietary system.
RESEARCH
The system has to serve every product team, and every client brand, from one source:
KEY DECISIONS
Instead of designing pages in Figma first, the other designer and I designed, iterated and polished directly in code. We built the components, styles, layouts, micro-interactions and pages ourselves, and handed engineers a clean front end to plug the back end into.
Engineers no longer had to build each view. They added the data and functionality to the front-end views we gave them, and handoffs went from about 3–4 views a day to 8–10.
The system started as an MVC component library. We rebuilt it in Figma so internal and contracted teams could design from the same source, then expanded it into an Angular library when products moved from MVC to Angular, starting in late 2023.
Keeping Figma, the MVC library and the Angular library in sync was the hardest part. They’re different languages, built by separate teams, so every component had to match pixel for pixel.
During the move from MVC to Angular, a user could go from an MVC page to an Angular page in the same session. If anything looked different, the product would look broken, so the goal was that users couldn’t tell the difference.
Color, type and spacing are defined once as design tokens, and components read from them. A new theme means new token values, not redesigned screens.
New components and changes come from a small group of designers, and every contribution is reviewed and approved by the two of us who lead the system. Each component lives in the Figma library and as an Angular component, documented in Storybook and a proprietary documentation site, and checked in Chromatic so design and code stay in sync.
The built-in themes (light, dark, high contrast and color-blind-accessible) all come from the same tokens, with WCAG 2.1 AA as the minimum.
Client colors are the trade-off. Once a client changes the system colors, we can no longer control contrast, and you can’t really tell a client their brand colors don’t work and they have to change them. We had to accept that a custom theme might not meet WCAG, and trust clients to choose well.
More recently, our team has used AI to speed up how work moves through the system. Together, we introduced an AI-assisted design-to-code workflow with Claude Design and Claude Code that turns Figma designs into working Angular prototypes, cutting handoff time from design to front end to engineering by more than 75%.
We also built custom Claude agents and MCP servers with strict design system guardrails. Project managers can use them to generate mockups that follow the system, so they can communicate ideas clearly to design and engineering without leaving the design standard. All of this was a team effort, and I was one of several people building it.
THE SOLUTION
The system is the design standard for 20+ products under PrismHR’s Unified User Experience initiative.
Acquired products are brought into the system with guidance for their design and development teams, so workflows and interfaces feel like one platform.
The visuals below are built from the same token logic as the live demo further down the page. Change the colors there and these re-theme too.
1 · BRAND INPUTS
Set once per client.
2 · TOKENS
primary#1A56DBprimary-hover#174DC5primary-focus#1441A6primary-ghost#E8EEFBprimary-text#1A56DBsecondary-ghost#E7F5F3Generated from the two brand colors. Text on fills uses text-white or text-color.
3 · COMPONENTS
Components only read tokens.
Light, dark, high-contrast and color-blind-safe themes swap neutral and chart tokens. Success, warning and error colors stay the same in every theme and brand (only slightly lighter in dark mode), so statuses and messages that need attention are always recognizable. Components never change.
Buttons
Text fields
Selection
Status · consistent in every theme
Stepper
TRY IT
Pick a primary and secondary color and watch a sample employee dashboard re-theme itself. That’s the idea behind the system’s tokens: two brand inputs generate primary, primary-hover, primary-focus, primary-ghost and primary-text (and the same for secondary).
The contrast checks are something this demo adds to show the trade-off. In production, client colors are used as given, so a custom theme can fall below WCAG.
Switch themes to see the same screen in light, dark, high contrast, and two color-blind-safe themes. Components never change; only token values do.
Success, warning and error colors are the exception: they stay the same for every client brand and theme, only slightly lighter in dark mode, so statuses and messages that need attention are always recognized the same way.
BRAND COLORS
Light: The default theme. Status colors stay the same.
GENERATED TOKENS
CONTRAST CHECKS
STATUS · CONSISTENT IN EVERY THEME
RESULTS
REFLECTION
I’d build better documentation around the components from the start, along with real change logs.
With just two designers moving fast to keep up with the project timeline, we never set up a good system for change logs. Once more designers joined and more projects started using the system, they became much harder to manage.
A design system is never finished, and it keeps evolving as new products and acquisitions join the platform.