Building our in-house UI Kit

When I joined Leeto in 2020, our small Product & Tech team relied on Ant Design, an external UI library, to build the SaaS product quickly. As the product grew, our needs for customisation and scalability outpaced the library’s flexibility. Over time, overlapping code and limited resources led to visual & functional inconsistencies, accessibility gaps, and longer QA cycles, affecting both user trust and team efficiency.

In 2023, I led a project to rebuild our foundations by creating our own UI Kit and in-house Design System, giving us full control over design and product decisions while supporting the transition to Leeto V3.

3× faster Design QA

70% of design debt resolved

Shipped 100% unit-tested components

0 new UI-related tickets

Positive internal & user feedback

Theme

B2B Fintech

SaaS

Team

4 Developers

2 Product Designers

Skills

Design System

Design Strategy

Product Design

Project Management

Timeline

2023-2024

Tools

Mission: keeping simplicity & intuitiveness

At my early days at Leeto, I realised that to modernise the CSE world, simplicity had to be my guiding principle. It became my mantra while shaping the product’s foundations, and the results soon showed: many users described the interface as simple and intuitive, two qualities that became core to Leeto’s experience.

As the product scaled, several pain points linked with the interface became clear across teams and users:

Dev team

✦

Used outdated libraries, causing bugs and maintenance pain

✦

Slow dev & QA cycles, lacking design focus

✦

Inconsistent components and overlapping code

Design team

✦

Built “Frankenstein” components mixing libs & custom code

✦

Frustration and limits in customisation

✦

Hard to ensure design–dev alignment

Users

✦

Inconsistent visuals & behaviors across the app

✦

Frequent tickets linked to broken components

With new hires joining both the design and development teams, and the Product & Tech org now split into B2B and B2C squads, the situation became clear: it was urgent to step in and fix the growing inconsistencies.

Our way of working and aligning internally could never come at the expense of the user experience, one that users already praised as simple and intuitive. We had to protect that standard and rebuild solid foundations to support it.

Making the case for prioritisation

We knew we wanted to change the way we worked and reduce inconsistency for everyone involved, but the question was: what strategy should we adopt?

As the Lead Designer, I knew I had to prepare this neatly and anticipate this question:

We knew we wanted to change the way we worked and reduce inconsistency for everyone involved, but the question was: what strategy should we adopt?

As the Lead Designer, I knew I had to prepare this neatly and anticipate this question:

We knew we wanted to change the way we worked and reduce inconsistency for everyone involved, but the question was: what strategy should we adopt?

As the Lead Designer, I knew I had to prepare this neatly and anticipate this question:

We knew we wanted to change the way we worked and reduce inconsistency for everyone involved, but the question was: what strategy should we adopt?

As the Lead Designer, I knew I had to prepare this neatly and anticipate this question:

Ok Christiane… but how could we integrate this cross-squad, non-prioritised project while still maintaining each squad’s roadmap and keeping up the overall delivery pace?

Step 1 - Aligning common strategy & design vision

From a Business & Marketing perspective, the direction was clear: Leeto was preparing its Version 3 of the product, backed by a stronger positioning and a full rebranding.

In parallel, we refined a unified Product vision across squads, and I took the lead in formalising the Design vision I had been shaping for Leeto, introducing guiding principles.

Bringing all these efforts together, I felt like it was the perfect moment to boost alignment, discipline, and quality, and what better way to do it than by taking a step toward a Design System, starting with a new UI Kit?

From a Business & Marketing perspective, the direction was clear: Leeto was preparing its Version 3 of the product, backed by a stronger positioning and a full rebranding.

In parallel, we refined a unified Product vision across squads, and I took the lead in formalising the Design vision I had been shaping for Leeto, introducing guiding principles.

From a Business & Marketing perspective, the direction was clear: Leeto was preparing its Version 3 of the product, backed by a stronger positioning and a full rebranding.

In parallel, we refined a unified Product vision across squads, and I took the lead in formalising the Design vision I had been shaping for Leeto, introducing guiding principles.

