# Enterprise Design System *CASE STUDY 03 · DESIGN SYSTEMS* One design system for 20+ HR products: 80+ components, documented in code, and themeable for every client’s brand. ## Project details Built and scaled the 80+ component design system behind 20+ PrismHR products, with design tokens that power white-label theming, dark mode and color-blind-accessible themes. - **Role:** Co-creator and lead maintainer - **Team:** Co-led with one other designer · 4 contributing designers - **Timeline:** Started 2022 · Angular library since late 2023 - **Scope:** 20+ products under the Unified User Experience initiative - **Platform:** Figma component library + Angular components - **Tools:** Figma · Angular · Storybook · Chromatic · Design tokens - **Outcome:** 80+ components · the standard for 20+ products - **Status:** In production · actively evolving ## Overview ### One system for a growing family of products. 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. ### My role - Co-created the design system in 2022 with one other designer, and we remain its main contributors and stakeholders - Review and approve contributions from four other designers - Built and scale the Figma component library - Design and document Angular components in Storybook and a proprietary documentation site - Validate UI in Chromatic for design fidelity - Implement the design tokens behind white-label, dark-mode and color-blind-accessible themes - Mentor global design and dev teams on system-wide standards ## The problem ### A tight deadline, and the same components built over and over. 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 ### What the system had to support. The system has to serve every product team, and every client brand, from one source: - 20+ products, including acquired platforms being brought into the system - Designers in Figma and developers in Angular working from the same components - Client branding (white-label) that goes beyond a logo swap - Dark mode, high-contrast and color-blind-accessible themes, with WCAG 2.1 AA as the minimum for the built-in themes ## Key decisions ### 1. Design, iterate and polish in code 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. ### 2. Grow with the stack 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. ### 3. Pixel-perfect across Figma, MVC and Angular 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. ### 4. Tokens at the core 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. ### 5. One component, designed and built 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. ### 6. Accessible by default, with a trade-off 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. ### 7. AI that stays on-system 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 today 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. *Diagram: How tokens flow: two brand colors per client (primary and secondary) generate tokens such as primary, primary-hover, primary-focus, primary-ghost and primary-text, with text-white or text-color for text on colored fills. Components like buttons, nav items, status chips and toggles read only those tokens. Light, dark, high-contrast and color-blind-safe themes swap neutral and chart tokens without changing components; success, warning and error colors stay the same in every theme, only slightly lighter in dark mode.* *Diagram: Component states built from the same tokens: primary, hover, focus, secondary, ghost and disabled (a faded primary) buttons; text fields in default, focus and error states; checkbox, radio and toggle with gray unselected states; fixed success, warning and error tags; and a stepper with green completed steps and a solid primary current step.* ## Try it ### White-label theming 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. *Interactive on the web page (https://mikemona.com/work/design-system#demo): visitors choose a primary and secondary brand color and a theme: light, dark, high contrast, red-green safe (deuteranopia and protanopia) or blue-yellow safe (tritanopia). A sample employee dashboard re-themes live (success, warning and error colors stay the same in every theme and brand, only slightly lighter in dark mode, so statuses are always recognizable), the generated design tokens are listed (primary, primary-hover, primary-focus, primary-ghost and primary-text for each brand color, plus text-color and text-white for text on fills), and WCAG contrast checks update live. The demo nudges text colors to pass AA (AAA in high contrast); in production, client colors are used as given, so custom themes can fall below WCAG.* ## Results - **8–10** views handed off per day, up from 3–4 - **80+** components in the library - **20+** products on one system - **AA** WCAG 2.1 contrast, the minimum for every built-in theme ## Reflection ### What I’d do differently 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. --- Web page: https://mikemona.com/work/design-system Contact: mikemonaphoto@gmail.com · LinkedIn: https://www.linkedin.com/in/mikemona Resume (PDF): https://mikemona.com/assets/Mike-Mona-Resume.pdf