Back
Back
Grid (Design System)
Multi-brand design system 1,248 tokens, 701 components, per-product theming across six platforms. Tokens sync to GitHub and ship to code without handoff. Built from scratch, plus the plugin ecosystem that maintains it.
YEAR
2025 - Current
ROLE
Design & Build
TEAM
Solo — built and maintained
PLATFORM
6+ platforms
STATUS
Live, daily use
Outcome
1,248 tokens 701 components 6+ platforms 4 months to usable Built solo. Adopted by every designer on the team, in daily use. Versioned releases with changelogs, full documentation, and two custom Figma plugins maintaining it.
Challenge
Mezorn ships a product suite — UBCab, UBCab Eats, UBCab Express, and payment products — that share structure but not appearance. Each has its own brand and its own audience, and each needs to feel like itself. What existed was a basic shared Figma library with no tokens. Components could be reused; values couldn't.
Every colour was a decision made again, per file, per designer, and nothing propagated. A brand change meant finding every instance by hand.
The constraint that shaped everything: engineering already built on
Material 3. Their components consumed M3's semantic names. A design system that ignored that would have required rewriting the component layer — which was never going to happen, and shouldn't have. So Grid had to give designers names they'd actually use, give engineers the M3 structure their components already spoke, and keep both in sync without a person in the middle.
My Role
Built Grid from nothing and still maintain it — token architecture, all 701 components, per-brand theming, documentation, the release process, and the two Figma plugins that audit and sync it.
Solo. No other designer contributes to the system; the rest of the team consumes it.
Process
Three tiers, because two wasn't enough
The standard advice is two layers: primitives, then semantic tokens. It would have failed here, because "semantic" meant two different things to two audiences.
Grid runs four collections:
1. Global — raw primitives. Every hex, every spacing step. No aliases; nothing points anywhere.
2. M3 - Light and M3 - Dark — flat collections that alias into Global. This is the layer engineering's Material components already consume.
3. Designer — carries Light and Dark modes, and aliases into M3. This is what designers actually pick from: bg/Cab/Base, text/Eats/Soft, stroke/MBank/Weak.
The middle layer is the translation. A designer choosing bg/Express/Sub never thinks about M3. An engineer's component never stops speaking M3.
Neither side absorbed the other's vocabulary, and the alias chain does the work between them.
This was the hardest part of the project and it looks like over-engineering until you know engineering was already on Material.
A naming scheme that scales to new brands
Every token is category/brand/weight. Categories are bg, text, stroke, icon, and overlay. Brands run Primary, Gray, Cab, Express, Eats, Pay, MBank. Weights run Strong, Base, Sub, Soft, Weak, White, with Dark and Disabled where the category needs them.
Semantic states — Error, Alert, Success, Info, Purple — use the same shape. The value of the grid is what it does to new products. Adding a brand isn't a design exercise, it's filling a known matrix: every category × every weight, already named, already scoped.
That's why one system can serve five platforms without each one negotiating its own vocabulary.
Tokens as source-controlled data
A design system that lives only in Figma stops at handoff. Grid's tokens sync to GitHub as Tokens Studio JSON, where developers consume them directly as data rather than reading values off a spec.
That's the second-hardest problem here, and it's why I built the sync plugin rather than exporting by hand: resolving a Designer token to a real hex means walking an alias chain across collection and mode boundaries, and getting that wrong ships light-mode colours into the dark theme.
Making compliance self-serve
Adoption was the easiest of the four problems, and it wasn't free. A system only works if people use it correctly, and policing that manually turns the system owner into a reviewer nobody wants to hear from.
So compliance became a tool: any designer runs the audit plugin before shipping, gets a health score, and fixes violations themselves. The system enforces itself instead of me enforcing it.
Versioned releases with changelogs and full documentation do the rest — people can see what changed and why without asking.
More on the tooling:
Trade-offs
The M3 layer is a permanent tax.
Every token traverses an extra hop, every alias chain is one level deeper, and any tooling I write has to resolve across a collection boundary. I'd make the same call — rewriting engineering's component layer was never the right trade — but it's a real cost paid on every change, not a free abstraction.
Solo ownership is a single point of failure.
Grid is used daily by the whole team and maintained by one person. That's fine at this size and it doesn't scale — documentation and versioning exist partly so the system survives me, but nobody else has contributed to it.
What I learned
The architecture was shaped by a constraint I didn't control. Engineering was on Material 3 and that wasn't changing, so the interesting question stopped being "what's the ideal token structure" and became "what structure lets both sides keep their own vocabulary." The three-tier answer only makes sense in that light.
Building the tooling was part of building the system, not extra. The sync and audit plugins exist because a 1,248-token system can't be maintained by hand — the moment it got big enough to be useful it got too big to police manually.
A grid is easier to extend than a taxonomy. Naming tokens
category/brand/weightmeans a new brand is a matrix to fill rather than a set of decisions to make. That's most of why five platforms didn't become five negotiations.
Back
Grid (Design System)
Multi-brand design system 1,248 tokens, 701 components, per-product theming across six platforms. Tokens sync to GitHub and ship to code without handoff. Built from scratch, plus the plugin ecosystem that maintains it.
YEAR
2025 - Current
ROLE
Design & Build
TEAM
Solo — built and maintained
PLATFORM
6+ platforms
STATUS
Live, daily use
Outcome
1,248 tokens 701 components 6+ platforms 4 months to usable Built solo. Adopted by every designer on the team, in daily use. Versioned releases with changelogs, full documentation, and two custom Figma plugins maintaining it.
Challenge
Mezorn ships a product suite — UBCab, UBCab Eats, UBCab Express, and payment products — that share structure but not appearance. Each has its own brand and its own audience, and each needs to feel like itself. What existed was a basic shared Figma library with no tokens. Components could be reused; values couldn't.
Every colour was a decision made again, per file, per designer, and nothing propagated. A brand change meant finding every instance by hand.
The constraint that shaped everything: engineering already built on
Material 3. Their components consumed M3's semantic names. A design system that ignored that would have required rewriting the component layer — which was never going to happen, and shouldn't have. So Grid had to give designers names they'd actually use, give engineers the M3 structure their components already spoke, and keep both in sync without a person in the middle.
My Role
Built Grid from nothing and still maintain it — token architecture, all 701 components, per-brand theming, documentation, the release process, and the two Figma plugins that audit and sync it.
Solo. No other designer contributes to the system; the rest of the team consumes it.
Process
Three tiers, because two wasn't enough
The standard advice is two layers: primitives, then semantic tokens. It would have failed here, because "semantic" meant two different things to two audiences.
Grid runs four collections:
1. Global — raw primitives. Every hex, every spacing step. No aliases; nothing points anywhere.
2. M3 - Light and M3 - Dark — flat collections that alias into Global. This is the layer engineering's Material components already consume.
3. Designer — carries Light and Dark modes, and aliases into M3. This is what designers actually pick from: bg/Cab/Base, text/Eats/Soft, stroke/MBank/Weak.
The middle layer is the translation. A designer choosing bg/Express/Sub never thinks about M3. An engineer's component never stops speaking M3.
Neither side absorbed the other's vocabulary, and the alias chain does the work between them.
This was the hardest part of the project and it looks like over-engineering until you know engineering was already on Material.
A naming scheme that scales to new brands
Every token is category/brand/weight. Categories are bg, text, stroke, icon, and overlay. Brands run Primary, Gray, Cab, Express, Eats, Pay, MBank. Weights run Strong, Base, Sub, Soft, Weak, White, with Dark and Disabled where the category needs them.
Semantic states — Error, Alert, Success, Info, Purple — use the same shape. The value of the grid is what it does to new products. Adding a brand isn't a design exercise, it's filling a known matrix: every category × every weight, already named, already scoped.
That's why one system can serve five platforms without each one negotiating its own vocabulary.
Tokens as source-controlled data
A design system that lives only in Figma stops at handoff. Grid's tokens sync to GitHub as Tokens Studio JSON, where developers consume them directly as data rather than reading values off a spec.
That's the second-hardest problem here, and it's why I built the sync plugin rather than exporting by hand: resolving a Designer token to a real hex means walking an alias chain across collection and mode boundaries, and getting that wrong ships light-mode colours into the dark theme.
Making compliance self-serve
Adoption was the easiest of the four problems, and it wasn't free. A system only works if people use it correctly, and policing that manually turns the system owner into a reviewer nobody wants to hear from.
So compliance became a tool: any designer runs the audit plugin before shipping, gets a health score, and fixes violations themselves. The system enforces itself instead of me enforcing it.
Versioned releases with changelogs and full documentation do the rest — people can see what changed and why without asking.
More on the tooling:
Trade-offs
The M3 layer is a permanent tax.
Every token traverses an extra hop, every alias chain is one level deeper, and any tooling I write has to resolve across a collection boundary. I'd make the same call — rewriting engineering's component layer was never the right trade — but it's a real cost paid on every change, not a free abstraction.
Solo ownership is a single point of failure.
Grid is used daily by the whole team and maintained by one person. That's fine at this size and it doesn't scale — documentation and versioning exist partly so the system survives me, but nobody else has contributed to it.
What I learned
The architecture was shaped by a constraint I didn't control. Engineering was on Material 3 and that wasn't changing, so the interesting question stopped being "what's the ideal token structure" and became "what structure lets both sides keep their own vocabulary." The three-tier answer only makes sense in that light.
Building the tooling was part of building the system, not extra. The sync and audit plugins exist because a 1,248-token system can't be maintained by hand — the moment it got big enough to be useful it got too big to police manually.
A grid is easier to extend than a taxonomy. Naming tokens
category/brand/weightmeans a new brand is a matrix to fill rather than a set of decisions to make. That's most of why five platforms didn't become five negotiations.