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]

V4.2.0

Made with whatever my mom cooks and oikos yogurt.

Status

Finishing off my hoard of books

V4.2.0

Made with whatever my mom cooks and oikos yogurt.