Context

When I joined The Mobility House, the product suite had grown across multiple applications, each with its own interface language, its own component patterns, and its own definition of what a button looked like. Teams rebuilt the same UI elements repeatedly. Every new feature started from scratch instead of building on decisions the team had already made.

The cost was time. Design handoffs were slow because there was nothing to hand off to. Development was slow because engineers were rebuilding components across three codebases. And scaling was impossible: each new product inherited the same inconsistency.

I rebuilt DesignGrid from the ground up: a single source of truth for UI decisions, tested before code, adopted across the suite.

The problem

The fragmentation wasn’t cosmetic: it showed up in three ways.

• Inconsistent UI meant inconsistent workflows: one product used modals for configuration, another used panels. A toggle meant one thing in the dashboard and something else in the installer app. This wasn’t a polish problem: it was cognitive load. Every new user and every new engineer had to learn the language from scratch.
• The work was repetitive: designing a new feature meant gathering screenshots from old features, tracing the patterns, rebuilding the components, then waiting to find out whether dev had already built something similar. No single source of truth meant constant duplicated effort.
• Brand identity was diluting: TMH’s new brand guidelines existed but applied unevenly. Some products followed them closely; others had adapted them so far that users couldn’t tell they belonged to the same suite. White-labeling was painful: reusing components across customers meant reworking layouts every time.

Approach

Why Atomic Design: I studied how other companies were building design systems: the patterns they used, where they struggled, what actually stuck. Brad Frost’s Atomic Design methodology organizes components by complexity: atoms (the smallest elements), molecules (simple combinations), organisms (complex, multi-part systems). That hierarchy forces a discipline: you can’t build an organism without first deciding what the atoms are. Consistency by design rather than by process.

The three pillars

• Accessibility as a foundation, not an afterthought: colour contrast, touch targets, and OS conventions were entry requirements, not polish. I audited the existing suite with Stark and found core table text failing WCAG on every threshold (normal and large text, AA and AAA). The DesignGrid palette was built to clear all four. Contrast on primary table content went from 2.55:1 to 18.92:1.
• Communication with developers, from day one: I didn’t design the system and hand it off. I built it with the engineering team, listening to their edge cases, understanding what they needed to implement quickly, and designing components developers would actually want to reach for.
• A single source of truth in Figma, tested in code. Components live in two places: the design file, where decisions are made, and the code repository, where they ship. Chromatic kept the two in sync, catching visual drift before it became debt.

The architecture

Atoms. The base layer: buttons, inputs, labels, icons, avatars. Once you define what a button is, every component that needs a button inherits that decision.

Molecules. Simple combinations: form groups (label + input + helper text), navigation items (icon + label), action cards. This is where you start to see how atoms cooperate.

Organisms. Complex, multi-part systems: modals, tables, dashboards, data forms. This is where the leverage shows: you’re not starting from scratch, you’re assembling tested pieces.

Templates. Page-level skeletons: the arrangement of organisms into a working view. A template decides where the navigation sits, where the primary table lands, how a configuration panel relates to the content behind it.

The real challenge: designing for adoption

Building the system was the easy part. Getting teams to use it was the hard part.

Shipping a component didn’t make anyone use it. Adoption meant sitting with teams, walking through the component, explaining why this shape and not that one, and answering the inevitable “but what if we need to…”. The system was never about restriction. It was about making the right choice the easy choice.

The resistance was real, and it was reasonable. Engineering pushed back twice: first on building a design system at all, and later on the data-heavy tables, the most expensive components in the library to build and maintain. Both objections came from the same place: a large upfront cost against no immediate user-facing feature.

Neither objection was wrong on its own terms. The design system got built because Ant Design made the first step cheap enough to take. The tables got built because I stopped arguing and went to look.

The same instinct drove the site setup redesign. The old flow moved you through five separate views to configure a single site, with no overview anywhere. I pushed for a stepwise structure with the full data model visible in one place, so dependencies were legible at a glance instead of discovered by clicking forward.

Testing & validation

Chromatic became the QA layer that kept the system honest. Every component change was tested across viewport sizes, interaction states, and edge cases before it reached code, catching the inconsistencies that otherwise surface only when three engineers implement the same button three different ways.

The sharpest feedback came from real use. Redesigning the Dashboard on the new components made teams surface gaps: “we need a variant for this”, “this doesn’t support that state”. Those requests fed straight back into the library, so the system grew from what the products actually needed rather than from what I’d anticipated.

Outcome

Before DesignGrid there was no front-end component library and no design source of truth. Designers copy-pasted screens from old features; engineers rebuilt the same table, the same dropdown, the same modal across three codebases. Every new feature paid the full cost of every decision that had already been made once.

That’s where the time went, and that’s what the system took back. The first product is slower, because you’re building the system and the product. The second is faster. By the third, the recurring decisions are already made and the saving compounds. Engineering’s internal estimate put the reduction in development time for new features at roughly 80%.

2.55:1 → 18.92:1

contrast on primary table content, now clearing WCAG AA and AAA

3

products consuming a shared component library

1

source of truth, synced between Figma and code, tested in Chromatic

What one system taught me

• Consistency isn’t about control: it’s about clarity. The worst design systems say “you must use this”. The best make it obvious why you’d want to. When an engineer reaches for a tested button instead of relitigating button sizes in code review, that isn’t restriction: it’s a gift.
• A design system is only as strong as its adoption. I could have built something thorough and beautiful and shipped it into silence. What made DesignGrid work was sitting with teams, answering why this decision, and treating their edge cases as system insights rather than exceptions.
• Stop arguing, go get the recording. I spent weeks making the case for rebuilding the tables and got nowhere. Twenty minutes of Hotjar sessions did it. When a decision is stuck between two reasonable positions, the fastest way out is usually evidence neither side has seen yet, and I should have reached for it sooner than I did.
• Infrastructure is design work. I arrived thinking I’d design components. What I actually did was reshape how the team makes decisions. That’s design: it just isn’t visible in the final product.

The bigger picture

I built the system that let teams ship fast.

This is the work that doesn’t appear in a user-facing feature but changes how fast a team can move. One investment in getting the system right multiplies across every product that uses it. I came in expecting to design components; what I designed was the decision-making layer underneath them.