Design Systems as a way of working and not just a design file.
The ask.
While embedded across product teams, I began 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, documented, or carried forward, leading to repeated conversations and fragmented understanding.
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.
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 continued, 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 make changes 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, but together they created compounding friction — increasing manual interpretation, slowing decisions, and raising the cost of change across teams.
Inconsistent foundations
Over time, incremental design decisions resulted in well over 100 colour variations across the product — largely subtle deviations of core brand colours — with no shared reference point to guide their use. As a result, teams relied on memory and judgement rather than a system to make consistent decisions.
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, reducing interpretation, and supporting clearer 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, making even small updates harder to reason about and more dependent on individual knowledge.
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, with feedback often arriving too late to meaningfully influence decisions.
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, be reused, and inform future decisions 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, while 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
- Using supporting tools to audit patterns, surface inconsistencies, and reduce manual overhead as the system evolved
The system evolved alongside delivery, allowing teams to learn, adjust, and build confidence together.
Supporting the system
As the system grew, maintaining consistency through manual review alone didn’t scale. To support this, We introduced lightweight tooling to help audit components, identify edge cases, and surface where patterns had drifted from their intended use — often before issues reached development.
These tools were used to support judgement, not replace it: speeding up checks, highlighting inconsistencies, and creating space to focus on higher-value design decisions. The aim wasn’t automation for its own sake, but reducing friction and risk as the system evolved alongside delivery.
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, supported by lightweight tooling that made it easier to keep patterns accurate and up to date as the product evolved
- 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 aren’t 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. That includes supporting teams with the right tools at the right moments — reducing friction and overhead while keeping judgement, responsibility, and decision-making firmly human.
Relative Writing.
January 2026 | Systems
UX beyond 'designing' buttons
Facilitation, learning, and shared understanding turn systems into better ways of working across teams.
View blog post >
January 2026 | Artificial Intelligence
AI as support, not substitution
We all talk about tools at work — the ones that promise speed, clarity, or better outcomes. But the tools that matter most are usually the ones that quietly support the work, not the ones that try to do it for us.
View blog post >