Scaling Liquidise from design debt to a modular system
Design Ops
Systems Architecture
React MUI Alignment
Process Optimization
Scalability
Company
Liquidise
Industry
Fintech B2B
I joined as the first designer when Liquidise was Boulevard Global, a digital share registry. I built the design infrastructure that served as the technical foundation for the product, ensuring the UI remained resilient and consistent as the engineering team and feature set expanded.
The product was built on unmanaged design debt: a disorganised UI kit with no central library that forced a "copy-paste" workflow. This lack of operational logic doubled the time required to ship features, as every release was stalled by manual hand-audits and hours of repetitive spec meetings to clarify basic UI logic.
I implemented a 3-tier token system and a modular React-aligned library that cut prototyping cycles from weeks to days. This system empowered the engineering team to build consistent screens autonomously, allowing the business to scale production significantly without increasing design overhead or UI fragmentation.
1 Lead Engineer
2 Engineers
1 Product Designer (me)
Design System
Token Strategy
Technical Handoff
Documentation
Initiated September 2022
Completed Phases 1 and 2 completed in a month.
Context
In early 2022, Boulevard Global (now Liquidise) was still a digital share registry focused on scaling and shipping features at high speed. As the first design hire, I inherited a single, overloaded Figma file with hundreds of pages and only one disorganized page acting as a "UI kit". Without a central library, every new feature was a manual copy-paste of the last. Without design oversight, the files were a mess of design debt that slowed down shipping and made consistency impossible as the product grew.
The "One-Off" Trap
The codebase was built on a component-based approach that lacked a shared design foundation, forcing engineers to create isolated "one-off" implementations for every update
The Scalability Wall
As the team grew, the lack of a "source of truth" made coordination impossible and turned a manual workflow into a massive growth blocker.
Handoff Friction
Every screen required manual annotation and hours in meetings explaining basic specs like spacing and padding because the engineers couldn't trust the static files.
Wasted Time
Without systemic logic or documentation, features that should have taken one sprint took two, making design a constant bottleneck for every release.
This setup couldn't keep pace with our growth. As the team and product grew, this manual way of working was holding us back.
In September 2022, I started building a professional design operation. I decided to move the team to a a modular system designed to align with the existing React MUI codebase. The goal was to eliminate handoff friction and build a technical foundation resilient enough to handle any future product direction.
strategy
I couldn't stop product work to build a system from scratch, so I created a 4-phase roadmap to improve our workflow in stages while continuing to ship new features.
Phase 1
I moved all styles and components into a single, published Figma library and wrote the first set of standards in Confluence for the team’s reference.
Phase 2
I rebuilt components with auto-layout and established a 3-tier Token system in Figma to align our design names with engineering logic.
Phase 3
I mapped the bridge to connect tokens to the codebase and work with engineers to ensure all production components followed the system.
Phase 4
I planned the use of ESLint rules to prevent hard-coded values and the integration of Storybook to keep design and code in sync.
Phase 1
The primary goal was to eliminate manual overhead. I transformed a disorganized set of static files into a functional, shared resource for the entire team.
Auditing the Mess
I scanned our production designs to document every variation of our core elements. This audit confirmed the source of our inconsistency: without a shared library, the team was forced to guess on styles for every new feature.
Implementing a Modular Hierarchy
I centralised every style and component into a single Primary Library. To ensure the system was scalable, I adopted a clear hierarchy to ensure the system was scalable:
Foundations: I defined basic building blocks - colours, typography, and spacing, standardising them to replace inconsistent hex codes.
Components: I consolidated redundant versions of buttons and inputs into master components. These were then used to build complex patterns like cards and modals.
Information Architecture: I structured the library for high discoverability, allowing any team member to find components independently.
Driving Team Adoption:
A system only works if it's used. As the sole designer, I held weekly walkthroughs with the engineering team to align and gather feedback. This ensured that all 5 engineers felt comfortable using the library independently, which eliminated the need for me to manually audit every screen before launch.
Documentation (Confluence)
A library only works if everyone uses it the same way. I wrote a Design Documentation in Confluence that set clear rules for using components and spacing. This gave the team a single place to find answers, which stopped unnecessary meetings and kept engineers from having to guess how a design should work.
In Confluence, I documented a standardised 4px spacing scale. This gave engineers a clear rulebook for layouts, preventing on-the-fly bespoke variations and allowing them to build consistent screens without constant design oversight.
Phase 2
Once the mess was cleared, I had to make sure the new components were technically sound. I focused on making the Figma files smart enough to match how the engineers actually build.
Engineering-Led Component Logic
Original components were static and required manual adjustment. I rebuilt the library using Figma Auto-layout to mirror CSS behaviour:
Inheritance: By standardising foundations first, any global update now ripples through the entire component ecosystem automatically.
Responsive Behaviour: Components were built to be content-aware (e.g., buttons expanding with text) and layout-aware (e.g., modals adapting to content length).
Laying the Token System in Figma
To prepare for a future sync with the React MUI codebase, I replaced hard-coded values with a 3-tier Token structure in Figma:
Primitive Tokens: Raw values (e.g.,
Blue-500,Space-16).Semantic Tokens: Purpose-driven names (e.g.,
Brand-Primary,Surface-Background).Component Tokens: Element-specific values (e.g.,
Button-CTA-Background).
By building this in Figma, I created a shared vocabulary with the developers. I made sure my naming system matched the logic they used in their code, which removed the guesswork during handoff. This created a clear blueprint, making it easy to eventually move these values into the codebase in Phase 3.
Impact
By the time the first two phases were complete, the way we built products at Liquidise had completely changed. The shift from a manual workflow to a managed system allowed the team to scale without losing speed.
50% Faster Shipping: I cut high-fidelity prototyping time in half. By using the modular library, I reduced the turnaround for complex feature designs from an average of 10 days down to 5 days. This allowed me to deliver work to engineering an entire sprint ahead of the previous schedule.
Built for Scale: I started this system when we had 2 engineers. As the team grew to 5, the system ensured we could more than double our headcount without slowing down our output or increasing design debt.
Engineering Autonomy: By creating a shared naming system in Figma that matched the code logic, I eliminated constant back-and-forth meetings. Engineers could finally build consistent screens without my direct supervision.
Professional Foundation: I moved the company from a "copy-paste" culture on a free Figma plan to a professional design operation. This created a permanent source of truth that will support every future hire.
Impact
While the first two phases fixed our design side, I mapped out the technical steps to connect our Figma library to the live product.
Phase 3: Connecting to Code
I led the handoff by showing the Lead Engineer how to bridge the gap between our design logic and their code.
I showed the Lead Engineer how we can export our naming rules from Figma as a single JSON file to stop engineers from having to type in colours or spacing manually.
This file plugs directly into the code so that a colour change in Figma updates the entire app automatically, removing the "translation" step during handoff.
We placed this on the roadmap but paused the final implementation to prioritise the company’s transition from a share Registry to a secondary trading marketplace.
Phase 4: Staying in Sync
The final step is to make sure the system stays clean as the team grows and more people contribute to the codebase.
We will set up code checks (ESLint) to flag errors if an engineer uses a random colour instead of a system name, ensuring the library stays clean as the team grows.
We will use Storybook as a shared place to view every live component, making sure the coded version always matches the Figma version 1:1.