From Drift to Foundation

CONTEXT

Project Context

It started with a button. Not a broken one — a button that worked fine. The problem was, there were seventeen of them. Seventeen buttons across the product that did roughly the same thing, built at different times, by different people, with slightly different radii, weights, and hover states.

Nobody had set out to create seventeen buttons. Each one made sense when it was built. But standing back and looking at all of them together, the shape of a deeper problem became visible: the product had outgrown the decisions that were supposed to hold it together.

This was a B2B travel platform used by companies across Europe — flights, hotels, rail, car rentals, internal tooling — all evolving in parallel. The UI was growing faster than any shared rules could keep up with. Every sprint added another local solution, another quiet variation nobody would notice until the next person built on top of it.

ROLE

My Role

I was the sole designer responsible for this work from beginning to end — component audit, system architecture, governance documentation, and direct collaboration with engineering on implementation.

There was no dedicated design systems team and no pre-existing mandate. A significant part of the role was making the case internally: demonstrating through the audit that the inconsistency was not cosmetic but structural, with real costs for delivery speed and engineering rework.

THE PROBLEM

From Visual Problem to Structural One

At first glance, the issues looked mostly visual: inconsistent spacing, slightly different button styles, repeated components that didn't quite match. Clean up the UI, standardise the components, move on.

But as the audit progressed, the scale became clear. The component library had grown into a graveyard of almost-the-same things — patterns solved multiple times over, with no shared record of why one approach was chosen over another.

Everything lived in a single, large design file. It had become slow to open, prone to version conflicts, and impossible to tell which components were stable, which were experimental, and which had simply been left behind.

The problem wasn't that people were designing badly. It was that there was no shared language to design within.

INVESTIGATION

The Audit

I ran a practical audit across key flows and the existing component library — not to build a perfect inventory, but to find where the same user need was being solved differently.

I mapped duplicated UI decisions across search, results, booking, and forms: filter chips, sort controls, empty states, inline validation. This made the problem visible in a way that was hard to argue with.

INVESTIGATION

Five-Point Audit Framework

To structure the findings and communicate them meaningfully, I evaluated the existing system against five dimensions — each chosen because it reflected a real cost the product was already paying.

This framework reframed the conversation from 'our UI looks inconsistent' to 'our current system structure is creating measurable overhead — here is the evidence.'

KEY INSIGHTS

What the Audit Revealed

Most inconsistencies weren't intentional design choices. They were local solutions created under time pressure. Nobody set out to fragment the system — it accumulated quietly, one sprint at a time.

What made it costly was compounding. The filter chip existed in four variations. Two used icon-left, two used text-only. The behaviours diverged — one reset filters on tap, another supported multi-select. This forced different sort control positioning, which affected empty state layouts. One undocumented decision had created three downstream inconsistencies.

DESIGN STRATEGY

Design Strategy

Rather than redesigning individual screens, the effort needed to move upstream — toward a shared foundation that could survive growth.

The strategy had four parts: identify the core building blocks used everywhere; define interaction patterns, not just visual styles; reduce the number of valid variations; and align design decisions with how engineering would actually implement and reuse them.

Less pixel perfection. More decision clarity.

A key part was introducing design tokens — named, reusable values representing visual decisions. Instead of a button storing a hard-coded hex value, it referenced a semantic token like 'interactive-primary' that could be defined once and propagated everywhere.

SYSTEM DESIGN

System Architecture

I structured the system in four tiers, each with a clear purpose:

Foundations — design tokens, colour scales, spacing, typography, elevation. The raw decisions everything depends on. Components — buttons, inputs, dropdowns, filter chips, modals — each referencing foundation tokens, not hard-coded values. Documentation — usage guidance, interaction specs, accessibility requirements, and decision rationale. System Hub — living documentation bringing together component status, usage guidance, and contribution guidelines.

This separated the concerns previously collapsed into a single file — making the system easier to maintain, navigate, and extend.

SYSTEM DESIGN

Maturity Tracking

To measure progress beyond component counts, I tracked the system's maturity across nine dimensions grouped into three categories: Foundation (tokens, components, documentation), Growth (interoperability, innovation, quality assurance), and ROI (governance, adoption, culture).

This gave stakeholders a clear before-and-after picture and made the investment case concrete — not just 'things look better' but 'here is how the system has matured across the dimensions that matter.'

SYSTEM DESIGN

Governance

The hardest problem isn't building the system — it's preventing it from fragmenting again.

I introduced a lightweight governance process: a clear, low-friction path for proposing changes. Each proposal was evaluated against the five audit dimensions. Component status conventions distinguished stable, in-review, experimental, and deprecated — so teams could tell at a glance what was safe to build with.

"The best governance is invisible. It works because the right choice was always easier than the wrong one."

COLLABORATION

Collaboration & Rollout

A design system that lives only in Figma isn't a system — it's a reference document that will fall out of date. I worked closely with engineering throughout, not just at handoff.

The system was introduced gradually, letting active features pull it into use. It supported the release of dashboards, user administration, invoicing, and reporting — each module stress-testing the architecture.

When an engineer could reach for an existing pattern instead of building from scratch, the system gained credibility. When a feature shipped faster because the design decisions had already been made, the investment began to pay back.

OUTCOMES

Outcome

The outcome wasn't a single redesign. It was a shared language for how the product should look, behave, and grow.

Duplicated components consolidated into flexible building blocks. Interaction patterns defined so users encounter predictable behaviour across flows. The design file reorganised from a single monolithic file into a tiered system where each layer has a clear home.

"The UI shifted from being whatever the last sprint produced to feeling like a coherent product language."

REFLECTION

Reflection

The most useful shift was recognising that inconsistency is rarely the root problem — it's a symptom of missing structure and undocumented decisions.

Doing this as a solo designer reinforced something about advocacy: the audit framework wasn't just a research method — it was a communication tool. Framing the problem in terms of business alignment and delivery cost made it possible to have a different kind of conversation about the value of the work.