A Tale of 2 Systems
I joined Wildeye — mid-rebrand from Outpost Central — as its first UX designer: no design system, no brand guidelines, no shared definition of "good". I designed one OEM-ready system, and when handing it off failed, I hand-built its components myself — Vue 3 for web, React Native for mobile.
What I walked into
Straight out of university, into a company mid-rebrand and already selling to resellers who put their own branding on top. Internally: two products that shared customers but didn't feel related.
N-01
Two products, one customer — zero shared language
N-02
A .NET web UI running inside iframes, circa 2008
N-03
No design system, no brand guidelines, no “good”
Where it started
The problem wasn't the UI
The company had no shared language for product quality. In an OEM world that's dangerous: if the foundation is messy, white-labelling amplifies the mess.
FM-01
One-off features
Every feature was built from scratch, in its own way.
FM-02
Ad-hoc UI calls
Every engineer made their own visual decisions.
FM-03
Compounding drift
Every new screen pushed the product further apart.
FM-04
Mounting UI debt
Every “quick change” added long-term UI debt.
The reframe
Instead of "how do I design the next screen?" I started asking: how do I build something that makes the next 100 screens easier?
Two colours and a blank canvas
The rebrand gave me a logo. The logo gave me a starting point — and Figma gave the system its first home.
Brand → tokens
The logo is literally the palette: Wild blue and Eye green. From those two anchors I built a full neutral ramp and five semantic families — then abstracted all of it into implementation-ready tokens.
Wildeye Blue
GlobalBlue-900#00AEEF
→ 100 – 1300
Wildeye Green
GlobalGreen-700#0DB14B
→ 100 – 1300
Colour — from architecture to shipped tokens
Global architecture · 100 – 1300 · every hue, thirteen steps
Shipped neutrals · --color-grey-50 → 1200
Shipped semantics · base → dark, every state a token
Primary
Success
Warning
Error
Info
Top: the Figma architecture — global 100–1300 ramps across the full hue wheel. Below: the distillation that shipped, rendered live from tokens.css — the same file the Vue 3 and React Native libraries consume.
Typography had one job: disappear. Running under reseller brands, the typeface couldn't carry identity of its own — Inter is legible at 11px on a data table and genuinely neutral.
Type, space & surface
Spacing · 4px base
Radius · sm → full
Elevation · sm → xl
The real ramp, 36px down to 9px — set in Inter, the product face. The 475 weight is the system's signature: a variable-font medium tuned for 11px data tables.
The Figma side — where the system was born, before it learned to ship.
The white-label model added pressure: every choice had to be neutral enough for resellers to rebrand, but distinctive enough to hold product identity. That discipline made the system future-proof — nothing leans on brand personality to carry UX.
Built upward in layers
Atoms
Type, colour, spacing
Molecules
Buttons, inputs, fields
Organisms
Cards, modals, navigation
Templates
Dashboard layouts, steppers
Pages
Full feature experiences
Atoms → pages, live
LiveA live walk up the atomic ladder — every layer composed from the tokens above it.
The part that hurt: handoff
A Figma system doesn't automatically become a product system. I assumed engineers would treat designs as the source of truth; in reality they became rough guidelines.
Designed vs shipped
LiveOne side moves. One side is a screenshot of what survived the handoff. That gap is the whole story — and no amount of documentation was closing it.
Constant friction
F-01
Figma wasn’t their tool
Engineers weren’t comfortable working from design files — specs became suggestions.
F-02
Spacing drift, every time
Paddings and gaps changed in translation, screen after screen.
F-03
Responsive states improvised
Breakpoints and edge states were missed or invented on the spot.
F-04
Hours of “almost right” calls
Even with everything mapped, the shipped output still varied.
The pivot
The system wasn't failing. The handoff was.
So I stopped handing off. I hand-built the components myself — Vue 3 for the web app, React Native for mobile — and made the code the source of truth.
Design became something we ship
Storybook and component-driven development became the home of the system — and I took on the work that was blocking adoption: implementation.
With AI coding assistance I built, unit-tested and shipped every component in the library myself — no more handing off files and hoping. If a component looked or behaved wrong in production, it was on me to fix. Owning that loop end-to-end was the whole point.
Map
Audit the product; identify the reusable component set.
Migrate
Align with roadmap work — start small, prove value, expand.
Two libraries, one token layer
Same architecture on both stacks.
Vue 3webReact NativemobileThe trick: defining components at the token layer first, not the implementation layer. Vue 3 and React Native have completely different rendering models — but a button built from shared tokens looked and behaved identically on both.
Storybook — the living Vue 3 library
The real Storybook: Alerts, Buttons, Cards, Data Grids, Date Pickers and complex modals — each built once at the token layer, rendered live in Vue 3. Design stopped living in a file and became the source of truth in code.
Graph editor, rebuilt on the system
tokens.cssVue 3StorybookLiveDrag to pan, scroll to zoom, switch tabs, try the AI panel — a live partial prototype, interactive on desktop. Flip to the legacy tab to see the screen it replaced.
The widget dashboard, composed from the system
tokens.cssVue 3LiveThe full widget dashboard — gauges, compasses, charts, schedules and alarms, every one composed from shared components and tokens. Hover a card to see its motion; flip to the legacy tab for the dashboard it replaced.
The live map, rebuilt on the system
tokens.cssVue 3LivePan, zoom, and browse the sites and sensor list. A live partial prototype — interactive on desktop.
On mobile — the same system
tokens.cssReact NativeLiveThe React Native library consumes the same token layer as the web app — one system, two stacks, no drift.
Engineers
had something they could trust — components, not guesswork.
Testers
had a stable baseline to test against.
Leadership
saw UI change land immediately, release after release.
The outcome
Design stopped being a file. It became a system we ship.
What changed in practice
It worked not because it was perfect, but because it lived in real code. Every week, the gap between design and production got smaller.
In practice
IP-01
Reseller table-density complaints tapered off — at least one turned into a feature request rather than a bug.
IP-02
The team stopped asking “when will it be designed?” and started asking “is this component already built?”
IP-03
New feature work now builds on shared components by default, on web and mobile alike.
The shift
Before
Request → mockup → long build
After
Decision → component → shipped
The honest version
Figma ≠ change
A Figma system doesn’t create change on its own. Adoption needs trust, workflow integration and real implementation — the system isn’t the deliverable, the behavioural change is.
Consistency is a product feature
In industrial software, clarity beats decoration. A pattern repeated 100 times stops feeling monotonous and starts feeling safe.
Systems don’t ship themselves
The work wasn’t the tokens and components — it was Storybook, migration guides, code examples, and fixing the edge cases everyone avoided.
Influence is craft
I had to advocate repeatedly and prove value through small wins, not arguments.
Why it mattered
Two colours and a messy UI became a living system that changed how the product is built.
Every token, every component, every layout pattern — built to scale.
Next · 01
White-label theming
Dark mode + per-reseller brand tokens driven off the one source of truth — no forks.
Next · 02
Reseller-driven UX
The feedback loop now points at the component layer, so a fix ships everywhere at once.