Building Liquidise's First Design System
Information Architecture
Systems Architecture
React MUI Alignment
Process Optimization
Scalability
COMPANY
Liquidise
INDUSTRY
Fintech B2B
TIMELINE
Oct 2022 onwards
ABOUT
Liquidise, then Boulevard Global, is a regulated share registry serving 170+ companies and their shareholders. I joined in October 2022 as the first designer and inherited a UI kit that had been used for months without an owner, on a free Figma plan, with no shared library. I rebuilt it in stages, alone, while shipping product.
CHALLENGE
No published library, a copy-paste workflow, and components too static to adapt to content. A component-by-component audit later found 51 separate button components, 42 separate input components, and four different modal implementations spread across 23 layers, none of them sharing a header, footer, or content box. Every release needed manual annotation, and every launch needed me to check the whole thing myself.
TEAM
Lead Engineer, Engineering team (2 growing to 5), Product Designer (me)
IMPACT
High-fidelity prototyping for complex features went from roughly 10 days to 5. The engineering team grew from 2 to 5 without added design debt. I replaced zero enforced tokens with 68, across three governed tiers, and engineers could build consistent screens without my oversight.
Preface
I inherited a UI kit that had been running for months without an owner
The product shipped. The design behind it never did, so I became the lookup table.
Boulevard Global had been building for months without a designer before I joined in October 2022. By then the registry already held records for 170+ companies and roughly $800M in shares, so the stakes were real from day one. The UI kit that survived that period was not a system, it was a set of files that had drifted.
No source of truth. On a free Figma plan there was no published library, which forced a copy-paste workflow and made versioning impossible.
Broken components, counted properly. When I later audited it component by component instead of by feel, the numbers were worse than I expected: 51 separate button components, 42 separate input components, and four different modal implementations across 23 layers.
Unreliable styles. One swatch in the brand palette turned out to belong to Apple's iOS UI Kit, not Boulevard, evidence the file had been assembled from whatever library happened to be open at the time.
Handoff friction. Every screen needed manual annotation and hours of meetings explaining spacing and padding, because engineers could not trust the static files.
Wasted time. Features that should have taken one sprint took two, and with no documentation I audited every screen before launch myself.
That last point is the one that mattered. I was the only designer and the only checkpoint for every release, and the company was about to move from a static share registry to a regulated trading marketplace with more engineers joining.
The file I inherited. Styles, components and finished screens in one place with no structure, nothing published, and no way to tell which version was current.
Approach
Four stages, because nobody was going to pause the roadmap
Nobody was going to pause the roadmap so I could fix the file. So I didn't ask them to.
Each stage had to deliver something usable on its own, because this was never a dedicated project, it was work I fit around shipping features the whole time. The later stages needed hours nothing else was competing for, and they didn't always get them, so the earlier ones had to stand on their own.
Cleanup came before tokens on purpose, not by default. The textbook order is tokens first, then components built against them. I had zero organisational buy-in and an active mess nobody had agreed was worth fixing yet. Consolidating the visible chaos first, the 51 buttons, the four modals, bought credibility fast. The invisible infrastructure became fundable once people could see I was solving a real problem, not building something for its own sake.
First, the cleanup. Every style and component into a single published library, with the first written standards for the team.
Second, the foundation. Components rebuilt with auto layout, and a three-tier token system aligning design names with engineering logic.
Third, connecting to code. A mapped bridge from Figma tokens to the codebase, worked through with the Lead Engineer.
Fourth, staying in sync. ESLint rules against hardcoded values, and Storybook so the coded components match Figma one to one.
The first two shipped. The third and fourth were mapped and agreed, but never got the dedicated hours, because shipping features and fixing what was already broken in production always came first. More on that later.
The Cleanup
Making it findable before making it clever
A library only works if people can find things in it without asking me.
Auditing the mess
I scanned the production designs and documented every variation of our core elements, component by component instead of by feel. The audit confirmed the cause rather than the symptom: with no shared library, the team was guessing at styles on every new feature. 51 button variants. 42 input variants. Four separate modal implementations.
Follow one component: the modal
There was no single modal, there were four: Desktop/Modal, Desktop/Modal2, Modal/Large, and Modal/Small, plus loose header and footer instances that were not even children of those. 23 modal-related layers in total in the design file, for what should have been one component with a size variant. It was the clearest single example because it was small enough to lay out in full: different padding, different header treatment, different button placement, none of the four sharing a base.
But the modal wasn't the whole story, it was the sharpest cut into a pattern that showed up everywhere. Buttons and inputs had the same disease at a larger scale, just less dramatic to screenshot. Laying all of it out, not just the modal, is what got the cleanup funded.
The audit. Different modal treatments from the same product: different padding, different header styles, different button placement.
A modular hierarchy
Everything went into one primary library, structured in three levels so it could scale rather than just be tidy.
Foundations. Colour, typography, and spacing defined as basic building blocks, replacing inconsistent hex codes with named values.
Components. The 51 buttons and 42 inputs consolidated into master components, which then assembled into complex patterns like cards and modals.
Information architecture. The library organised for discoverability, so any team member could find what they needed independently.
A separate file for the source, a separate file for the work
The design system lived in its own file, published as a Figma library. Product screens lived in a separate app-design file that only ever consumed the library, it never edited it directly. That split meant a change to a button only ever happened in one place, and every screen using it picked up the update instead of drifting further from whatever the "real" version was supposed to be. I was the only one publishing to the library. Every accepted update went through me.
[ IMAGE: the published Figma library, Foundations and Components pages, organised structure ]
Documentation, so the rulebook was not a person
It started as blue annotation layers directly in the Figma file, redlines showing engineers the exact spacing, sitting right next to the component they described so nobody had to go looking for the rule. Once the spacing scale settled, I moved it into a Confluence page engineers could search without opening Figma at all.
The spacing scale went in there too, 8 to 120 pixels across ten steps. A documented scale is what lets an engineer lay out a screen they have never seen before without asking anyone, and it is what prevents the on-the-fly bespoke variations that created the mess in the first place.
The Confluence documentation. Foundations, components and design patterns, with the rules written down so the rulebook was not a person.
Adoption
A system nobody uses is documentation. I ran weekly walkthroughs with the engineering team to align on what had changed and gather feedback, until all five engineers were using the library independently.
That is what ended the manual pre-launch audits. I had been checking every screen myself because there was no other way to catch inconsistency. Once engineers were building from the library, the checking was built into the process instead of into me.
The Foundation
Making Figma behave the way the code does
Tidy wasn't the bar. The components had to behave the way the code already did.
Auto layout as CSS
The original components were static frames. Any change in content meant manual adjustment, which is why bespoke variations kept appearing. I rebuilt the library on Figma auto layout so components mirrored CSS behaviour rather than approximating it.
Inheritance. With foundations standardised first, a global change now ripples through the entire component ecosystem automatically.
Content-aware. Buttons expand with their label instead of breaking or needing a duplicate.
Layout-aware. Modals adapt to content length instead of requiring a second Modal2 for a longer message.
[ VIDEO: the same button expanding to fit a short and a long label, one component, no duplicate ]
A shared vocabulary, not a designer's one
Hard-coded values were replaced with a three-tier token structure, 68 tokens in total.
Primitive. Raw values with no meaning attached. 15 colour primitives across a mint scale, secondary blue and fog, five neutrals, and five alert colours. 10 spacing steps from 8px to 120px. A typeface primitive, three font weights, and 10 font sizes.
Semantic. Purpose-driven names aliased only to the primitive tier below them: brand.primary, surface.background, text.default, feedback.error, three spacing intents, and 11 composite typography roles.
Component. Element-specific values: button.cta.background, button.cta.background-hover, modal.header.background, input.border.default, button.label.
[ IMAGE: the three-tier token panel in Figma, primitive, semantic, and component, with real names and resolved values visible ]
The tokens became the shared language. When a designer specified space.16 in Figma, an engineer could implement it with certainty, no more threads asking whether something was 16px or 14px. I made the naming match the logic developers already used in React MUI, variant, size, palette, which removed the guesswork at handoff and made the eventual bridge to code a mapping exercise rather than a rewrite.
brand.primary resolves to a raw color.mint.400 primitive rather than being its own hardcoded hex, specifically so a brand refresh is a one-line change at the primitive tier instead of a find-and-replace across every component using that colour.
Versioning came from the plan, not a workaround
The Professional plan gave every published update version history and a required description, so accepting a library update meant reading what changed and why before it touched a live product file. I did not have to build a changelog process from scratch, I had to be disciplined about writing a real description every time I published, instead of leaving it blank.
What stayed unfinished: accessibility
Accessibility was on the roadmap, and I never got the dedicated time for it. It stayed weak, and I knew it stayed weak. Colour contrast wasn't audited against WCAG, focus states weren't a governed token, and neither got the overhaul pass it needed before I moved on to the trading marketplace work.
An ideal system treats accessibility as its own token category from day one, contrast pairs, focus rings, reduced-motion values, not a pass you run afterward. This one didn't get that, and the gap is real: nothing in the 68 tokens enforces a contrast ratio, and no component carries a governed focus state. That's the honest distance between what shipped and what a mature system looks like, and I'm naming it here instead of leaving it out.
Impact
What changed once the first two stages landed
The workflow changed before the system was finished, which was the point of phasing it.
Prototyping time halved. Complex feature designs went from an average of 10 days to 5, which put work in front of engineering a sprint earlier than before.
Built for scale. I started this with two engineers. The team reached five without slowing output or adding design debt.
From 0 to 68. Zero enforced tokens became 68 across three tiers. 51 bespoke button components became one, with variant props. 42 bespoke input components became one. Four modal implementations across 23 layers became one.
Engineering autonomy. A shared naming system in Figma that matched the code logic ended the constant back-and-forth. Engineers built consistent screens without my supervision.
A professional foundation. The company moved from copy-paste on a free plan to a published source of truth that outlived my time there, through a full company rebrand and a settlement-layer migration with zero interface changes.
[ IMAGE: before and after, one real screen built from the old bespoke components next to the same screen rebuilt from the governed library ]
The Roadmap Ahead
I mapped the bridge to code, then chose the trading platform
The bridge to code was mapped and agreed. It never got built, because the design system was always the work that happened between features, not instead of them.
I showed the Lead Engineer how we could export our naming rules from Figma as a single JSON file, so engineers would stop typing in colours or spacing manually. This file would plug directly into the code so a colour change in Figma updates the app automatically, removing the translation step at handoff. Staying in sync would have added code checks through ESLint to flag a hardcoded value instead of a system name, and Storybook as a shared place to confirm the coded version matched Figma one to one.
How it would have worked
The plan was simple on purpose. Export the token JSON straight out of Figma, run it through a build step that turns it into a theme file shaped like the one React MUI already expects, so palette and spacing values land exactly where the app already looks for them. Check that generated file into the repo instead of hand typed values. Wire an ESLint rule to fail a pull request that used a raw hex or pixel value instead of a token. Add a Storybook entry per component so a reviewer could put the coded version next to the Figma version and see them match, or not, before merge. None of it was novel. It just needed a designer with the hours to pair on it, and those hours went to the trading marketplace instead.
[ IMAGE: the mapped JSON export structure, a sketch or whiteboard photo of the planned Figma-to-code bridge ]
Fixing what was broken in production and driving adoption were already running in the background the entire time, threaded through whatever feature I was shipping that week. The token bridge and its enforcement layer needed dedicated hours instead, a block of time nothing else was competing for, and I never got to carve that out. There was no second designer to hand it to, and building automated enforcement for a system that was already working, by hand, well enough, kept losing to whatever feature was next.
What it cost: the handoff still had a manual step in it when I left. The vocabulary matched, so the gap was small, but it was not closed. There is no lint-compliance percentage I can quote here, because that tooling never shipped. Saying a design system is finished is usually a sign nobody had to make that trade, or that there were enough people to avoid making it.
Collaboration
A naming decision, not a meeting
The clearest moment of influence wasn't a meeting, it was a naming decision.
Early on I chose token names, variant, size, state, that mirrored MUI's own prop vocabulary rather than a Figma-native taxonomy. The Lead Engineer picked up on it immediately. A design review stopped being "translate this into code" and became "confirm this matches what you'd already write."
Working the bridge together
When I mapped what the JSON export from Figma to code would look like, I worked it through with the Lead Engineer directly rather than handing over a spec afterward. He told me where the token names would actually land in the theme file, I adjusted the naming before any of it got built, and that's why the plan for staying in sync never needed a translation layer, even though it never shipped.
That's the part I'd point to if someone asked what working with engineering actually meant here. It wasn't a scheduled sync, it was choosing words early enough that the sync never had to happen.
Reflection
What I learned
Systems are about people, not pixels. Selling it to engineers and writing it down mattered as much as building it.
Stage it, or it never happens
I was the only designer, and nobody was going to pause the roadmap so I could build infrastructure. Four stages meant each one delivered something usable on its own, so when the third and fourth lost to a product launch, the first two still stood.
A label without a source behind it is not a token
While rebuilding, I found a swatch in the brand palette that traced back to an unrelated iOS icon library, not Boulevard. It looked like governance from a distance. It wasn't, because nothing tied the colour to a single source of truth, so the file had quietly been assembled from whatever library happened to be open at the time. 68 real tokens later, that kind of drift is structurally harder to reintroduce, not just discouraged.
Adoption is the work, not the artefact
Weekly walkthroughs with five engineers did more for adoption than the library itself. A system nobody opens is documentation.
What I would do differently: I never measured it
I can tell you what the system survived: a rebrand, a team that more than doubled from 2 to 5, a settlement-layer swap with zero interface changes. I can tell you the raw scale of the mess I inherited: 51 bespoke buttons, 42 bespoke inputs, 4 modal implementations across 23 layers. What I cannot tell you is how much faster anything got for the engineering side, because I only ever measured my own prototyping time. Baseline timings before the cleanup would have cost an afternoon and would have made every claim since defensible, not just the one I happened to be measuring myself.
[ IMAGE: closing shot, the final published library today, Foundations, Components, and Design Patterns side by side ]