Building Tilli's Design System from the Ground Up
[1]
During my time at the fintech start-up, I discovered mid-project that the company had no shared visual language.
So I built oneβ¦ from scratch, alongside a 0β1 product build, with no prior foundation to work from.
Role
Sole UX Designer
Industry
B2B, Fintech, SaaS
Tools
Figma, Cursor, Vercel, Github, Linear, FigJam, Webflow.
Context
[2]
Laying the groundwork to scale.
When I joined TilliX, Tilli was already operating as a growing product with multiple live workflows, but there was no design system to support that scale.
Inconsistent components, no shared tokens, no docs. Engineers were filling design gaps themselves just to keep moving.

"I couldn't build a zero-to-one product cleanly on top of inconsistency. And neither could anyone who came after me."
Research
[3]
Understanding how teams use component docs.

Since they were the ones actually building these components, I sat down with engineers to understand what was actually painful in their day-to-day.

Measurable Design Features
[4]
I made sure to align the design features with our product team needs, creating goals to ensure my solution addressed the prior pain points successfully.

Visual inconsistency
Improve the existing pages with clearer copy and updated visuals.
No source of truth
Rebuild the site around a single, clear narrative with reusable sections.
Compounding debt
Every new product made it worse.
Offshore risk
No shared standards meant misalignment would happen fast.
Structuring The System
[5]
As Tilli expanded its product suite, I focused on creating the building blocks to support that growth - a scalable system of visual foundations and reusable components.
Structure analysis

By the time I moved into designing the TilliX dashboard, I was assembling from a system, not designing from scratch.
A system for everyone
[6]

Our product users were finance and ops teams handling high-volume payments under pressure.
I prioritized clarity: larger, more legible components to reduce risk in critical moments.
I ran weekly design system reviews with engineers and stakeholders: sharing decisions, gathering feedback, and iterating so the system stayed grounded in what could actually be built.

The Finalized Design
[7]
The result of this work led to a complete overhaul of Tilliβs component documentation moving forward. I presented these updates to the broader team to gather feedback and align on how the system would scale across products.

01 β Dark Mode
Both modes, one system.
π βΆ π βΆ π βΆ π
Color tokens were built to support both light and dark mode from day one. Switching modes required no component rework just swapping the token values.

02 β Scalable Components
One brand reflected on every surface.
The system was built to outlast TilliX. Tokens, type scale, and components are structured so any future Tilli product can inherit the foundation without starting over.

Components were composable building blocks & engineers source of truth. QuickPay and the post-login dashboard are entirely different experiences - assembled from the same parts.
03 β Accessibility
Every interactive state designed and documented.
The system was built to outlast TilliX. Tokens, type scale, and components are structured so any future Tilli product can inherit the foundation without starting over.
04 β Seamless Integration
One update propagates across every file.
When a component in the library gets updated, every instance across every file updates with it. Engineers did not have to hunt down stale components, the system stays in sync automatically.

Crafting the Visual Experience
[8]
Once the system was established, I used it to continue building out TilliX β applying the same components and patterns across new features and flows.
Click here to see my work.
Footer
[9]

