From Chaos to Cohesion: Building Visibuild's Design System

The Outcome

A design system with 280+ design tokens, 100+ components, and automated enforcement that reduced bespoke implementations by 30 to 50% and enabled a team that scaled from 3 designers and 6 developers to 4 designers, 2 PMs, and 13 developers.

The Problem

When I joined Visibuild, the frontend was the wild west.

Every component was bespoke. Buttons came in countless variations, not through intentional design, but through accumulated decisions made on the fly. Inputs, modals, spacing were all inconsistent. The codebase was a graveyard of one-off implementations that each developer had built in isolation.

The cost was velocity. Features that should have taken one sprint took two. Every new screen meant rebuilding primitives from scratch. And as the team prepared to scale, this approach simply would not hold.

This was not a customer-facing crisis. Users were not complaining. It was an internal crisis of coherence. The product looked like it had been built by dozens of different teams, because functionally, it had been.

The Audit

I began with a systematic inventory using the Design System Guide's audit template. Over the course of a month, squeezed between other business priorities, I documented every inconsistency.

The process:

• Built a Notion database cataloguing every component variant in production
• Screenshotted styling inconsistencies directly in Figma for visual evidence
• Mapped the full landscape of buttons, inputs, modals, and typography treatments

What I found was sobering:

• 23 distinct button styles that were essentially the same button with slight variations
• Modal implementations that ranged from polished to broken, with no shared patterns
• Colour values hardcoded throughout with no source of truth
• Spacing applied by gut feel, pixel by pixel

The audit gave us our baseline. More importantly, it gave the team a shared understanding of the problem. When you can see the chaos laid out visually, the need for systematisation becomes self-evident.

Education Before Implementation

Before writing a single token, I focused on building shared understanding.

I ran workshops with designers and developers to gauge their familiarity with design systems. Many had heard the term but had never worked within one. Some designers worried it would constrain their creativity.

My philosophy, which I communicated clearly: a good design system supports designers, it does not dictate to them. The goal was not to eliminate creative decisions. It was to eliminate unnecessary decisions and free up cognitive load for the problems that actually matter.

This framing was critical. By positioning the system as a tool for empowerment rather than control, I avoided the resistance that often derails these initiatives.

Building the Foundation: Tokens First

We started simple: colours, typography, and spacing.

These foundational tokens were built in Figma using Token Studio, creating a single source of truth that could be exported to JSON, JavaScript, and SCSS. Within two months of starting, we had our first tokens shipping.

The token architecture:

The tokens became the shared language. When a designer specified space-8 in Figma, a developer could implement it with certainty. No more "is this 8px or 10px?" conversations.

Enforcement Through Tooling

Tokens only work if people use them. We partnered with the development team to implement Stylelint rules that enforced token usage:

This was not punitive. It was educational. Every linting error became a learning moment. Developers began internalising the system not because they were told to, but because the tooling made the right choice the easy choice.

Components: Collaboration Over Handoff

By month four, we shipped our first standardised Button component with 11 variants covering every legitimate use case we had identified in the audit.

As tools like Cursor emerged, I found myself increasingly working directly in code. What started as "critiquing pixel-perfect implementation" evolved into making those changes myself. The line between design and development blurred productively.

The contribution model:

• Individual product streams could propose components that would benefit the system
• I reviewed each proposal against clear criteria: Is this a snowflake (one-off need) or does it have genuine reusability?
• Promising components were tested across multiple contexts before acceptance
• Governance stayed lightweight with conversations, not committees

The result was a system that grew organically from real product needs rather than theoretical completeness.

Scaling the Team

The design system became our onboarding accelerator.

As Visibuild grew from 9 to 19 people, every new team member, whether designer or developer, received role-appropriate introduction to the system. Designers learned how to work within Figma's token structure. Developers learned the component library and linting rules.

What would have been weeks of "learning the codebase" became days of "learning the system." New team members could contribute meaningfully faster because the primitives were already solved.

The Turning Point

The moment the team became true believers was not when we shipped components. It was when they felt the speed of tokens.

Once designers could specify space-12 and developers could implement it without a single clarifying question, something clicked. The back-and-forth evaporated. Decisions that used to require meetings now happened asynchronously through a shared vocabulary.

The team went from following the system to protecting it. They understood its power because they had felt the alternative.

Current State and Sustainability

Today, the system includes:

I remain a key driver, but the system is self-sustaining. The team understands its value and will maintain it with or without me, which is exactly how it should be.

Remaining work:

The foundation is solid. The work now is completion, not creation.

What I Would Do Differently

Start with linting enforcement earlier. The tokens shipped quickly, but enforcement lagged. Every week without linting was a week of new hardcoded values entering the codebase, creating technical debt we are still paying down.

Key Takeaways

• Audit first, build second. You cannot systematise what you have not inventoried.
• Education enables adoption. A design system imposed is a design system ignored.
• Tokens before components. Get the language right before building the vocabulary.
• Enforcement is education. Linting rules teach the system better than documentation.
• Governance can be lightweight. Small teams do not need committees. They need conversations.