Wildeye Design System
I was the first designer in the building. Three years later, UI that took months to ship takes about a week — across web and 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.
Two products, one customer — zero shared language
A .NET web UI running inside iframes, circa 2008
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.
One-off features
Every feature was built from scratch, in its own way.
Ad-hoc UI calls
Every engineer made their own visual decisions.
Compounding drift
Every new screen pushed the product further apart.
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 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.
Brand → tokens
Brand
Anchor 01
Wildeye Blue
GlobalBlue-900#00AEEFAnchor 02
Wildeye Green
GlobalGreen-700#0DB14BThe whole starting palette: one logo, the two anchors it yields, and the 100–1300 ramp each anchor opens into.
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.
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
Figma wasn’t their tool
Engineers weren’t comfortable working from design files — specs became suggestions.
Spacing drift, every time
Paddings and gaps changed in translation, screen after screen.
Responsive states improvised
Breakpoints and edge states were missed or invented on the spot.
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
So I stopped shipping files and started shipping code. Storybook became the system's home.
With AI assistance I built, tested and shipped every component myself — web and mobile. If it broke in production, it was mine to fix. Owning that loop end-to-end was the 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 (early days)
The real Storybook, early in its life: 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.
The component library, live
viteuitokens.cssInter 475LiveWhere that Storybook ended up. Every specimen is the real component, ported 1:1 from the Vue library — the same buttons, fields, chips and badges that compose the product page on the last tab. States are on a clock so they play without a cursor; hover anything to take it off the script.
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. All three phones are running live in this page: the dashboard scrolls its chart cards behind a glass tab bar, the login types itself in, and settings pushes into a profile form.
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
Reseller table-density complaints tapered off — at least one turned into a feature request rather than a bug.
The team stopped asking “when will it be designed?” and started asking “is this component already built?”
New feature work now builds on shared components by default, on web and mobile alike.
The shift
Request → mockup → long build
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.