One System to Rule Them All

Process

• Securing Buy-In

  I introduced the concept of a design system to the broader team, walking through current inconsistencies and showing how a shared library could improve brand quality, accessibility, and development speed. Leadership quickly saw the value and asked me to lead design systems work alongside my product design responsibilities.

• Design Audit

  I conducted a comprehensive audit of our existing products to understand the scope of inconsistency. I catalogued every button variant, colour usage, typography choice, and spacing pattern across the corporate website and print materials. The audit revealed dozens of button styles, conflicting colour palettes, and inconsistent spacing — confirming that we needed a systematic approach, not just incremental fixes.

  I prioritized components by how critical they were to the product and how out of sync they were with current designs. This helped me focus on the highest-impact components first.

• Design Ops & File Governance

  I restructured our Figma workspace so every product and campaign linked back to a single IPAC Design System library. Files were organized by product area and access level, and the team were given direct access to the system file for reference and spec.

• Components & Tokens

  I rebuilt core components for the website and dashboard — buttons, inputs, cards, navigation, layouts — using a shared set of design tokens. We adopted a 4px spacing grid, with tokens like space-4 mapping to 16px, and global colour tokens such as primary-500 for easier handoff and future theming.

  I structured tokens to be developer-friendly, using naming conventions that mapped clearly to CSS variables and class names. This made it easier for engineers to translate designs into code and reduced back-and-forth during handoff.

• Documentation & Guidelines

  Alongside the Figma library, I created a documentation website that explained how and when to use components, colour, and typography. This site was added to onboarding and Smartsheets so new team members could quickly learn the system.

  View the design system documentation website

• Execution & Governance

  I rolled the system into active projects in phases. Components were only introduced into product and marketing files once full-page replacements were possible, which helped avoid awkward hybrid states where old and new styles mixed.

  Because I was the primary designer, I kept governance lightweight but intentional. I tracked required updates and issues through our bug-tracking tools (Smartsheet) and annotated Figma files with comments so developers knew exactly what needed to change. New component variations were documented, named, and reviewed against existing patterns before being added to the system, which kept the library focused and prevented component creep.

Challenges & Solutions

Building and scaling a design system comes with unique challenges. Here's how I addressed key obstacles while maintaining system integrity and team adoption.

Semantic Tokens for Theming

As the IPAC Dashboard evolved, I needed to support future themes like dark mode. Relying only on raw color tokens made changes risky and time-consuming. I introduced semantic tokens for key components (like button-surface-primary instead of hard-coded hex values), created a comprehensive token migration strategy, and established naming conventions that made design intent clear to both designers and developers.

Cross-Team Adoption

The marketing team understood the concept of a design system but sometimes used off-system colors, fonts, or illustration styles, which weakened the brand. I worked with my manager and developers to add a Smartsheet-based review step, created marketing-specific component variants, developed targeted training sessions, and implemented a feedback loop where the marketing team could request new variants.

Scaling to New Products

When we launched new products that required different header, footer, and layout variants, I extended existing components rather than creating entirely new ones, created product-specific theme layers, and developed a framework for evaluating when to extend vs. create new components.

Measuring Impact

Leadership wanted to understand the ROI of the design system investment. I tracked key metrics like component reuse rate and development time reduction, created quarterly reports showing adoption rates, and established user feedback loops.

Design System Structure

I organized the IPAC Design System into three core pillars: Brand, Design Foundations, and Components. This structure creates a clear, efficient system tailored to the needs of our small team and the company.

Unified Component Library

From September 2024 onward, the IPAC Design System became the foundation for our main products — the IPAC Dashboard (app and marketing website), the corporate website, and ongoing marketing and education materials. Shared components across these areas reduced one-off UI and made brand changes easier to roll out.

Core Components

Our library includes comprehensive components for all common UI needs: navigation (headers, footers, breadcrumbs, pagination), forms (inputs, selects, checkboxes, radio buttons, textareas), feedback (alerts, modals, tooltips, badges), content (cards, tables, lists, accordions, tabs), actions (buttons, dropdowns, menus), plus specialized components like widgets, AI assistants, and icons.

Design Tokens & Architecture

I created a comprehensive token system within Figma that serves as the single source of truth for our design decisions. Most colors are semantic, using names like primary-500, primary-400, neutral-900, accent-tan, alert-success, and alert-danger, with a few exceptions like --black and --white.

I also created component-specific tokens such as text-base, text-secondary, button-surface-primary, icon-button-surface-primary, and input-surface-base.

For spacing, I established a clear system where space-1 equals 4px, and sizing follows the same pattern with size-1 equaling 4px. Radius tokens map to spacing values (radius-sm = space-1, radius-default = space-2), and I have specific tokens for icon strokes (stroke-icon-default = 1.5px).

Developer Integration

For smooth developer handoff, I ensured that developers use the same variable names as my token names. This direct mapping makes implementation straightforward and reduces translation errors. I've recently started integrating dark mode support, which works naturally with our existing token structure.

Design Benefits

This token-driven approach provides consistency across all products, makes theme support (like dark mode) straightforward, and ensures design decisions are systematic rather than arbitrary. The semantic naming makes the purpose of each token clear, while the direct developer mapping reduces implementation time and errors.

Accessibility by Design

Accessibility is foundational to the IPAC Design System. All components are validated against WCAG 2.1 AA standards, including color contrast, keyboard navigation, and screen reader compatibility.

I test using various contrast‑checking tools, screen‑reader software, and keyboard‑only navigation workflows. Interactive elements include proper focus indicators, semantic structure, and the necessary ARIA attributes.

Configurable Components

Our components use Figma's variant system to allow easy customization while maintaining system integrity. The alert component demonstrates this approach with its flexible configuration options.

The Alert component includes type variants for default, danger, and warning states. Designers can show or hide elements like user names, headings, dates, descriptions, icons, and close buttons. All components are fully responsive across all screen sizes.

Scalable Across All Viewports

All components in the IPAC Design System are built to work across all screen sizes. While I don’t enforce specific breakpoints, components follow standard responsive patterns and adapt naturally from mobile to desktop. Using Figma’s auto‑layout, components adjust based on their content and container.