In 2020, I led the migration from Adobe XD to Figma and built the central component library that unified 40+ products. Alongside one other designer, I scaled the system group-wide within 18 months.
The Access Group operates as a portfolio of independently acquired software companies – each with its own product teams, design conventions, and ways of working. When I joined, there was no shared design language or centralised tooling. Teams worked in Adobe XD, which lacks a component-sharing model built for enterprise scale.
Without a shared library or visual patterns, every product team spent valuable cycles redesigning basic elements. Flexibility became effort with no accumulated value. This wasn't a typical design-system problem; it was an organisational scalability challenge. I needed to shift the company's tooling, define the technical architecture, and build a system that could scale across dozens of independent companies.
In 2020, Figma was not yet the enterprise default, making Adobe XD the comfortable, procurement-approved status quo. I pushed for an organisation-wide migration to Figma anyway – not on personal preference, but because XD could not deliver the live component syncing, real-time collaboration, and native design-token support required to sustain a group-wide system.
The greatest friction wasn't adoption; it was change management. I managed the transition by treating the tool switch as a change-management exercise, and the library proved its value by immediately eliminating repetitive design chores – shifting the culture toward shared contribution.
With the tooling settled, I architected and built the core of the component library alongside one other designer. We had to serve highly diverse enterprise products – spanning legal, HR, finance, and hospitality – meaning the system had to balance extreme data density with ease of use. To ensure long-term stability, I structured the library into five distinct extension layers from day one.
I designed the colour architecture around automated compliance, mapping full WCAG contrast ratios directly into the system documentation for light and dark variants — so designers see exact contrast ratios instantly within Figma, without opening a separate evaluation tool. For typography, I implemented Inter across 20+ named styles, optimising desktop specifications to handle the high layout density enterprise administrators demand all day, without sacrificing readability.
The decisions that let two designers build something dozens of teams could depend on.
The architectural foundation was built entirely on design tokens. Because every colour, spacing value, and type style references a token rather than a hard-coded hex, theming or rebranding a product line only requires updating a single token layer.
Unlike consumer apps that default to mobile-first, I optimised this system desktop-first – our core users are professionals working complex tools on large screens all day. Mobile layouts were adapted from desktop patterns second, not the other way round.
Accessibility was treated as a core build requirement. Focus states, contrast ratios, and keyboard navigation were embedded directly into the anatomy of every component from version 1.0 – eliminating the need for expensive retroactive audits.
Component delivery was incomplete without comprehensive usage guidance. Every element shipped with do/don't examples and explicit accessibility notes – making documentation an equal product deliverable rather than a post-launch afterthought.
Shipping components is an exercise in craft, but getting dozens of acquisition product teams to use them consistently is an organisational challenge. To guarantee adoption, I authored the operational governance framework that turned the design system into a non-negotiable company standard.
From a defined launch date, all new design work across the entire portfolio was required to start from EVO – transforming the library into the default baseline for every screen and every team.
Our tokens worked perfectly inside Figma, but we didn't align naming conventions with front-end frameworks on day one. That oversight caused unnecessary translation friction during the initial component handoff.
As adoption spiked, product teams began creating custom variations in isolation. A lean intake process early on would have captured those patterns and converted them into reusable system components much faster.
Relying on manual reviews to catch component detachment or style drift slowed governance as the team grew. Automated file-linting plugins sooner would have protected design quality at scale without the manual friction.
