Design System Transformation

There was no strong common visual identity. Different parts of the application solved the same UI problems in different ways — not because anyone did it badly, but because each was built when it was needed, by whoever needed it, with no shared reference to build against.

Everyone was solving UI locally.

I worked with a product designer on what the product should actually look and behave like: colour, typography, iconography, grid, spacing, interaction patterns and component behaviour. That exploration ran for a month or two before anything was worth building — the point was to agree on the foundations the components would share.

Material UI gave us a low-level foundation to build on; it was not the design system. Components were adapted and rebuilt to follow our own language, documented in Storybook, reviewed by the designer before release, published as an internal npm package, and consumed by the portal like any other dependency.

Design→Code→Review→Release

That distinction mattered. It stopped being a folder of shared React components and became a versioned, reviewable surface that engineering could depend on.

The first release covered the things every page needed, and nothing more. Complex components came later, once the primitives underneath them were settled and being used.

Don’t begin with the fancy components.

A new counsellor dashboard was being built around the same time, so it became the first real product surface designed entirely around the new system. When it was reviewed with business stakeholders the response was strongly positive — which is what made the rest of the work possible.

Once the system had proved itself on a real dashboard, I worked through the existing portal page by page, replacing one-off patterns with shared components. It was roughly six weeks of concentrated migration, and I handled a substantial part of it myself.

The same primitives now carry increasingly complex workflows — statuses, verification steps, document handling, nested application state — without each page reinventing how those things should look.

Our component library wasn’t designed to become a universal company package — other pods had different audiences and different visual needs, B2C and B2B alike. What travelled instead was the practice: other teams began formalising their own.

Shared principle > shared pixels.

“The portal finally started to feel like one product.”

Building the components was the straightforward part. The more important work was creating trust in the system — with designers, with engineers, with business stakeholders, and eventually with the existing product itself.

Consistency is a product feature.