Enterprise Design System: Architecture & Adoption

Companion case study: this piece covers the system itself: architecture, tokens, documentation, and adoption. The creative direction and product UI it supported are covered in Banking Platform: Creative Direction.

NDA note: this is an NDA-protected project. The process described is real; visuals are representative.

Context

Inside a financial institution running several digital products, every new project started by rebuilding the same things: buttons, form fields, error states, navigation. Each team solved them slightly differently. The cost showed up twice: once in duplicated effort, and again in a customer experience that felt assembled rather than designed.

The brief was a design system. The actual problem was that teams had no agreed definition of correct, and no cheap way to find one.

The Problem

No shared foundation. Multiple products, each with its own interpretation of the brand. Nothing was reusable because nothing was authoritative.

Two platforms, different physics. The system had to serve React on web and Flutter on mobile. Flutter’s widget model doesn’t map cleanly onto web component conventions, so a naive shared library would break the moment it met real mobile code.

Distributed teams. Designers and engineers sat across departments and vendors. Anything requiring a meeting to interpret was going to fail.

Speed pressure. Delivery timelines assumed the system would accelerate teams immediately, not after a six-month adoption curve.

My Role

I owned system architecture. I designed the component library and token model, wrote the documentation, defined the contribution and naming standards, and worked directly with engineers on both platforms to make sure the system held up in code rather than only in Figma.

Process

1. Foundation: tokens before components

I started with design tokens rather than components, because tokens are what make a system survive two platforms. Colour, typography, spacing, and elevation were defined as named values with no platform assumptions baked in, then mapped separately into React and Flutter.

Components came second, structured on atomic design: atoms, molecules, organisms, so teams could compose rather than request.

2. Structure and naming

Naming was the highest-leverage decision in the project. A distributed team can’t ask clarifying questions at scale, so names had to be self-explanatory and predictable enough that engineers could guess correctly.

3. Platform adaptation

For mobile I reworked components against Flutter’s constraints rather than forcing web patterns onto it. Where a pattern couldn’t survive translation, I designed the platform-appropriate equivalent and documented the mapping, so a designer and a Flutter engineer would still agree they were looking at the same component.

I also built a notification framework covering how the products communicate state and errors, a repeated decision turned into a rule.

4. Documentation and adoption

A system nobody adopts is a folder. I wrote usage guidelines, do/don’t examples, and contribution rules, then ran feedback loops with the teams consuming it to find where the system was fighting them.

Key Decisions

Tokens first, components second. Building components first would have hard-coded web assumptions that Flutter couldn’t honour. Starting at the token layer meant one source of truth and two honest translations.

Documented divergence over forced parity. Pretending React and Flutter can render identical components produces a system engineers quietly abandon. Naming the divergences kept the system trustworthy.

Guessable names over precise ones. I optimised naming for what a distributed engineer would search for, not for taxonomic correctness.

Outcome

One foundation across platforms. Web and mobile products built from the same token source and a shared component vocabulary, replacing per-project reinvention.

Faster standard work. Teams composed common screens from existing components instead of designing and building them from scratch each time.

A system that could be extended. Contribution rules and naming conventions meant teams could add to the system without forking it.

Technical Implementation

Reflection

What worked. Involving engineers from the start. Every component I designed in isolation needed rework; every one I designed alongside the people implementing it shipped close to intact.

What I’d do differently. I treated documentation as a phase rather than a product. It should have shipped alongside each component from day one, because undocumented components get used incorrectly and then get blamed.

What I learned about governance. The hard part of a design system isn’t the components. It’s holding the line between flexible enough to solve real problems and consistent enough to be worth having. That balance is a standing negotiation, not a decision you make once.