In 2020, The Access Group’s design teams were working in XD. I argued for Figma before it was the enterprise default, then designed and built the component library that unified design across the entire group. Two designers. 240+ components. Adopted group-wide within 14 months.
The Access Group operates as a portfolio of software companies — each acquired independently, each with its own product teams, its own design conventions, its own way of working. When I arrived at Access Legal, the design team was working in XD. Not Sketch. Not Figma. XD.
XD is primarily a UI design tool. You can create screens and share prototypes, but component versioning is limited, design token integration with engineering is minimal, and maintaining a living shared library that updates across files at group scale is not what it was built for. Every product team across the group was designing from scratch — their own button styles, their own colour decisions, their own spacing conventions. A user moving between Access products encountered entirely different interfaces each time.
Meanwhile, the group was running a major recruitment drive to embed a UX designer in every product team across every software company. The right ambition — but it made the fragmentation problem exponentially worse. More designers, each working in isolation, each inventing their own components from disconnected XD files. The tools couldn’t support the way the group needed to work, and the absence of a shared system meant every pixel was a bespoke effort with no accumulated value.
This wasn’t a design system problem in the typical sense. It was an organisational scalability problem. I needed to change the tooling, define the architecture, and create a shared system that could work at group scale — before the practice grew any further.
In 2020, Figma wasn’t the enterprise default. Its enterprise plan didn’t exist until late 2021. Research showed only around 13% of companies with 1,000+ employees had adopted it by 2020, with UK enterprises lagging US adoption by six to twelve months. For a PE-backed group of Access’s size, XD and the Adobe ecosystem were the comfortable, procurement-approved status quo.
I pushed for Figma anyway. Not because of trends or preference — but because I could see exactly what the group’s design practice would need in two years, and XD couldn’t deliver it:
A button updated in a shared Figma library updates everywhere it’s used. In XD, shared components exist but the library ecosystem is fragmented — updates don’t propagate reliably across teams working in different files. A colour change at group scale means manually chasing updates across dozens of product teams. That’s not a workflow — it’s a maintenance burden that guarant
The same variable name in Figma and in the React codebase. colour/primary/600 in Figma maps to $color-primary-600 in code. Designers and engineers stop having subjective conversations about what “primary” means — it’s the same value in both tools. XD has no native design token system, making this kind of shared single source of truth structurally impossible without significant workarounds.
With designers being embedded across every product team across the group, they needed to pull from the same shared library in real time — not email static PDFs between offices. Figma’s browser-based model made this work regardless of which software company a designer sat in.
The design tooling market was clearly moving toward Figma. Building a design system on XD in 2020 would have meant rebuilding the entire thing within two years as the industry migrated. I decided to move early — it was an investment decision, not a tool preference. It proved right.
The biggest resistance wasn’t to the design system concept — the need for that was obvious. The resistance was to abandoning XD. Designers had workflows, templates, and muscle memory invested in the Adobe ecosystem. That was the hard sell. The design system became the proof the bet paid off.
Choosing Figma before it was the enterprise default was the highest-leverage call on the entire project. Without Figma’s component architecture, variant system, and shared libraries, two people could not have built a system adopted by 40+ products. XD couldn’t have enabled that architecture. The tool enabled the system. The system enabled the scale.
I designed and built most of the component library, with one other designer contributing alongside me. The system needed to serve products across all of Access’s software companies — legal, HR, finance, hospitality, and more. Desktop was the primary platform: these are enterprise applications used by professionals on large screens all day. Getting the desktop foundation architecturally right was the constraint that mattered first. Mobile and dark mode were planned as extension layers — not afterthoughts, but deliberately sequenced.
General
Buttons, checkboxes, menus, navigation, icons, labels. The foundational interaction patterns everything else composes from.
Data Editors
Autocomplete, date pickers, rich text, multi-select, file pickers, form inputs. Where users spend most of their time entering and editing data.
Data Display
Avatars, badges, banners, data cards, lists, tables, timelines, progress indicators. Designed for the information density enterprise workflows demand.
Surfaces
App bars, cards, modals, drawers, panels, popovers, tooltips. The containers that give structure to every screen.
Navigation
Breadcrumbs, links, menus, tabs, pagination, left nav. For applications where users move between dozens of views per session.
Feedback
Alerts, confirmations, error states, spinners, skeletons, toasts, validation. The system’s voice when something goes right — or wrong.
I designed the colour architecture with full WCAG contrast ratios mapped at every pairing. The palette spanned primary teal, secondary purple, 15+ semantic colour scales — surface tones, content colours, success, warning, error, and information states — each with light and dark variants and accessibility ratings documented inline. Every colour pairing in the system shows its contrast ratio. Designers don’t need to open a separate tool to check — the documentation tells them whether a combination passes AA or AAA before they use it.
Inter as the typeface, with a comprehensive type scale covering 20+ named styles from H1 through table cells. Separate specifications for desktop and mobile, each documented with exact size, weight, line height, and letter spacing. I designed the scale to support the information density enterprise applications require without sacrificing readability — a 12px caption needs to be legible next to a 56px heading, in the same interface, all day.
Tokens first, components second
I defined colour, spacing, and typography as abstract design tokens before designing a single component. This added time upfront but meant every component inherited its values from the token layer. When a brand colour needed to shift, it changed everywhere at once. When the team later explored dark mode, the token architecture made it achievable in days rather than months — because every component already referenced tokens, not hard-coded values. This was the decision that let two people build a system at 40-product scale.
Desktop-first, deliberately
The instinct in 2020 was “mobile first.” I argued the opposite. These are enterprise desktop applications — fee earners, HR managers, accountants, and hospitality staff work on desktop screens eight hours a day. Component architecture, spacing, and interaction patterns all needed to work at desktop density first. I planned mobile and touch as extension layers, not the foundation. Designing for the primary use case first, then extending, produced a more coherent system than trying to serve all platforms simultaneously from day one.
Accessibility as architecture, not audit
I shipped every component WCAG 2.1 AA compliant from the start. Keyboard navigation, screen reader support, focus states, and ARIA patterns were first-class concerns — not a checklist applied after the visual design was finished. I built the colour system around contrast ratios, not the other way around. The accessibility documentation included checklists across visual, auditory, cognitive, and interaction categories, giving every designer a clear standard before they opened Figma.
Documentation as a product, not an appendix
A component library designers love but engineers can’t implement is a failed system. I treated the Docusaurus documentation site as a product in its own right: live code editors where engineers could modify component properties and see results immediately, npm installation and registry guides, step-by-step tutorials walking through a complete application build from TAG components, and a full component availability matrix across platforms. If an engineer couldn’t get from zero to working component in under five minutes, the documentation had failed.
Shipping 240+ components is craft. Getting product teams across multiple software companies to actually use them consistently is a fundamentally different challenge — and the harder one. A design system nobody uses is a Figma file, not infrastructure. So alongside the component library, I authored the full layer of documentation that makes adoption possible.
Iconography, colours, typography, illustrations, shadows, and personas. Each page explains not just the specification but the reasoning — why this typeface, why these spacing values, why this shadow depth. Designers who understand the logic make better decisions when the system doesn’t have a pre-built component for their specific situation.
Practical onboarding for the tools the design practice used: Figma, Marvin for research, UserZoom for testing, Wootric for satisfaction measurement. Consistent tooling is as important as consistent components — if designers use different research tools with different methods, the insights don’t compound across the group.
Documentation covering UX research, data analysis, journey mapping, ideation, and show-and-tell formats. Every designer joining any software company in the group got a clear picture of how we work — not just what the UI looks like.
A dedicated accessibility section with WCAG-aligned checklists, practical guidance by impairment type, and resource cards. Accessibility wasn’t a separate concern — I embedded it in every layer of the documentation from day one.
The adoption mechanism was simple and non-negotiable: from a defined date, all new design work across the group followed EVO’s principles and guidelines. This wasn’t a suggestion or a best-practice recommendation. It was the standard. EVO became the shared language — the default starting point for every new screen, every new feature, every new product, across every software company in the group.
Components are the visible tip. Beneath them: the governance model, the onboarding documentation, the tooling guides, the playbooks, the accessibility standards, and the mandate that made adoption group-wide. This layer is what turned a component library into organisational infrastructure — and it’s the layer I defined and authored.
The system two designers built was successful enough that Access invested in a dedicated team to extend it to touch, mobile, and a full DesignOps practice.
Pushing for Figma before it was the enterprise default was the highest-leverage call on the entire project. Every capability the system eventually needed — living components, shared libraries, design tokens, real-time collaboration across offices — depended on a platform that could support them. A well-designed system on the wrong tool is a guaranteed rebuild. XD couldn’t scale to what the group needed. By 2022, the Figma migration was obvious to everyone. The two-year head start meant Access had a mature, adopted system while competitors were still switching over.
240+ components is craft work I’m proud of. Getting 40+ product teams across multiple software companies to use them consistently was harder — and ultimately more important. The guidelines, the governance model, the documentation, the onboarding materials: these aren’t supplementary to a design system. They’re what makes the difference between a Figma library and something the whole organisation depends on.
Desktop-first was a deliberate constraint, not a compromise. Shipping a system that worked brilliantly for the primary use case was more valuable than one that worked adequately across all platforms at once. The token-first architecture made extension possible without rebuilding — and when the dedicated team picked it up, they extended rather than replaced. That was the test of whether the original architecture held.
Two people building a system for 40+ products sounds impossible — until you understand what the token-first architecture actually does. Define the abstraction layer well and components compose from it. Build components without tokens and every one is a bespoke effort that doubles the maintenance surface. The decision I made at the start about how to structure the system determined everything that followed, including how much of it two people could realistically do.