Jul 2023 - Oct 2023
Punters Design System
Build a design system from scratch to be adopted by the product team to streamline their workflow.
Design System
Tokens
Overview
Punters is a racing media platform that helps punters make smarter betting decisions through rich statistical data on horse and greyhound racing. Its core audience - men aged 20 to 40 - had been using the site since its establishment in 2014, but the product had never been built on a unified design system. A decade of design debt had accumulated: inconsistent visual patterns, significant accessibility failures, and a codebase split across misaligned technologies. When the development team committed to migrating from Nuxt 2 to Nuxt 3, it created the perfect time to align both teams. A clean technical slate meant a genuine opportunity to build a design system from scratch - one that would align designers and developers on a single source of truth, fix long-standing accessibility issues, and set the platform up to scale.
I resolved accessibility errors, boosted designer productivity by 30%, and built a tokenised system scalable enough to rebrand an entire sister site - saving the team close to a month of rework down the line.
My Role
I was the lead designer for the design system, with full ownership over its architecture and execution.
This included creating and naming design tokens, building tokenised components, establishing Figma styles and variables, and prototyping interactive components. I also led adoption across a cross-functional team of 15 - designers, developers, and product managers - guiding them through an entirely new way of working.
Problem
Many inconsistencies and errors haven't been addressed in years causing designers, developers and even users to work harder.
A thorough audit of the design files, website, and CSS codebase revealed the scale of the problem. There was no consistent colour scale, no type system, no unified spacing or grid - and 65 shades of grey in use across the source files alone. Icon styles varied even when representing identical concepts.
Components were managed separately across four platforms - desktop web, mobile web, iOS, and Android - making updates slow, error-prone, and expensive in both designer and developer time.
The accessibility situation was particularly acute. Using the WAVE web accessibility tool, I audited the six most visited pages and found over 1,450 contrast errors.
For a platform asking users to trust it with data-driven decisions, these weren't just compliance gaps - they were credibility gaps.
An Audit using the WAVE extension picked up these accessibility errors on the Form Index and Form Guide
Goals
Unify the team through a single source of truth and optimise the design to development process.
Build a fully tokenised design system within three months to feed directly into the website rebuild
Resolve basic accessibility failures across the site and achieve WCAG AA compliance
Create a unified source of truth that aligns designers and developers
Increase design and development efficiency through reusable, scalable tokenised components
Maintain the existing brand feel to avoid alienating a loyal, established user base
Future-proof the system with dark mode support and rebranding flexibility - including a parallel application to the sister site, Racenet
Outcomes
Design system executed and exceeded expectations on many metrics
The design system was fully adopted by both design and development teams within three months of kickoff.
30% increase in designer productivity - projects that previously took a week were completed in 3–4 days, freeing designers to focus on higher-order UX problems but also streamlining the process by removing wireframing as components were already built to instantly produce a high fidelity mockup.
Near-complete resolution of contrast errors - consistent, tokenised colour pairings brought the site to WCAG AA compliance across almost all components (remaining errors in the navigation header are tied to a full tech stack migration, not the design system)
Accessibility baked in by default - optimal touch target sizes, focus states, alt text, and ARIA support built into every component
Developers eliminated guesswork - the token system removed the need to manually hunt design files for CSS properties, significantly streamlining the build process
Months saved on Racenet rebranding - the system's rebranding architecture reduced the effort of adapting designs to the sister site dramatically.
Comprehensive documentation created so future team members could onboard independently, without tribal knowledge
Retesting the same pages implementing the design system found major improvements in accessibility
Showcase of how the tokens can be quickly reskinned to dark mode and other brands.
Process
Process - Discover
Audit & Analysis
Before designing anything, I needed to understand the full scope of what existed. I audited the Sketch design files, the live website, and the CSS codebase end to end.
The picture that emerged was one of accumulated inconsistency: no cohesive colour palette, no consistent icon library, no type scale, no shared spacing system, and no grid. The 65 shades of grey were a symptom of a deeper problem - without a system, every designer had been making independent decisions, and those decisions had compounded over years into something genuinely difficult to work with or build on.
The WAVE accessibility audit made the stakes concrete. 1,450+ contrast errors across six pages wasn't an abstract design quality issue - it was a measurable failure to serve users.
Process - Develop
Building the Foundation
Core Tokens and Component Architecture
With a three-month deadline and a clear brief, I chose Token Studio as the Figma plugin to implement the token architecture, and adopted Brad Frost's Atomic Design methodology as the structural framework. Both decisions were deliberate: Token Studio gave us a robust, exportable token file that developers could attach directly to their flow; Atomic Design gave the team a shared mental model for how components related to each other.
The brief had one important constraint: don't alienate existing users. The rebrand needed to feel like an evolution, not a replacement.
Typography
I retained the existing Roboto typeface and base font size - familiar to users and well-supported across platforms. For the type scale, the data-heavy nature of the content called for a compact, low-contrast solution. I settled on a 1.2 Minor Third scale, with desktop sizes running slightly larger than mobile to take advantage of the available screen real estate. A separate iOS token set using SF Pro was built in parallel, laying the groundwork for extending the system to other platforms and brands.
Colour
The existing colour palette had two problems: the naming was opaque, and the pairings didn't meet accessibility standards. I began by extracting and refining the palette in Atmos, but quickly hit its limits - certain colours couldn't be reliably adjusted for contrast, and dark mode support was out of scope entirely.
The solution was Leonardo Color, which generates perceptually consistent colour scales with predictable contrast at every step. The outcome was a scale where any colour at token level 600 or above, paired with a level 50 or below colour, would reliably pass WCAG AA contrast standards. Designers no longer needed to manually check every pairing - the system encoded accessibility into the naming convention. Leonardo's dark mode generation also gave us the dark palette we needed to future-proof the system without doubling the design work.
The colour scales for Punters in light and dark modes
Remaining Tokens
Spacing, sizing, border radius, border widths, opacity, shadows, and blur tokens were systematically defined and integrated — straightforward to produce once the colour and type foundations were in place.
Iconography
For iconography, I adopted the Material icon library as the default set. It closely matched the existing icon style, reduced the effort of custom icon creation significantly, and still left room for bespoke icons where the brand required it.
The Material icons have a specific style that is easy to emulate to create custom icons
Building Components
With core tokens in place, I began building components using the Atomic Design hierarchy - atoms first, then molecules, organisms, and templates. Standard universal components came first: buttons, inputs, checkboxes, breadcrumbs, dropdowns, and form elements.
One early and important lesson: building components in isolation doesn't work. A button's required variants only become apparent when it's placed in context - inside a form, a modal, a table row. The shift to building against real pages - replacing existing elements with new components as we went - gave us a far more honest picture of how the system would actually perform.
On the token architecture, my team and I made a deliberate call to stop at semantic tokens rather than pushing to component-level tokens. Given the timeline and team size, component tokens would have added significant overhead without meaningfully improving rebranding flexibility - the semantic layer already gave me everything I needed within the current timeframe.
Token Studio semantic tokens
Some of the selected semantic tokens used to build components
Accessibility as architecture, not afterthought
Every component was built with WCAG AA compliance as a requirement, not a review step. Accessible colour token pairings, minimum touch target sizes, keyboard focus states, screen reader labels, error messages and ARIA attributes were built into the component structure itself. Accessibility wasn't a checklist at the end - it was load-bearing.
Process - Launch & Test
Documentation & Adoption
A design system is only as valuable as its adoption. Alongside building the system, I created comprehensive documentation covering colour usage, typography, component behaviour, interaction patterns, and the rationale behind key decisions.
This documentation proved critical: as the team scaled and new people joined, they could onboard independently without relying on tribal knowledge. It also became a reference for resolving design debates - decisions that had already been made and reasoned through didn't need to be relitigated.
Leading adoption across 15 people - many of whom had never worked with a token-based system before - required as much communication investment as design investment. The concept of tokens was unfamiliar to most of the team. Building confidence meant presenting clearly, explaining the why behind architectural decisions, and demonstrating the efficiency gains early to build buy-in.
Learnings
Constraints sharpen decisions
A three-month deadline with a live rebrand downstream meant every architectural choice had to be justified by impact. The call to stop at semantic tokens rather than component tokens was right for the context — perfectionism would have cost the project.
Accessibility is a systems problem
Fixing 1,450 contrast errors one by one would have been unsustainable. Encoding accessibility into the token architecture meant compliance became automatic rather than effortful - the right solution was structural, not manual.
Documentation is design work
A system that only exists in the heads of its creators isn't a system - it's a dependency. Investing in documentation wasn't overhead; it was what made the system genuinely transferable.
Tokens need translation
Working with Android developers to convert tokens into Compose-compatible formats was unexpectedly complex. Building those cross-functional bridges early — and understanding each platform's constraints - is essential for a design system to land well beyond the design file.
Leading without authority is a skill
Guiding a team of 15 through an unfamiliar workflow, without being able to mandate adoption, required clarity, patience, and consistent demonstration of value. Earning the team's trust in the system was as important as building the system itself.
Next Steps
A design system is never finished. Components will be added as new product features are built, tokens will evolve as the brand develops, and Figma's native variables capability may eventually supersede Token Studio for parts of the workflow. The priority now is maintaining the documentation discipline and governance processes that keep the system trustworthy - so that designers and developers continue to reach for it first, rather than working around it.
More works
Jul 2023 - Oct 2023
Punters Design System
Build a design system from scratch to be adopted by the product team to streamline their workflow.
Design System
Tokens
Overview
Punters is a racing media platform that helps punters make smarter betting decisions through rich statistical data on horse and greyhound racing. Its core audience - men aged 20 to 40 - had been using the site since its establishment in 2014, but the product had never been built on a unified design system. A decade of design debt had accumulated: inconsistent visual patterns, significant accessibility failures, and a codebase split across misaligned technologies. When the development team committed to migrating from Nuxt 2 to Nuxt 3, it created the perfect time to align both teams. A clean technical slate meant a genuine opportunity to build a design system from scratch - one that would align designers and developers on a single source of truth, fix long-standing accessibility issues, and set the platform up to scale.
I resolved accessibility errors, boosted designer productivity by 30%, and built a tokenised system scalable enough to rebrand an entire sister site - saving the team close to a month of rework down the line.
My Role
I was the lead designer for the design system, with full ownership over its architecture and execution.
This included creating and naming design tokens, building tokenised components, establishing Figma styles and variables, and prototyping interactive components. I also led adoption across a cross-functional team of 15 - designers, developers, and product managers - guiding them through an entirely new way of working.
Problem
Many inconsistencies and errors haven't been addressed in years causing designers, developers and even users to work harder.
A thorough audit of the design files, website, and CSS codebase revealed the scale of the problem. There was no consistent colour scale, no type system, no unified spacing or grid - and 65 shades of grey in use across the source files alone. Icon styles varied even when representing identical concepts.
Components were managed separately across four platforms - desktop web, mobile web, iOS, and Android - making updates slow, error-prone, and expensive in both designer and developer time.
The accessibility situation was particularly acute. Using the WAVE web accessibility tool, I audited the six most visited pages and found over 1,450 contrast errors.
For a platform asking users to trust it with data-driven decisions, these weren't just compliance gaps - they were credibility gaps.
An Audit using the WAVE extension picked up these accessibility errors on the Form Index and Form Guide
Goals
Unify the team through a single source of truth and optimise the design to development process.
Build a fully tokenised design system within three months to feed directly into the website rebuild
Resolve basic accessibility failures across the site and achieve WCAG AA compliance
Create a unified source of truth that aligns designers and developers
Increase design and development efficiency through reusable, scalable tokenised components
Maintain the existing brand feel to avoid alienating a loyal, established user base
Future-proof the system with dark mode support and rebranding flexibility - including a parallel application to the sister site, Racenet
Outcomes
Design system executed and exceeded expectations on many metrics
The design system was fully adopted by both design and development teams within three months of kickoff.
30% increase in designer productivity - projects that previously took a week were completed in 3–4 days, freeing designers to focus on higher-order UX problems but also streamlining the process by removing wireframing as components were already built to instantly produce a high fidelity mockup.
Near-complete resolution of contrast errors - consistent, tokenised colour pairings brought the site to WCAG AA compliance across almost all components (remaining errors in the navigation header are tied to a full tech stack migration, not the design system)
Accessibility baked in by default - optimal touch target sizes, focus states, alt text, and ARIA support built into every component
Developers eliminated guesswork - the token system removed the need to manually hunt design files for CSS properties, significantly streamlining the build process
Months saved on Racenet rebranding - the system's rebranding architecture reduced the effort of adapting designs to the sister site dramatically.
Comprehensive documentation created so future team members could onboard independently, without tribal knowledge
Retesting the same pages implementing the design system found major improvements in accessibility
Showcase of how the tokens can be quickly reskinned to dark mode and other brands.
Process
Process - Discover
Audit & Analysis
Before designing anything, I needed to understand the full scope of what existed. I audited the Sketch design files, the live website, and the CSS codebase end to end.
The picture that emerged was one of accumulated inconsistency: no cohesive colour palette, no consistent icon library, no type scale, no shared spacing system, and no grid. The 65 shades of grey were a symptom of a deeper problem - without a system, every designer had been making independent decisions, and those decisions had compounded over years into something genuinely difficult to work with or build on.
The WAVE accessibility audit made the stakes concrete. 1,450+ contrast errors across six pages wasn't an abstract design quality issue - it was a measurable failure to serve users.
Process - Develop
Building the Foundation
Core Tokens and Component Architecture
With a three-month deadline and a clear brief, I chose Token Studio as the Figma plugin to implement the token architecture, and adopted Brad Frost's Atomic Design methodology as the structural framework. Both decisions were deliberate: Token Studio gave us a robust, exportable token file that developers could attach directly to their flow; Atomic Design gave the team a shared mental model for how components related to each other.
The brief had one important constraint: don't alienate existing users. The rebrand needed to feel like an evolution, not a replacement.
Typography
I retained the existing Roboto typeface and base font size - familiar to users and well-supported across platforms. For the type scale, the data-heavy nature of the content called for a compact, low-contrast solution. I settled on a 1.2 Minor Third scale, with desktop sizes running slightly larger than mobile to take advantage of the available screen real estate. A separate iOS token set using SF Pro was built in parallel, laying the groundwork for extending the system to other platforms and brands.
Colour
The existing colour palette had two problems: the naming was opaque, and the pairings didn't meet accessibility standards. I began by extracting and refining the palette in Atmos, but quickly hit its limits - certain colours couldn't be reliably adjusted for contrast, and dark mode support was out of scope entirely.
The solution was Leonardo Color, which generates perceptually consistent colour scales with predictable contrast at every step. The outcome was a scale where any colour at token level 600 or above, paired with a level 50 or below colour, would reliably pass WCAG AA contrast standards. Designers no longer needed to manually check every pairing - the system encoded accessibility into the naming convention. Leonardo's dark mode generation also gave us the dark palette we needed to future-proof the system without doubling the design work.
The colour scales for Punters in light and dark modes
Remaining Tokens
Spacing, sizing, border radius, border widths, opacity, shadows, and blur tokens were systematically defined and integrated — straightforward to produce once the colour and type foundations were in place.
Iconography
For iconography, I adopted the Material icon library as the default set. It closely matched the existing icon style, reduced the effort of custom icon creation significantly, and still left room for bespoke icons where the brand required it.
The Material icons have a specific style that is easy to emulate to create custom icons
Building Components
With core tokens in place, I began building components using the Atomic Design hierarchy - atoms first, then molecules, organisms, and templates. Standard universal components came first: buttons, inputs, checkboxes, breadcrumbs, dropdowns, and form elements.
One early and important lesson: building components in isolation doesn't work. A button's required variants only become apparent when it's placed in context - inside a form, a modal, a table row. The shift to building against real pages - replacing existing elements with new components as we went - gave us a far more honest picture of how the system would actually perform.
On the token architecture, my team and I made a deliberate call to stop at semantic tokens rather than pushing to component-level tokens. Given the timeline and team size, component tokens would have added significant overhead without meaningfully improving rebranding flexibility - the semantic layer already gave me everything I needed within the current timeframe.
Token Studio semantic tokens
Some of the selected semantic tokens used to build components
Accessibility as architecture, not afterthought
Every component was built with WCAG AA compliance as a requirement, not a review step. Accessible colour token pairings, minimum touch target sizes, keyboard focus states, screen reader labels, error messages and ARIA attributes were built into the component structure itself. Accessibility wasn't a checklist at the end - it was load-bearing.
Process - Launch & Test
Documentation & Adoption
A design system is only as valuable as its adoption. Alongside building the system, I created comprehensive documentation covering colour usage, typography, component behaviour, interaction patterns, and the rationale behind key decisions.
This documentation proved critical: as the team scaled and new people joined, they could onboard independently without relying on tribal knowledge. It also became a reference for resolving design debates - decisions that had already been made and reasoned through didn't need to be relitigated.
Leading adoption across 15 people - many of whom had never worked with a token-based system before - required as much communication investment as design investment. The concept of tokens was unfamiliar to most of the team. Building confidence meant presenting clearly, explaining the why behind architectural decisions, and demonstrating the efficiency gains early to build buy-in.
Learnings
Constraints sharpen decisions
A three-month deadline with a live rebrand downstream meant every architectural choice had to be justified by impact. The call to stop at semantic tokens rather than component tokens was right for the context — perfectionism would have cost the project.
Accessibility is a systems problem
Fixing 1,450 contrast errors one by one would have been unsustainable. Encoding accessibility into the token architecture meant compliance became automatic rather than effortful - the right solution was structural, not manual.
Documentation is design work
A system that only exists in the heads of its creators isn't a system - it's a dependency. Investing in documentation wasn't overhead; it was what made the system genuinely transferable.
Tokens need translation
Working with Android developers to convert tokens into Compose-compatible formats was unexpectedly complex. Building those cross-functional bridges early — and understanding each platform's constraints - is essential for a design system to land well beyond the design file.
Leading without authority is a skill
Guiding a team of 15 through an unfamiliar workflow, without being able to mandate adoption, required clarity, patience, and consistent demonstration of value. Earning the team's trust in the system was as important as building the system itself.
Next Steps
A design system is never finished. Components will be added as new product features are built, tokens will evolve as the brand develops, and Figma's native variables capability may eventually supersede Token Studio for parts of the workflow. The priority now is maintaining the documentation discipline and governance processes that keep the system trustworthy - so that designers and developers continue to reach for it first, rather than working around it.
More works
Jul 2023 - Oct 2023
Punters Design System
Build a design system from scratch to be adopted by the product team to streamline their workflow.
Design System
Tokens
Overview
Punters is a racing media platform that helps punters make smarter betting decisions through rich statistical data on horse and greyhound racing. Its core audience - men aged 20 to 40 - had been using the site since its establishment in 2014, but the product had never been built on a unified design system. A decade of design debt had accumulated: inconsistent visual patterns, significant accessibility failures, and a codebase split across misaligned technologies. When the development team committed to migrating from Nuxt 2 to Nuxt 3, it created the perfect time to align both teams. A clean technical slate meant a genuine opportunity to build a design system from scratch - one that would align designers and developers on a single source of truth, fix long-standing accessibility issues, and set the platform up to scale.
I resolved accessibility errors, boosted designer productivity by 30%, and built a tokenised system scalable enough to rebrand an entire sister site - saving the team close to a month of rework down the line.
My Role
I was the lead designer for the design system, with full ownership over its architecture and execution.
This included creating and naming design tokens, building tokenised components, establishing Figma styles and variables, and prototyping interactive components. I also led adoption across a cross-functional team of 15 - designers, developers, and product managers - guiding them through an entirely new way of working.
Problem
Many inconsistencies and errors haven't been addressed in years causing designers, developers and even users to work harder.
A thorough audit of the design files, website, and CSS codebase revealed the scale of the problem. There was no consistent colour scale, no type system, no unified spacing or grid - and 65 shades of grey in use across the source files alone. Icon styles varied even when representing identical concepts.
Components were managed separately across four platforms - desktop web, mobile web, iOS, and Android - making updates slow, error-prone, and expensive in both designer and developer time.
The accessibility situation was particularly acute. Using the WAVE web accessibility tool, I audited the six most visited pages and found over 1,450 contrast errors.
For a platform asking users to trust it with data-driven decisions, these weren't just compliance gaps - they were credibility gaps.
An Audit using the WAVE extension picked up these accessibility errors on the Form Index and Form Guide
Goals
Unify the team through a single source of truth and optimise the design to development process.
Build a fully tokenised design system within three months to feed directly into the website rebuild
Resolve basic accessibility failures across the site and achieve WCAG AA compliance
Create a unified source of truth that aligns designers and developers
Increase design and development efficiency through reusable, scalable tokenised components
Maintain the existing brand feel to avoid alienating a loyal, established user base
Future-proof the system with dark mode support and rebranding flexibility - including a parallel application to the sister site, Racenet
Outcomes
Design system executed and exceeded expectations on many metrics
The design system was fully adopted by both design and development teams within three months of kickoff.
30% increase in designer productivity - projects that previously took a week were completed in 3–4 days, freeing designers to focus on higher-order UX problems but also streamlining the process by removing wireframing as components were already built to instantly produce a high fidelity mockup.
Near-complete resolution of contrast errors - consistent, tokenised colour pairings brought the site to WCAG AA compliance across almost all components (remaining errors in the navigation header are tied to a full tech stack migration, not the design system)
Accessibility baked in by default - optimal touch target sizes, focus states, alt text, and ARIA support built into every component
Developers eliminated guesswork - the token system removed the need to manually hunt design files for CSS properties, significantly streamlining the build process
Months saved on Racenet rebranding - the system's rebranding architecture reduced the effort of adapting designs to the sister site dramatically.
Comprehensive documentation created so future team members could onboard independently, without tribal knowledge
Retesting the same pages implementing the design system found major improvements in accessibility
Showcase of how the tokens can be quickly reskinned to dark mode and other brands.
Process
Process - Discover
Audit & Analysis
Before designing anything, I needed to understand the full scope of what existed. I audited the Sketch design files, the live website, and the CSS codebase end to end.
The picture that emerged was one of accumulated inconsistency: no cohesive colour palette, no consistent icon library, no type scale, no shared spacing system, and no grid. The 65 shades of grey were a symptom of a deeper problem - without a system, every designer had been making independent decisions, and those decisions had compounded over years into something genuinely difficult to work with or build on.
The WAVE accessibility audit made the stakes concrete. 1,450+ contrast errors across six pages wasn't an abstract design quality issue - it was a measurable failure to serve users.
Process - Develop
Building the Foundation
Core Tokens and Component Architecture
With a three-month deadline and a clear brief, I chose Token Studio as the Figma plugin to implement the token architecture, and adopted Brad Frost's Atomic Design methodology as the structural framework. Both decisions were deliberate: Token Studio gave us a robust, exportable token file that developers could attach directly to their flow; Atomic Design gave the team a shared mental model for how components related to each other.
The brief had one important constraint: don't alienate existing users. The rebrand needed to feel like an evolution, not a replacement.
Typography
I retained the existing Roboto typeface and base font size - familiar to users and well-supported across platforms. For the type scale, the data-heavy nature of the content called for a compact, low-contrast solution. I settled on a 1.2 Minor Third scale, with desktop sizes running slightly larger than mobile to take advantage of the available screen real estate. A separate iOS token set using SF Pro was built in parallel, laying the groundwork for extending the system to other platforms and brands.
Colour
The existing colour palette had two problems: the naming was opaque, and the pairings didn't meet accessibility standards. I began by extracting and refining the palette in Atmos, but quickly hit its limits - certain colours couldn't be reliably adjusted for contrast, and dark mode support was out of scope entirely.
The solution was Leonardo Color, which generates perceptually consistent colour scales with predictable contrast at every step. The outcome was a scale where any colour at token level 600 or above, paired with a level 50 or below colour, would reliably pass WCAG AA contrast standards. Designers no longer needed to manually check every pairing - the system encoded accessibility into the naming convention. Leonardo's dark mode generation also gave us the dark palette we needed to future-proof the system without doubling the design work.
The colour scales for Punters in light and dark modes
Remaining Tokens
Spacing, sizing, border radius, border widths, opacity, shadows, and blur tokens were systematically defined and integrated — straightforward to produce once the colour and type foundations were in place.
Iconography
For iconography, I adopted the Material icon library as the default set. It closely matched the existing icon style, reduced the effort of custom icon creation significantly, and still left room for bespoke icons where the brand required it.
The Material icons have a specific style that is easy to emulate to create custom icons
Building Components
With core tokens in place, I began building components using the Atomic Design hierarchy - atoms first, then molecules, organisms, and templates. Standard universal components came first: buttons, inputs, checkboxes, breadcrumbs, dropdowns, and form elements.
One early and important lesson: building components in isolation doesn't work. A button's required variants only become apparent when it's placed in context - inside a form, a modal, a table row. The shift to building against real pages - replacing existing elements with new components as we went - gave us a far more honest picture of how the system would actually perform.
On the token architecture, my team and I made a deliberate call to stop at semantic tokens rather than pushing to component-level tokens. Given the timeline and team size, component tokens would have added significant overhead without meaningfully improving rebranding flexibility - the semantic layer already gave me everything I needed within the current timeframe.
Token Studio semantic tokens
Some of the selected semantic tokens used to build components
Accessibility as architecture, not afterthought
Every component was built with WCAG AA compliance as a requirement, not a review step. Accessible colour token pairings, minimum touch target sizes, keyboard focus states, screen reader labels, error messages and ARIA attributes were built into the component structure itself. Accessibility wasn't a checklist at the end - it was load-bearing.
Process - Launch & Test
Documentation & Adoption
A design system is only as valuable as its adoption. Alongside building the system, I created comprehensive documentation covering colour usage, typography, component behaviour, interaction patterns, and the rationale behind key decisions.
This documentation proved critical: as the team scaled and new people joined, they could onboard independently without relying on tribal knowledge. It also became a reference for resolving design debates - decisions that had already been made and reasoned through didn't need to be relitigated.
Leading adoption across 15 people - many of whom had never worked with a token-based system before - required as much communication investment as design investment. The concept of tokens was unfamiliar to most of the team. Building confidence meant presenting clearly, explaining the why behind architectural decisions, and demonstrating the efficiency gains early to build buy-in.
Learnings
Constraints sharpen decisions
A three-month deadline with a live rebrand downstream meant every architectural choice had to be justified by impact. The call to stop at semantic tokens rather than component tokens was right for the context — perfectionism would have cost the project.
Accessibility is a systems problem
Fixing 1,450 contrast errors one by one would have been unsustainable. Encoding accessibility into the token architecture meant compliance became automatic rather than effortful - the right solution was structural, not manual.
Documentation is design work
A system that only exists in the heads of its creators isn't a system - it's a dependency. Investing in documentation wasn't overhead; it was what made the system genuinely transferable.
Tokens need translation
Working with Android developers to convert tokens into Compose-compatible formats was unexpectedly complex. Building those cross-functional bridges early — and understanding each platform's constraints - is essential for a design system to land well beyond the design file.
Leading without authority is a skill
Guiding a team of 15 through an unfamiliar workflow, without being able to mandate adoption, required clarity, patience, and consistent demonstration of value. Earning the team's trust in the system was as important as building the system itself.
Next Steps
A design system is never finished. Components will be added as new product features are built, tokens will evolve as the brand develops, and Figma's native variables capability may eventually supersede Token Studio for parts of the workflow. The priority now is maintaining the documentation discipline and governance processes that keep the system trustworthy - so that designers and developers continue to reach for it first, rather than working around it.
More works