FULL CASE STUDY

Spark Design System

A multi-dimensional design system including themes, modes,
flexible components, templates, and guidelines.

⛓️‍💥 The Challenge: A Fragmented Experience

Spark is the design system that supports the products and interfaces of Genesys Cloud — a product ecosystem that spans a wide range of customer experience (CX) solutions. These products are mission-critical and heavily used, which means the interfaces are both complex and constantly evolving.

When I joined the Spark team, one of the biggest problems was inconsistency. Each team designed and built things slightly differently, which made the overall experience feel fragmented. There was a legacy design system, but it wasn’t robust enough to handle the scale. Its components were rigid, documentation was limited, and adoption across teams was low.

The result was a product suite that looked and behaved differently depending on where you were, slowing down designers and developers and making accessibility hard to guarantee. A new system was clearly needed — one that could scale with the product and actually earn adoption across such a large organization.

🎯 Strategic Goals

To solve the issues, we’ve worked with cross-functional teams to define a clear vision for our new design system.  It needed to:

Improve efficiency: reusable and versatile assets to speed up design and development.
Ensure consistency: standardized components for a cohesive look and feel.
Scale across platforms: support for multiple brands and modes (legacy/new, light/dark).
Enhance accessibility: at least WCAG AA compliance across the board.

In addition to setting these goals, we considered the entire product development lifecycle. The new design system was intentionally inserted into different phases — from research and definition, through prototyping and design, into build and testing.

Design system assets inserted into the product development cycle

💎 Building a Multi-Dimensional Design System

With the goals defined, we focused on building a system that could adapt to complex product needs while remaining consistent across teams. Our work centered on the following main pillars:

Reusable Components and Assets

Designed to be flexible through properties and slots, allowing customization without detachment.
Example: see the architecture of a rich text editor I contributed here.
Used across products — for example, in the Agent workspace, components were tailored via properties slots, and custom components used design system variables.

Token-Based Architecture

Tokens defined core design decisions such as colors, spacing, and typography.
Enabled multiple themes and modes (legacy/new, light/dark).
Connected directly to code via Tokens Studio's GitHub integration, ensuring parity between design and engineering.
The token system made it possible to switch entire screens/designs to different themes and modes.

The Agent Workspace in light and dark mode

Documentation & Best Practices

Comprehensive usage guidelines, templates, and patterns.
Helped teams adopt the system consistently and lowered the learning curve.
Reinforced through examples like dashboards built entirely on system tokens and variables.
Example: we've developed an Elevation and Hierarchy Guide that included not only elevation levels but also a decision matrix for container priority. This helped designers and product managers make consistent decisions about which UI elements should take precedence in complex flows.

A snippet from the z-index decision tree and the elevation styles

🤝 Collaboration & QA Process

To ensure quality and adoption, we built the system in close partnership with engineering and validated complex components with both designers and end users:

Tight Feedback Loops
- Designers and developers collaborated throughout implementation.
- Components were refined based on real-world usage and developer feedback.
Quality Assurance
- Every component went through structured QA before release.
- Verified design–code parity and validated that micro-interactions followed expected flows.
Accessibility Reviews
- Conducted accessibility checks during design and code phases.
- Ensured semantic markup, keyboard navigation, and screen reader support.
- (Illustration: accessibility audit screenshot or testing setup)
Component Testing with Designers & Users
- Ran component-level testing sessions with designers before publishing to ensure the system matched real design needs.
- Validated interaction patterns with end users to confirm usability in practice.
- See my testing process in this article.

🚀 Driving Adoption Through Education & Support

Even the most robust design system has limited impact if teams don’t adopt it. We made adoption a priority by supporting designers and developers at every stage:

Workshops & Training
- Facilitated sessions on using system components, tokens, and documentation.
- Provided hands-on guidance during onboarding.
Migration Support
- Guided teams in updating legacy UIs and libraries to align with the new system.
- Offered structured migration workshops with clear before/after examples.
Continuous Feedback
- Created channels for designers to share insights and challenges.
- Iterated the system based on real-world usage.

Migration workshop snippet

⚡️ Impact & Results

The introduction of Spark as a multi-dimensional system led to clear improvements across the organization:

Faster design and development — design teams reported being noticeably faster in their overall processes by reusing system components instead of creating one-off solutions. They also reported being more confident in their design decisions by relying on Spark's patterns and guidelines.
Higher adoption — approximately half of product teams integrated Spark into their core workflows.
Improved accessibility — WCAG AA compliance achieved more consistently across product areas.
Greater consistency — a more unified look and feel across the Genesys Cloud ecosystem.
Central knowledge hub — Spark became the reference point for usability and best practices.