Building Dexla’s Design System

UX research

UI design

2024

Overview

When I joined Dexla, things were moving fast. The company was scaling. New features were launching. Teams were growing. But the product? It was starting to feel messy. Buttons didn’t match. Colours changed from page to page. And everyone, from stakeholders to developers, had their own version of what “on brand” meant.

To be honest, the only consistent thing I found when I arrived... was the logo.

That’s when it became clear, we needed a design system. Not just a set of pretty components, but a structure that could bring clarity to the team and help the product scale without falling apart.

The Problems

Without a design system

The product felt inconsistent across features
We couldn’t move fast if every team had to re-invent the basics
Developers and designers weren’t speaking the same language
We wasted time fixing the same visual and UX issues in every sprint

And honestly? It made collaboration harder than it needed to be

The Challenges

What we exactly did we struggled with?

We were building a comprehensive system while the product was being built, with tight deadlines, a growing team, and no brand design foundation to start from. Some challenges we ran into:

No brand guidelines to reference

Ongoing feature work that pulled attention in multiple directions
Tight deadlines

We had to rethink the experience from the ground up, not just to make it easier, but to make it comprehensive for the team and scalable for the future

Research

Before designing anything, we studied existing design systems from Google, Atlassian, and Wise. I wasn’t just looking at their components; I wanted to understand their thinking, their structure, and what they might have done differently starting from zero.

Most systems don’t show you how they got there. That insight shaped how I approached Dexla’s

Defined a Clear Foundation

I introduced Atomic Design to help the team break down the UI into reusable pieces. We started by setting simple style rules: colour, spacing, typography, and iconography. This became our shared language.

Built the Component Library

From there, I designed the core building blocks: buttons, form fields, nav bars, cards, and modals. These weren’t just styles, they were flexible, with different sizes and states, so teams could actually use them across the product without needing to tweak or re-do them.

Supported the No-Code Editor

Dexla’s main product is a no-code app builder, so we also needed reusable UI components within the tool itself — for users, not just the internal team. I designed drag-and-drop elements that looked and felt consistent with our design language, while still being flexible for non-technical users to build their apps.

Documenting the Components

Each component was documented with clear usage guidelines, best practices, and examples to ensure easy adoption by the entire team. This will help designers and developers implement components without ambiguity.

The Result

The implementation of Dexla’s design system brought about transformative changes:

The team could now move faster, using shared, flexible components
Developers didn’t need to ask for specs or rebuild from scratch
Designers had a clear system to plug into — no more guessing
The product started to feel like one thing again, not five different versions

“The design system made implementation much faster and reduced back-and-forth discussions. Having clear guidelines and pre-built components meant fewer bugs and better alignment with the designs.”

Williams Balogun

Development Team

“It was a real pleasure to work with the new design system, the components were very intuitive and documented well that designing new features was seamless. Indeed it did bring structure to our workflow”

Ayowande Olubo

Product Team

Key Takeaways

This project taught me how to design for scale — not just for users, but for teams. I learned:

How to work from zero — no Figma file, no design system, no guide
How to bring designers together and keep things simple
How to balance structure with flexibility, so the system grows with the team
And how good documentation can save you hours of back-and-forth later