Genesis UI is a company wide Figma design system built to replace multiple fragmented legacy libraries across Aware Super’s public website and member-facing digital products, giving design and engineering teams one accessible, governed foundation to build from.
It is one of the most advanced, groundbreaking design systems I’ve built designed to build upon itself and reduce the overall component count that normally causes library bloat in larger organisations.
Senior UX / Product Designer, leading the Design System initiative over a 6 month term.
Replaced competing component libraries with a single source of truth used across the website, onboarding and member products. Teams moved from recreating UI to reusing it, removing a recurring cost that had been absorbed silently by every project.
Accessibility standards were built into core components at the foundation layer, so teams inherited compliant patterns instead of correcting them late. This shifted accessibility from a per-project remediation task to a property of the system itself.
Standardised naming, structure and component behaviour gave developers predictable expectations at handoff. All backed up by comprehensive component documentation in confluence. Fewer clarification loops meant less rework and a more consistent gap between what was designed and what shipped.
Aware Super’s UX team was working across several legacy design systems, most of them outdated, inconsistently structured or unmaintained. The same component existed in multiple forms, behaved differently depending on which team had built it, and carried no shared accessibility baseline.
The cost was rarely visible on any single project. It surfaced as designers rebuilding patterns that already existed, developers interpreting the same component two different ways, and members encountering subtly inconsistent experiences as they moved between products.
The opportunity wasn’t to build a better UI kit. It was to establish an operating model for design consistency that could hold up as more teams and products were added.
Before proposing a new system, I audited the existing Figma libraries and legacy systems to understand what was actually being used, what had been abandoned, and where teams had quietly forked their own versions.
The audit focused on duplicated and conflicting components, inconsistent naming and structure, gaps in accessibility, and the points where handoff friction was costing delivery time.
What it exposed was not only a primarily a visual problem. There was no shared architecture, no reliable source of truth, and no ownership model which meant design debt was compounding faster than any individual project could pay it down.
I used Atomic Design as the underlying architecture because it gave designers and developers a shared mental model rather than a private filing convention.
Foundational elements, grouped controls, larger reusable patterns and repeatable page structures were each given a defined role in the system, along with standardised naming and consistent behaviour across every instance.
The result was a foundation that could absorb new products and journeys without a proportional increase in maintenance the difference between a library that ages well and one that fragments again within a year.
Every component was designed with a clear path to production code. Coming from a front-end background, I worked directly with developers on structure, states and edge cases rather than handing over static specifications.
That collaboration changed design decisions. Patterns that were visually appealing but expensive to build were reconsidered early, and I was able to advise on HTML and CSS approaches that kept implementation simple.
Designing this way meant the system was practical to deliver, not just internally consistent.
A design system only works if teams adopt it, so the final phase was change management rather than a launch.
I prioritised the highest-value components first and introduced the system into live initiatives so it could be validated in real delivery contexts. Teams transitioned progressively instead of being asked to stop work and migrate wholesale the fastest realistic path to adoption in an organisation with active roadmaps.
Alongside rollout, I established the governance foundations the previous systems had lacked: component ownership, change control, versioning discipline and a maintenance model, so quality would be protected after the initial build.
Genesis UI replaced a set of fragmented, unowned libraries with a single accessible system that design and engineering teams could build against with confidence.
By diagnosing the operating model rather than the components, the project reduced duplicated effort, raised the accessibility baseline across member-facing products, and created a foundation capable of scaling with the organisation.
The lasting outcome was less about the library itself than the governance around it the system was set up to stay consistent as teams, products and priorities changed.
Joseph