Design systems as a way of working

While embedded across product teams, I started to notice a broader breakdown in alignment — not just across squads, but across disciplines and ways of working. Teams were delivering, but often without shared foundations for how decisions were made, understood, or carried forward.

This case study explores how those issues surfaced in practice, how they were addressed, and how a design system became a catalyst for shared understanding, confidence, and scale — not just visually, but culturally.

What I noticed

Working across multiple product squads, it became clear that teams were operating without shared foundations — not only in UI, but in how work was understood, built, approved, and evolved over time.

Delivery was moving forward, but decision-making was fragmented. Similar problems were being solved in slightly different ways, often without visibility into how those decisions affected other squads, disciplines, or the wider product ecosystem.

This wasn’t immediately obvious when looking at individual screens or features. It showed up in the day-to-day realities of delivery — duplicated effort, uncertainty around ownership, and teams hesitating to change things for fear of unintended knock-on effects.

Signals of misalignment

A number of consistent signals highlighted where alignment was breaking down. Individually, these issues felt manageable. Together, they created compounding friction across teams.

Inconsistent foundations

Over time, incremental design decisions had resulted in well over 100 colour variations across the product — largely subtle deviations of core brand colours — with no shared reference point guiding their use.

Ad-hoc interpretation between design and engineering

Spacing and layout intent were often unclear. In some cases, developers were drawing rectangles directly into Figma files to interpret spacing values, highlighting a lack of shared language between design and build.Rather than positioning the work as “introducing a design system”, the opportunity was framed around improving collaboration and decision-making across squads.

Fragmented styling architecture

Styling had grown organically. A central styling file had expanded to hundreds of lines, while individual flows pulled from their own stylesheets. This increased complexity and risk with every change.

Slow and fragile approval processes

Brand sign-off typically occurred on static designs. Once features went live, discrepancies often appeared, creating rework and straining relationships. Approval became reactive and difficult to scale.

No concept of reuse or iteration

Screens were designed and built as one-offs. Features were treated as complete at launch, rather than as foundations that could evolve, iterate, and scale across journeys.

Ways of working under strain

The lack of shared foundations placed strain on both delivery and relationships.

Product teams lacked clarity on what was actually being built, as designs were interpreted screen by screen rather than as reusable building blocks. Engineering teams absorbed increasing complexity to keep delivery moving. Brand teams lost confidence in outcomes once work went live.

As a result, delivery slowed, rework increased, and trust between teams gradually eroded — despite everyone working hard to move the product forward.

The Challenge

The challenge was not simply the absence of a design system, but the absence of shared structures that teams could rely on to collaborate effectively, make confident decisions, and scale quality without friction.

Framing the opportunity

Rather than introducing a design system as a standalone initiative, the opportunity was framed around improving how teams worked together.

This work was aligned with the launch of a new feature, using live delivery as a practical entry point. By building shared components screen by screen and applying them across journeys, the system could prove value immediately while remaining grounded in real product needs.

The focus was on adoption, alignment, and trust — not on creating a perfect library upfront.

Approach

My role spanned from identifying the opportunity through to facilitation, delivery, and ongoing support. This included:

Working closely with product, engineering, and brand to align on shared patterns and principles
Introducing component-led thinking through active product work rather than theoretical documentation
Bridging gaps between disciplines to create shared understanding and confidence
Securing buy-in and sign-off at senior and operational levels
Supporting adoption through documentation, collaboration, and mentorship

The system evolved alongside delivery, allowing teams to learn, adjust, and build confidence together.

Trade-offs and constraints

Delivery pressures meant this work needed to progress alongside active product development. There was limited appetite for pausing delivery to “design the perfect system.”

As a result, the focus remained on usefulness over completeness — prioritising momentum, clarity, and trust rather than exhaustive definition upfront.

Outcomes

This approach led to meaningful change across teams:

Components were built once and reused across multiple journeys
Feature delivery became faster and more predictable
Brand sign-off was simplified, with greater confidence in live outcomes
Teams shared a clearer understanding of patterns, intent, and quality
Documentation began to live alongside the system, supporting ongoing learning
Alignment between brand guidelines and product design improved, creating a single source of truth for change

Most importantly, teams moved from screen-by-screen execution toward shared foundations that supported iteration and scale.

Reflection

This work reinforced that design systems are not about control or consistency for their own sake. They’re about trust, shared understanding, and enabling teams to move forward together — especially in complex environments.

When treated as a way of working rather than a deliverable, design systems become a powerful lever for alignment, confidence, and long-term quality.