From a Business & Marketing perspective, the direction was clear: Leeto was preparing its Version 3 of the product, backed by a stronger positioning and a full rebranding.

In parallel, we refined a unified Product vision across squads, and I took the lead in formalising the Design vision I had been shaping for Leeto, introducing guiding principles.

Step 2 - Bringing the side project out

The next step to get everyone on board was to share what I had started alone as a side project: a library of UI foundations & components I had documented a little but few had seen.

Through internal “Walk in my shoes” workshops, I helped grow design culture and bridge collaboration with developers, turning design into a shared responsibility.

As summer brought a calmer pace, I proposed a Design x Front Dev Summer Camp, two 2-week sprints to co-build the first UI Kit elements and let me test them directly in a B2B project (Hello Business Accounts!).

The next step to get everyone on board was to share what I had started alone as a side project: a library of UI foundations & components I had documented a little but few had seen.

Through internal “Walk in my shoes” workshops, I helped grow design culture and bridge collaboration with developers, turning design into a shared responsibility.

The next step to get everyone on board was to share what I had started alone as a side project: a library of UI foundations & components I had documented a little but few had seen.

Through internal “Walk in my shoes” workshops, I helped grow design culture and bridge collaboration with developers, turning design into a shared responsibility.

The next step to get everyone on board was to share what I had started alone as a side project: a library of UI foundations & components I had documented a little but few had seen.

Through internal “Walk in my shoes” workshops, I helped grow design culture and bridge collaboration with developers, turning design into a shared responsibility.

Step 3 - Convincing Product & Tech management over time

The Summer Camp was a starting point, but the goal was to keep the UI Kit project alive over time, while each squad, designers and developers alike, continued to focus on their product and delivery goals.

To convince Product & Tech management to prioritise, sustain, and integrate the project in the long run, I emphasised the following points:

Capture the momentum

I wanted to highlight that if we didn’t act now, Leeto V3 could feel like déjà vu, without truly reflecting progress. That would be a shame, given the strategy aimed to showcase a fresh brand and product experience, effects that wouldn’t be visible anytime soon if we delayed.

Take the ownership

With a Product & Tech rapid pace routine already in place, I wanted to reassure the team about project management by taking naturally full ownership and leading the initiative end to end, making sure it wouldn’t interfere with ongoing product objectives. At the same time, I aimed to secure a small but steady share of development velocity in each sprint, so progress on the UI Kit could continue alongside product delivery.

Starting with a few objectives for the common interests

Divide Design review time by 2

Kill 80% of UI tickets and reduce design debt

0 new ticket linked with component usage

Building the Design–Dev process

With priorities aligned, it was time to bring designers and developers together, working on a close, hands-on process to co-build and refine the first components of our UI Kit.

Auditing, inspecting the code and mapping our existing system

Thanks to my hybrid design-dev background, I conducted a full audit of our UI foundations and components, cross-referenced with product issues and support feedback. Beyond visuals, I inspected the component code to uncover recurring structural and logic issues, using tools like Heurio to streamline feedback and bridge communication. This deep dive helped me identify what to fix, map and group components into families by usage.

Workshops to build shared understanding

I organised workshops to introduce Atomic Design to the Tech team and define how the UI Kit should live across design, dev, and public use. These sessions helped clarify ownership and collaboration, especially around cross-squad vs. squad-specific components, shaping a shared Design System culture.

Defining our creation flow

I set up a collaborative flow where designers and developers co-created each component, from design ideation and dev spikes to build, test, and replace. This approach kept creativity open early on and ensured consistency and quality at every stage.

Prioritising smart to move fast

There was no doubt that we had to change foundations first on the platform. Concerning the components and to make the UI Kit development more structured and predictable, I defined three prioritisation criteria:

✦

Logic

✦

Frequency of use

✦

Upcoming product impact

By crossing these dimensions, we could objectively decide which components to design or build first in each sprint, balancing effort, velocity, and value. This approach brought a shared decision-making framework between designers and developers, helping us stay aligned and focused on the most impactful components for upcoming releases.

