Apr 2022 - Nov 2022
EonX Design System
Creating a new design system that accounts for scalability and team unification.
Design System
Tokens
Overview
EonX is a fintech company operating multiple customer-facing websites from a single shared design system. One website was an employee benefits including employee discounts at affiliate stores and bulletin hub that adopts client branding. When the new design team was assembled, that system hadn't been meaningfully updated in years. The visual language was fragmented, the codebase was out of step with the designs, and accessibility failures were serious enough to carry legal risk.
The brief was clear: rebuild the design system from the ground up. Not patch it - rebuild it. A system that met modern accessibility standards, gave designers a single source of truth, and could scale across multiple brands without starting from scratch each time.
My Role
I was one of three designers on the project, working alongside a design lead and a senior UX/UI designer.
My responsibilities covered the full span of the build: auditing the existing system, researching best-in-class design systems, rebuilding from foundational tokens upward, and constructing the component library through to page-level templates. Developers also underwent accessibility training and this opportunity allows us to become WCAG AA compliant.
Problem
The audit told a clear story. EonX's websites were being held together by design decisions made at different times, by different people, without a shared framework. The result was a system that was inconsistent, inaccessible, and genuinely painful to work with.
Accessibility failures with legal exposure
The live product did not meet WCAG AA standards. Colour contrast failures were widespread - buttons, text, and interactive elements across multiple sites were failing basic legibility thresholds. For the commercial product handling financial data, this wasn't just a design quality issue - it was a compliance and legal risk.
Visual inconsistency at every level
The design files showed the hallmarks of accumulated design debt: icon line weights that varied within the same page, icon sizes that skipped major intervals, buttons that changed shape between desktop and mobile, and a general incoherence that made the product feel unpolished and untrustworthy.
No shared source of truth
Design assets were scattered across multiple files with no clear canonical version. When starting a new project, the team would rebuild prototyped components from scratch each time. There was no reliable reference point - for designers or developers.
No rebranding capability for white-label clients
EonX's core product was a white-label suite - an employee benefits portal, a bulletin board, and a communications site - licensed to client organisations who expected it to reflect their own brand. The existing design system had no mechanism to support this. Every new client rebrand meant manually reworking components and styles from scratch, creating significant overhead and making the process difficult to scale.
Goals
Improve accessibility, usability and designer efficiency.
Resolve all WCAG AA accessibility failures across the suite of websites
Consolidate all design decisions into a single, well-organised file that serves as a source of truth for both design and development
Dramatically increase prototyping productivity by building pre-prototyped, reusable components
Build rebranding capability into the system's tokenised component architecture, so EonX's white-label suite could be reskinned per client without rebuilding components each time
Outcomes
The rebuilt design system was delivered in full and exceeded expectations on every front.
500% increase in prototyping productivity - pre-prototyped components meant a Figma file could replicate a live website experience in a fraction of the previous time
Full WCAG AA compliance achieved across the colour system through rigorously tested, accessible token pairings and component anatomy
Reskinning capability unlocked for white-label clients - design tokens linked to a GitHub repository allowed EonX's employee benefits and communications site to be rebranded per client by swapping token sets, turning what was previously a manual rebuild into a configuration task
Single source of truth established for both design and development, eliminating the ambiguity and duplication that had slowed the team down
Process
Process - Discover
I began with a thorough audit of the existing design files, live websites, and component library. The scope of the problem became clear quickly. Beyond the known accessibility failures, the icon set alone had four distinct issues: inconsistent stroke caps (some round, some square), varying fill styles within the same thematic group, line weights that deviated from the 2px standard, and size increments that ignored the established spacing scale.
Researching well-regarded design systems - including those from major product companies - helped establish a benchmark. The patterns were consistent across the best systems: icons with uniform line weight and size, type scales with clear visual hierarchy, colours used with semantic intent, accessibility treated as a requirement rather than a retrospective check, and design tokens as the connective tissue holding everything together.
Process - Develop
With the audit complete and a clear picture of what good looked like, I adopted Brad Frost's Atomic Design methodology to structure the build - atoms first, then molecules, organisms, templates, and pages. The approach was deliberate: each component tier references and builds on the one before it, which keeps the system scalable and internally consistent by design.
Colour
I rebuilt the colour palette from scratch, stress-testing every value against WCAG AA contrast requirements before committing it to the system. Accessible pairings were baked into the token naming structure so designers could make correct choices by default rather than by manual checking.
Typography
Font scales were rebuilt with appropriate visual intervals for both desktop and mobile contexts, replacing the ad hoc sizing decisions that had accumulated in the previous system.
Remaining foundations
Spacing, sizing, stroke widths, border radius, blur, and opacity values were all systematised and documented - the unglamorous but essential scaffolding that makes a design system feel coherent rather than cobbled together.
Component Construction
Building the component library was the most complex phase of the project. Pre-prototyped components - with hover states, focus states, expanded states, and animated transitions all built in - required careful thought about how each state would behave across different contexts and screen sizes.
All states had to meet accessibility contrast thresholds, not just look good. Expanding elements needed to animate correctly without breaking layouts. Button placements and labels followed established interaction design conventions to ensure predictability for users across the sites.
The investment paid off directly in productivity: once the component library was in place, new pages could be assembled and prototyped in a fraction of the time previously required.
Design Tokens
The impact was significant - and most immediately felt in EonX's white-label business. The core product suite (an employee benefits portal, a bulletin board, and a client communications site) was licensed to multiple client organisations, each expecting the product to carry their own brand. Previously, every new client meant manually reworking components and styles from the ground up.
Process - Launch & Test
With the token system in place, each client brand could be expressed as its own token set within the plugin - swapping colours, typography, and visual style across the entire component library instantly, without touching a single component. What had been a significant design and development effort was reduced to a configuration task reducing the work from a week to under a day.
The impact was significant. Each brand could maintain its own token set within the plugin, with global and semantic tokens structured to allow complete visual transformations - colour, typography, spacing - without touching a single component. Tokens also brought the design and development teams into closer alignment, encoding design decisions in a format developers could consume directly rather than interpret from static files.
This was also where I first deepened my understanding of how to communicate design decisions in a developer-friendly way - adopting Tailwind CSS naming conventions for tokens made the handoff substantially cleaner.
Learnings
Accessibility is easier to build in than to retrofit.
The contrast failures in the original system existed partly because accessibility had never been a first-class constraint. Rebuilding with WCAG AA compliance as a hard requirement from the token level up meant it was never something to chase after the fact.
A design system is only as good as its documentation.
Towards the end of the project, it became clear that without thorough documentation of the decisions and rationale behind the system, future team members would inevitably deviate from it - reintroducing the exact inconsistencies we'd just spent months eliminating. Documentation isn't an afterthought; it's what makes a system transferable.
Tokens change how designers think.
Implementing design tokens was the single most transformative decision of the project. Beyond the practical benefits of reskinning and GitHub-linked consistency, tokens pushed the design team to think more structurally - considering how decisions would cascade across a system, not just how they'd look on a single screen.
Rebuilding from scratch requires discipline.
The temptation to patch rather than rebuild is real, especially under time pressure. Committing to a clean rebuild - starting from atoms and building up - was the right call. The resulting system was coherent in a way that incremental patching never could have achieved.
Next Steps
The design system provides the foundation; the next phase is full rollout. Every website in the EonX ecosystem needs to be rebuilt using the new components and sourcing tokens from the correct repository. As new clients are onboarded, designers will create client-specific token sets to match their branding - the reskinning capability built into the system makes this a configuration task rather than a design task. Comprehensive public-facing documentation should be built and hosted, covering colour usage, component behaviour, interaction patterns, and the reasoning behind key decisions - so the system can grow without losing coherence.
More works
Apr 2022 - Nov 2022
EonX Design System
Creating a new design system that accounts for scalability and team unification.
Design System
Tokens
Overview
EonX is a fintech company operating multiple customer-facing websites from a single shared design system. One website was an employee benefits including employee discounts at affiliate stores and bulletin hub that adopts client branding. When the new design team was assembled, that system hadn't been meaningfully updated in years. The visual language was fragmented, the codebase was out of step with the designs, and accessibility failures were serious enough to carry legal risk.
The brief was clear: rebuild the design system from the ground up. Not patch it - rebuild it. A system that met modern accessibility standards, gave designers a single source of truth, and could scale across multiple brands without starting from scratch each time.
My Role
I was one of three designers on the project, working alongside a design lead and a senior UX/UI designer.
My responsibilities covered the full span of the build: auditing the existing system, researching best-in-class design systems, rebuilding from foundational tokens upward, and constructing the component library through to page-level templates. Developers also underwent accessibility training and this opportunity allows us to become WCAG AA compliant.
Problem
The audit told a clear story. EonX's websites were being held together by design decisions made at different times, by different people, without a shared framework. The result was a system that was inconsistent, inaccessible, and genuinely painful to work with.
Accessibility failures with legal exposure
The live product did not meet WCAG AA standards. Colour contrast failures were widespread - buttons, text, and interactive elements across multiple sites were failing basic legibility thresholds. For the commercial product handling financial data, this wasn't just a design quality issue - it was a compliance and legal risk.
Visual inconsistency at every level
The design files showed the hallmarks of accumulated design debt: icon line weights that varied within the same page, icon sizes that skipped major intervals, buttons that changed shape between desktop and mobile, and a general incoherence that made the product feel unpolished and untrustworthy.
No shared source of truth
Design assets were scattered across multiple files with no clear canonical version. When starting a new project, the team would rebuild prototyped components from scratch each time. There was no reliable reference point - for designers or developers.
No rebranding capability for white-label clients
EonX's core product was a white-label suite - an employee benefits portal, a bulletin board, and a communications site - licensed to client organisations who expected it to reflect their own brand. The existing design system had no mechanism to support this. Every new client rebrand meant manually reworking components and styles from scratch, creating significant overhead and making the process difficult to scale.
Goals
Improve accessibility, usability and designer efficiency.
Resolve all WCAG AA accessibility failures across the suite of websites
Consolidate all design decisions into a single, well-organised file that serves as a source of truth for both design and development
Dramatically increase prototyping productivity by building pre-prototyped, reusable components
Build rebranding capability into the system's tokenised component architecture, so EonX's white-label suite could be reskinned per client without rebuilding components each time
Outcomes
The rebuilt design system was delivered in full and exceeded expectations on every front.
500% increase in prototyping productivity - pre-prototyped components meant a Figma file could replicate a live website experience in a fraction of the previous time
Full WCAG AA compliance achieved across the colour system through rigorously tested, accessible token pairings and component anatomy
Reskinning capability unlocked for white-label clients - design tokens linked to a GitHub repository allowed EonX's employee benefits and communications site to be rebranded per client by swapping token sets, turning what was previously a manual rebuild into a configuration task
Single source of truth established for both design and development, eliminating the ambiguity and duplication that had slowed the team down
Process
Process - Discover
I began with a thorough audit of the existing design files, live websites, and component library. The scope of the problem became clear quickly. Beyond the known accessibility failures, the icon set alone had four distinct issues: inconsistent stroke caps (some round, some square), varying fill styles within the same thematic group, line weights that deviated from the 2px standard, and size increments that ignored the established spacing scale.
Researching well-regarded design systems - including those from major product companies - helped establish a benchmark. The patterns were consistent across the best systems: icons with uniform line weight and size, type scales with clear visual hierarchy, colours used with semantic intent, accessibility treated as a requirement rather than a retrospective check, and design tokens as the connective tissue holding everything together.
Process - Develop
With the audit complete and a clear picture of what good looked like, I adopted Brad Frost's Atomic Design methodology to structure the build - atoms first, then molecules, organisms, templates, and pages. The approach was deliberate: each component tier references and builds on the one before it, which keeps the system scalable and internally consistent by design.
Colour
I rebuilt the colour palette from scratch, stress-testing every value against WCAG AA contrast requirements before committing it to the system. Accessible pairings were baked into the token naming structure so designers could make correct choices by default rather than by manual checking.
Typography
Font scales were rebuilt with appropriate visual intervals for both desktop and mobile contexts, replacing the ad hoc sizing decisions that had accumulated in the previous system.
Remaining foundations
Spacing, sizing, stroke widths, border radius, blur, and opacity values were all systematised and documented - the unglamorous but essential scaffolding that makes a design system feel coherent rather than cobbled together.
Component Construction
Building the component library was the most complex phase of the project. Pre-prototyped components - with hover states, focus states, expanded states, and animated transitions all built in - required careful thought about how each state would behave across different contexts and screen sizes.
All states had to meet accessibility contrast thresholds, not just look good. Expanding elements needed to animate correctly without breaking layouts. Button placements and labels followed established interaction design conventions to ensure predictability for users across the sites.
The investment paid off directly in productivity: once the component library was in place, new pages could be assembled and prototyped in a fraction of the time previously required.
Design Tokens
The impact was significant - and most immediately felt in EonX's white-label business. The core product suite (an employee benefits portal, a bulletin board, and a client communications site) was licensed to multiple client organisations, each expecting the product to carry their own brand. Previously, every new client meant manually reworking components and styles from the ground up.
Process - Launch & Test
With the token system in place, each client brand could be expressed as its own token set within the plugin - swapping colours, typography, and visual style across the entire component library instantly, without touching a single component. What had been a significant design and development effort was reduced to a configuration task reducing the work from a week to under a day.
The impact was significant. Each brand could maintain its own token set within the plugin, with global and semantic tokens structured to allow complete visual transformations - colour, typography, spacing - without touching a single component. Tokens also brought the design and development teams into closer alignment, encoding design decisions in a format developers could consume directly rather than interpret from static files.
This was also where I first deepened my understanding of how to communicate design decisions in a developer-friendly way - adopting Tailwind CSS naming conventions for tokens made the handoff substantially cleaner.
Learnings
Accessibility is easier to build in than to retrofit.
The contrast failures in the original system existed partly because accessibility had never been a first-class constraint. Rebuilding with WCAG AA compliance as a hard requirement from the token level up meant it was never something to chase after the fact.
A design system is only as good as its documentation.
Towards the end of the project, it became clear that without thorough documentation of the decisions and rationale behind the system, future team members would inevitably deviate from it - reintroducing the exact inconsistencies we'd just spent months eliminating. Documentation isn't an afterthought; it's what makes a system transferable.
Tokens change how designers think.
Implementing design tokens was the single most transformative decision of the project. Beyond the practical benefits of reskinning and GitHub-linked consistency, tokens pushed the design team to think more structurally - considering how decisions would cascade across a system, not just how they'd look on a single screen.
Rebuilding from scratch requires discipline.
The temptation to patch rather than rebuild is real, especially under time pressure. Committing to a clean rebuild - starting from atoms and building up - was the right call. The resulting system was coherent in a way that incremental patching never could have achieved.
Next Steps
The design system provides the foundation; the next phase is full rollout. Every website in the EonX ecosystem needs to be rebuilt using the new components and sourcing tokens from the correct repository. As new clients are onboarded, designers will create client-specific token sets to match their branding - the reskinning capability built into the system makes this a configuration task rather than a design task. Comprehensive public-facing documentation should be built and hosted, covering colour usage, component behaviour, interaction patterns, and the reasoning behind key decisions - so the system can grow without losing coherence.
More works
Apr 2022 - Nov 2022
EonX Design System
Creating a new design system that accounts for scalability and team unification.
Design System
Tokens
Overview
EonX is a fintech company operating multiple customer-facing websites from a single shared design system. One website was an employee benefits including employee discounts at affiliate stores and bulletin hub that adopts client branding. When the new design team was assembled, that system hadn't been meaningfully updated in years. The visual language was fragmented, the codebase was out of step with the designs, and accessibility failures were serious enough to carry legal risk.
The brief was clear: rebuild the design system from the ground up. Not patch it - rebuild it. A system that met modern accessibility standards, gave designers a single source of truth, and could scale across multiple brands without starting from scratch each time.
My Role
I was one of three designers on the project, working alongside a design lead and a senior UX/UI designer.
My responsibilities covered the full span of the build: auditing the existing system, researching best-in-class design systems, rebuilding from foundational tokens upward, and constructing the component library through to page-level templates. Developers also underwent accessibility training and this opportunity allows us to become WCAG AA compliant.
Problem
The audit told a clear story. EonX's websites were being held together by design decisions made at different times, by different people, without a shared framework. The result was a system that was inconsistent, inaccessible, and genuinely painful to work with.
Accessibility failures with legal exposure
The live product did not meet WCAG AA standards. Colour contrast failures were widespread - buttons, text, and interactive elements across multiple sites were failing basic legibility thresholds. For the commercial product handling financial data, this wasn't just a design quality issue - it was a compliance and legal risk.
Visual inconsistency at every level
The design files showed the hallmarks of accumulated design debt: icon line weights that varied within the same page, icon sizes that skipped major intervals, buttons that changed shape between desktop and mobile, and a general incoherence that made the product feel unpolished and untrustworthy.
No shared source of truth
Design assets were scattered across multiple files with no clear canonical version. When starting a new project, the team would rebuild prototyped components from scratch each time. There was no reliable reference point - for designers or developers.
No rebranding capability for white-label clients
EonX's core product was a white-label suite - an employee benefits portal, a bulletin board, and a communications site - licensed to client organisations who expected it to reflect their own brand. The existing design system had no mechanism to support this. Every new client rebrand meant manually reworking components and styles from scratch, creating significant overhead and making the process difficult to scale.
Goals
Improve accessibility, usability and designer efficiency.
Resolve all WCAG AA accessibility failures across the suite of websites
Consolidate all design decisions into a single, well-organised file that serves as a source of truth for both design and development
Dramatically increase prototyping productivity by building pre-prototyped, reusable components
Build rebranding capability into the system's tokenised component architecture, so EonX's white-label suite could be reskinned per client without rebuilding components each time
Outcomes
The rebuilt design system was delivered in full and exceeded expectations on every front.
500% increase in prototyping productivity - pre-prototyped components meant a Figma file could replicate a live website experience in a fraction of the previous time
Full WCAG AA compliance achieved across the colour system through rigorously tested, accessible token pairings and component anatomy
Reskinning capability unlocked for white-label clients - design tokens linked to a GitHub repository allowed EonX's employee benefits and communications site to be rebranded per client by swapping token sets, turning what was previously a manual rebuild into a configuration task
Single source of truth established for both design and development, eliminating the ambiguity and duplication that had slowed the team down
Process
Process - Discover
I began with a thorough audit of the existing design files, live websites, and component library. The scope of the problem became clear quickly. Beyond the known accessibility failures, the icon set alone had four distinct issues: inconsistent stroke caps (some round, some square), varying fill styles within the same thematic group, line weights that deviated from the 2px standard, and size increments that ignored the established spacing scale.
Researching well-regarded design systems - including those from major product companies - helped establish a benchmark. The patterns were consistent across the best systems: icons with uniform line weight and size, type scales with clear visual hierarchy, colours used with semantic intent, accessibility treated as a requirement rather than a retrospective check, and design tokens as the connective tissue holding everything together.
Process - Develop
With the audit complete and a clear picture of what good looked like, I adopted Brad Frost's Atomic Design methodology to structure the build - atoms first, then molecules, organisms, templates, and pages. The approach was deliberate: each component tier references and builds on the one before it, which keeps the system scalable and internally consistent by design.
Colour
I rebuilt the colour palette from scratch, stress-testing every value against WCAG AA contrast requirements before committing it to the system. Accessible pairings were baked into the token naming structure so designers could make correct choices by default rather than by manual checking.
Typography
Font scales were rebuilt with appropriate visual intervals for both desktop and mobile contexts, replacing the ad hoc sizing decisions that had accumulated in the previous system.
Remaining foundations
Spacing, sizing, stroke widths, border radius, blur, and opacity values were all systematised and documented - the unglamorous but essential scaffolding that makes a design system feel coherent rather than cobbled together.
Component Construction
Building the component library was the most complex phase of the project. Pre-prototyped components - with hover states, focus states, expanded states, and animated transitions all built in - required careful thought about how each state would behave across different contexts and screen sizes.
All states had to meet accessibility contrast thresholds, not just look good. Expanding elements needed to animate correctly without breaking layouts. Button placements and labels followed established interaction design conventions to ensure predictability for users across the sites.
The investment paid off directly in productivity: once the component library was in place, new pages could be assembled and prototyped in a fraction of the time previously required.
Design Tokens
The impact was significant - and most immediately felt in EonX's white-label business. The core product suite (an employee benefits portal, a bulletin board, and a client communications site) was licensed to multiple client organisations, each expecting the product to carry their own brand. Previously, every new client meant manually reworking components and styles from the ground up.
Process - Launch & Test
With the token system in place, each client brand could be expressed as its own token set within the plugin - swapping colours, typography, and visual style across the entire component library instantly, without touching a single component. What had been a significant design and development effort was reduced to a configuration task reducing the work from a week to under a day.
The impact was significant. Each brand could maintain its own token set within the plugin, with global and semantic tokens structured to allow complete visual transformations - colour, typography, spacing - without touching a single component. Tokens also brought the design and development teams into closer alignment, encoding design decisions in a format developers could consume directly rather than interpret from static files.
This was also where I first deepened my understanding of how to communicate design decisions in a developer-friendly way - adopting Tailwind CSS naming conventions for tokens made the handoff substantially cleaner.
Learnings
Accessibility is easier to build in than to retrofit.
The contrast failures in the original system existed partly because accessibility had never been a first-class constraint. Rebuilding with WCAG AA compliance as a hard requirement from the token level up meant it was never something to chase after the fact.
A design system is only as good as its documentation.
Towards the end of the project, it became clear that without thorough documentation of the decisions and rationale behind the system, future team members would inevitably deviate from it - reintroducing the exact inconsistencies we'd just spent months eliminating. Documentation isn't an afterthought; it's what makes a system transferable.
Tokens change how designers think.
Implementing design tokens was the single most transformative decision of the project. Beyond the practical benefits of reskinning and GitHub-linked consistency, tokens pushed the design team to think more structurally - considering how decisions would cascade across a system, not just how they'd look on a single screen.
Rebuilding from scratch requires discipline.
The temptation to patch rather than rebuild is real, especially under time pressure. Committing to a clean rebuild - starting from atoms and building up - was the right call. The resulting system was coherent in a way that incremental patching never could have achieved.
Next Steps
The design system provides the foundation; the next phase is full rollout. Every website in the EonX ecosystem needs to be rebuilt using the new components and sourcing tokens from the correct repository. As new clients are onboarded, designers will create client-specific token sets to match their branding - the reskinning capability built into the system makes this a configuration task rather than a design task. Comprehensive public-facing documentation should be built and hosted, covering colour usage, component behaviour, interaction patterns, and the reasoning behind key decisions - so the system can grow without losing coherence.
More works