One modular library, one 9-step colour scale, and every text/background pair meeting WCAG AA.

Overview

Building a scalable future: a flexible system for growth and consistency.

During my time at Purple Digital I worked on Hyro, the company’s core SaaS product: an enterprise presentation platform for immersive experience rooms and customer experience centres, where large corporations deliver interactive, high-impact presentations.

As Hyro’s client base grew, it became clear that the product’s foundations weren’t built to scale. Alongside the redesign of the Story Designer editor, we needed a design system: a shared set of styles, components and rules that would make the product:

• Consistent

• Accessible

• Faster to design for

My role: I led the design system work while working with one other designer. Over eight weeks we built a new, modular system in Figma, from colour and type foundations to documented components, ready to support the redesigned product and whatever came after it.

Challenge

A product built for small teams, now carrying enterprise weight.

Hyro’s interface had grown screen by screen, feature by feature. That worked while the product and its users were small. As large corporations with complex needs adopted the platform, the cracks started to show:

1. Inconsistency everywhere

   • Without a shared foundation, similar elements looked and behaved differently from one part of the product to the next.

   • Spacing, colours and components were defined per screen rather than once, so the interface felt cluttered and unorganised.

   • Users had to relearn patterns as they moved through the product.

2. Usability problems that couldn’t be fixed one by one

   • Fixed sections, inefficient use of space and tools buried behind dropdowns made the product harder to use.

   • These issues were being tackled in the Story Designer redesign, but without a system behind it, every fix would be a one-off.

   • The next feature would bring the same problems back.

3. A bottleneck for the team

   • For designers, every new screen started almost from scratch.

   • For developers, inconsistent designs meant more one-off implementation and more to maintain.

   • As the product evolved, this slowed down both teams and made each update riskier than it needed to be.

4. Accessibility left to chance

   • Colour choices weren’t backed by a structured palette or clear contrast rules.

   • Whether text was readable enough depended on each individual decision, which made accessibility hard to guarantee and harder to check.

Why it mattered

Hyro’s growth depended on shipping new features quickly without degrading the experience. That required a foundation that was consistent, scalable and accessible by default, and one that would let the design team move faster instead of slower as the product grew.

Process

Foundations first, components second, documentation throughout.

1. Audit the existing interface

   • We collected what already existed in the product: buttons, navigation, form inputs, colours and text styles.

   • Laying them side by side showed how much duplication and variation had built up, and which patterns were worth keeping.

2. Build modular, not page by page

   • Rather than redesigning screens, we designed the building blocks screens are made of.

   • Every element, from buttons to navigation bars and form inputs, became a reusable component with its own variants.

   • Improvements made once carry through the whole product, and new features can be assembled from parts that already work together.

3. Design components to hold up at any size

   • Hyro runs in very different contexts, from designers’ laptops to large screens in experience rooms.

   • Components were built to be responsive, keeping their structure and integrity across screen sizes and layouts, so one library could serve the whole platform.

4. Structure colour around accessibility

   • Instead of picking colours by eye, we built a structured palette: each main colour has four lighter and four darker shades, a predictable 9-step scale.

   • The scale gives designers room for depth, emphasis and visual differentiation, while keeping contrast predictable from one step to the next.

   • We tested the palette against two standards:

     • WCAG, the established guideline.

     • APCA (Accessible Perceptual Contrast Algorithm), which better reflects how people actually perceive contrast.

   • Building on both meant the system met today’s requirements while being ready for where accessibility guidance is heading.

5. Put the documentation where the work happens

   • A design system only works if people use it correctly, and guidelines in a separate document tend to drift out of date.

   • Instead, we wrote descriptions directly into Figma for every style, component and asset: its purpose, best practices and accessibility notes.

   • Anyone using a component sees how to use it at the moment they need it.

Solution

A scalable, accessible system the whole team can build on.

• Scalable styles and components

  • A modular library of reusable components, including buttons, navigation bars and form inputs, built on shared styles for colour, type and spacing.

  • Responsive and flexible enough to customise as the product evolves, without breaking visual consistency.

• Colour system for accessibility

  • A palette of main colours, each with four lighter and four darker shades.

  • Contrast is consistent across the scale and checked against WCAG and APCA, so designers can create hierarchy and emphasis without guessing whether text will be readable.

  • The structure also allows the palette to adapt to different branding needs while keeping accessibility intact, which matters for a platform that presents on behalf of large corporate brands.

• Documentation built into Figma

  • Every style, component and asset carries a description: what it’s for, how to use it, how to extend it and what to watch for in terms of accessibility.

  • New designers and developers can understand the system without a handover, and the guidance stays in sync with the components themselves.

Impact

A foundation, measured by what it makes possible.

The system was delivered as a Figma library and hasn’t been built into code yet, so I can’t point to production metrics. What I can show is what the system itself guarantees:

• Accessible by default. Every text/background pair in the palette meets WCAG AA. Designers who use the system’s colours get readable text without having to check each combination themselves.

• One source of truth. Buttons, navigation and form inputs now have a single, documented definition instead of a different version per screen.

• A predictable colour scale. Nine steps per colour give designers enough range for hierarchy and emphasis while keeping contrast consistent.

• Faster, more consistent design work. New screens are assembled from existing components instead of drawn from scratch, which also gave the Story Designer redesign a consistent foundation to build on.

Reflection

• A design system is a product, not a file. The components matter, but so do the rules and documentation around them. Writing descriptions straight into Figma turned out to be one of the most valuable choices, because it put guidance exactly where decisions are made.

• Accessibility is easiest at the foundation. Building contrast into the colour scale meant accessibility stopped being a check at the end and became a property of the system. Fixing it at the source was far simpler than fixing it screen by screen.

• What’s next. Bring the library into code with the development team, so design and production share the same source of truth, and then measure adoption, consistency and design speed in practice.