UI Kit's organisation

Tab

Segment

Radio text

Checkbox text

40%

Document-1

PDF

23Ko

Success toast message.

Info toast message.

Warning toast message.

Error toast message.

Tab

Segment

Radio text

Checkbox text

40%

Document-1

PDF

23Ko

Success toast message.

Info toast message.

Warning toast message.

Error toast message.

Tag

Label

Input text

Label

Input text

Label

Input text

Error message.

150

Label

Select text

Label

Option 1

Option 4

Option 1

Option 2

Option 3

Option 4

Label

Select text

Error message.

Label

Input text

Label

Input text

Label

Input text

Error message.

150

Label

Select text

Label

Option 1

Option 4

Option 1

Option 2

Option 3

Option 4

Label

Select text

Error message.

Button

Tab

Segment

Radio text

Checkbox text

40%

Document-1

PDF

23Ko

Success toast message.

Info toast message.

Warning toast message.

Error toast message.

Tab

Segment

Radio text

Checkbox text

40%

Document-1

PDF

23Ko

Success toast message.

Info toast message.

Warning toast message.

Error toast message.

Applying design principles

Each new component was designed with our guiding principles in mind, from accessibility and contrast (WCAG-compliant colors) to clarity and usability. We refined both support elements (like detailed alerts) and key UI patterns (such as buttons) around a simplified color logic, balancing professionalism with a more human tone.

Anatomy & layout for a a shared design–dev language

Thanks to my front-end background, I could easily work with TailwindCSS, which became our shared framework between design and dev. To help developers better understand component structure, I documented the anatomy and layout foundations using a Figma specs plugin combined with Tailwind classes, making every detail explicit and transparent.

Variants for flexibility and precision

Using Figma’s component properties, variables, and Dev Mode features, we built clear and scalable component variants. This approach made it easier for both designers and developers to explore, test, and reuse components efficiently without losing control of details or consistency.

Structuring design & dev libraries for one shared system

Finally, we aligned Figma and Storybook through a common visual and logical organization, ensuring naming, hierarchy, and navigation matched across both environments. This structure covered not only components, but also families of components, strengthening our shared design–dev language and my role as a facilitator bridging both worlds.

Key impacts across teams and users

Impact on internal teams and ongoing projects

The implementation of the new UI Kit had an immediate impact on collaboration between Design, Tech, and Product teams. It improved visual consistency, accelerated delivery, and received highly positive feedback during early user tests on ongoing projects integrating the new components.

Design QA time reduced by 3×

New components and clearer guidelines significantly shortened design reviews and pre-release validation steps.

70% of design debt resolved

Legacy inconsistencies were progressively fixed as new standardised components replaced older ones.

0 new UI-related tickets

Since rollout, no bugs or regressions have been reported on elements built from the new system.

100% of components unit-tested

Every component was built with automated testing in mind, ensuring long-term stability and easier maintenance.

Positive feedback from early user tests

Initial test sessions on live projects highlighted a smoother, more cohesive experience, confirming the value of the new UI Kit for end users.

Learnings

✦

Pick your battles

I had been advocating for this topic for a long time, but finding the right moment and context finally allowed me to introduce it and get the team on board.

✦

Investing in the design–dev relationship pays off

Building a shared understanding with developers was key to ensuring consistency, smoother implementation, and a more collaborative process overall.

✦

From documentation to system thinking

Documenting the UI Kit while integrating the rebrand quickly turned into building the foundations of a full design system, requiring extra time and care.

✦

Design for evolution

A UI Kit, like any design system, is never static. It’s built to evolve, which makes having solid yet flexible foundations essential for long-term scalability.

Personal highlights

Bringing people together around ideas and growing a shared design culture.

Sharing language with developers thanks to my coding background to ensure smoother collaboration between design and tech.

Having a direct impact seeing both internal and user satisfaction on a project I led from start to finish.