Image — component variants
01 Guidance built into the component
Best practices, accessibility guidance and technical requirements were embedded in the components themselves, which cut ambiguity for the designers using them.
I built each component so the right choice was the easy one — presets by default, controlled flexibility where teams genuinely needed it.
The solution
Image — accessibility specs
02 Presets first, controlled flexibility second
Each component shipped with clear presets — padding, corner radius, interaction states — while flexing through controlled variables: size, colour, icon placement, label text.
Image — multi-brand tokens
03 One component, two brands
Figma modes tied to Macquarie brand variables adjusted brand-restricted properties automatically — the 0px radii and regulated fonts brand foundations required — so one component served Group Treasury and the wider system without being detached or rebuilt.
Image — accessibility standards
04 Accessibility as a default, not a task
Every component was built to meet AA, and AAA where it was right, so any designer pulling from GEL inherited compliance rather than engineering it themselves.
Image — scalable components
05 Atomic and adoptable
Foundations first, then atomic components as real needs surfaced — an architecture that let divisions adopt incrementally instead of migrating wholesale.
Image — developer documentation
06 Documented for developers
Accessibility documentation per component, plus Dev Mode specs for spacing, tokens and interaction, reviewed against the Storybook build with the engineers.
The process
Problem
When I joined, Macquarie's group design system was three components: a logo, a button, and a tag.
Across the bank, more than 400 internal and customer-facing products were running on fragmented local design systems or none at all. Some divisions had drifted so far they were using Material UI with none of Macquarie's own colour or typography foundations.
The result was a disjointed experience that slowed design and added mental load every time someone moved between tools. GEL existed to close that gap: reduce duplication, enforce consistency, and cut the overhead of switching contexts.
Before state — fragmented local systems across 400+ products
Process
We built components for one team first — Group Treasury — then generalised the proven ones into GEL, grounded in three principles: consistency, usability, accessibility.
We started against a component roadmap but quickly found it more efficient to design components in response to real needs as they surfaced in Group Treasury day to day.
Accessibility was the thread I owned. We aimed for AAA and stepped down to AA deliberately in the dense, data-heavy interfaces where AAA would have forced type too small or too large to be usable. The standard served the interface, not the other way around.
01
System-wide audit
For each new component I audited its use across Macquarie, interviewing lead designers across divisions to surface pain points, requirements and edge cases.
02
Benchmark & standards
Benchmarked against competitors for usability and against WCAG 2.1 for accessibility, so each component started from a defensible baseline rather than a preference.
03
Technical constraints in parallel
Worked with developers on constraints and the existing frameworks we could lean on, so every component was buildable from the start.
04
Craft for MARS, generalise to GEL
Components were crafted first for MARS, then adapted for GEL through Figma modes tied to brand variables — one component serving both without being rebuilt.
Iteration
Every component went through structured review and cross-divisional critique before it shipped, which is how we caught what wouldn't generalise.
What landed
Tables & variables — component flexing across modes
Building for MARS first, then generalising, gave each component a real proving ground before it entered GEL.
Accessibility built into each component meant compliance scaled with adoption instead of being re-litigated per team.
The presets-plus-controlled-flexibility model held up — designers met their needs without detaching components.
What needed work
Process-flow diagram — audit to critique to release
Early time spent comparing large public design systems cost momentum before anything usable existed.
Components first shaped for Group Treasury needed rework to generalise once we ran them past other divisions.
Niche, highly complex cases like advanced trading tables couldn't be solved in the first pass, so we documented the gaps and flagged them for future expansion.
Aligning three co-contributing designers whose availability rarely matched meant working to shared guidelines and sparring components afterwards — prioritising getting the system into designers' hands over making every component flawless first.
Documentation & handover
I owned the accessibility documentation and stayed in the build, so design intent survived into code rather than getting lost at handoff.
Once a component was approved I completed its accessibility documentation, while the Design Systems Lead handled the broader system docs.
We leaned heavily on Figma Dev Mode to surface spacing, token usage and interaction specs, and as it was released I brought designers and developers onto it. Developers then built the Storybook and reviewed it against spec with me to confirm it was accurate.
Storybook — components reviewed against spec
What I’d do differently
I'd start sooner. The slowest part was a team decision, made with the Head of Design, to get the structure right before building — part of why only three components existed when I joined.
We spent too long comparing large public design systems and studying how they'd been done, treating Carbon as a source of truth rather than testing it against what our own teams actually needed. Many public systems lack depth or usability and shouldn't dictate your solution.
What worked was the opposite instinct: build something real for Group Treasury, then correct and generalise it into GEL with other divisions' use cases in mind.
If I did it again I'd evaluate our ways of working up front — agile, waterfall or hybrid, to suit the context — invest earlier in dedicated contributors, and put living documentation directly in Figma so guidance stayed accurate. Gathering every answer before starting was never going to scale across five design teams and fifteen-plus designers, and the momentum lost early was the most expensive part of the project.
Four of the five Corporate Operations Group design teams adopted GEL, and the fifth folded it into a system they already ran.
Impact
01
80%
Adoption across Corporate Operations Group design teams — four of five — with the fifth integrating GEL into its existing system rather than starting over.
02
3 → 30+
Components, on an atomic model that flexed across divisional branding through Figma modes and brand variables.
03
100+
Internal tools brought onto consistent foundations, reducing the visual inconsistencies and usability issues that had driven bug fixes and support overhead.
Accessibility by default
AA throughout and AAA where appropriate, so any designer adopting GEL inherited WCAG compliance instead of engineering it per product.
Less duplicated engineering
Front-end developers stopped rebuilding design-system elements. Conservatively this could save several full-time-equivalent months a year — an estimate, not a measured result.
Consistency people could feel
Fewer context switches moving between tools, and fewer inconsistencies reaching users as bugs and support tickets.
A system that resisted fragmentation
Controlled flexibility meant teams met their product needs without detaching components — the behaviour that had fragmented the bank's systems in the first place.