Building M&S's Colleague Design System

Turning a design vision into an engineering capability through AI and cross-functional collaboration

Executive Summary

Creating a visual language gave Marks & Spencer a shared philosophy for designing colleague products. The next challenge was making that philosophy practical.

With more than 100 colleague-facing products, around 50 product teams and a newly established design function, every team was still solving the same problems independently. Engineers were repeatedly building components from scratch, designers lacked a common set of reusable assets and Product teams faced unnecessary delivery effort every time a new product or feature was created.

I led the creation of the colleague design system, transforming the visual language into a scalable platform that enabled Design, Product and Engineering to work from the same foundations. When limited engineering capacity threatened to delay implementation for well over a year, I introduced AI-assisted development workflows to generate production-ready components, documentation and code examples, reducing implementation from an estimated eighteen months to approximately two months.

The result wasn't simply a component library. It established a repeatable way of building products that improved consistency, accelerated delivery and fundamentally strengthened collaboration between Design and Engineering.

From Philosophy to Capability

The visual language had established what good colleague experiences should feel like.

The design system would enable teams to build them.

From the outset, these initiatives were always intended to work together. The visual language created alignment around principles, while the design system would translate those principles into reusable components, patterns and documentation that could be adopted across every product.

Without it, every new team would continue solving the same interface problems repeatedly.

Designers would recreate components.

Engineers would rebuild them.

Product teams would absorb the additional cost.

Creating a design system wasn't about improving efficiency for Design alone. It was about increasing the capability of the entire organisation.

Solving the Right Problem

It would have been easy to start by creating every conceivable component.

Instead, I wanted the system to evolve from real product work.

At the same time as building the design system, I was working closely with the Central Store Stock Management product team. This became the ideal environment for testing assumptions, validating interaction patterns and understanding which components genuinely deserved to become reusable standards.

Every iteration informed the next.

Components entered the system because they had already demonstrated value with colleagues rather than because they seemed useful in theory.

Equally important was recognising what shouldn't become standardised.

Working across more than one hundred products quickly demonstrated that there would always be contextual differences between domains. Rather than forcing complete uniformity, the system deliberately left room for designers to exercise judgement where context mattered.

The goal wasn't to eliminate design thinking.

It was to remove repetitive decision making so designers could focus on solving user problems.

Building Trust Through Collaboration

The technical challenge was only one part of the project.

The organisational challenge was larger.

When I joined, Design had very little established relationship with Engineering. There was enthusiasm for a design system, but no clear ownership, no dedicated engineering resource and little capacity to build one.

Rather than waiting for ideal conditions, I chose to build alongside Engineering.

The first step was understanding how engineers preferred to work—their coding standards, development practices and technical constraints. This transformed the relationship from Design handing over screens to both disciplines working towards a shared solution.

We collaborated daily, with weekly reviews used to refine components until both Design and Engineering agreed they were production ready.

Interestingly, there were very few disagreements.

Most discussions became collaborative problem-solving sessions where questions were explored together rather than positions defended.

As the project progressed, Engineering increasingly viewed Design as a strategic partner rather than simply a service function.

Within an organisation traditionally led by Product and Engineering, this represented a significant shift in how the design team was perceived.

Using AI to Remove Organisational Bottlenecks

One of the biggest risks facing the project was implementation.

Even with agreement across teams, building an entire design system through traditional engineering processes would have required significant resource and was unlikely to be prioritised.

Rather than accepting that delay, I explored whether AI could help bridge the gap.

The idea emerged while trying to explain the typography system to engineers who didn't have access to our Figma files. I built a small prototype in Replit that translated our design foundations into an interactive environment where developers could experiment with styles directly.

The reaction was immediate.

Instead of lengthy explanations, developers instinctively understood how the system worked.

That single prototype fundamentally changed my thinking.

If AI could communicate typography this effectively, perhaps it could accelerate much more.

From there, the project expanded rapidly.

AI became a practical partner in generating component documentation, producing initial component implementations, creating a reusable codebase and documenting how teams could integrate components into their own applications.

Every output was reviewed, refined and validated collaboratively with Engineering, but the time saved was substantial.

What initially appeared to be an eighteen-month implementation challenge became achievable in approximately two months.

More importantly, AI didn't replace collaboration.

It created more opportunities for collaboration by removing repetitive work and allowing Design and Engineering to spend more time refining the user experience rather than recreating boilerplate code.

Driving Adoption

Rather than treating the design system as a major launch, adoption happened through product delivery.

Teams already working alongside Design naturally became early adopters as new features were developed.

New product teams were introduced to the system as part of discovery, allowing them to understand both the visual language and the practical tooling available before development began.

This incremental approach reduced resistance.

Teams experienced the value through delivery rather than being asked to adopt another internal standard.

Central Store Stock Management and Help Hub became two of the strongest advocates, demonstrating how reusable components could improve both delivery speed and product quality.

Product Managers also began measuring reductions in implementation effort as the system became established, reinforcing the business value beyond Design itself.

Lasting Impact

Today, the colleague design system provides the operational foundation for delivering consistent experiences across the colleague product ecosystem.

Designers have reusable assets supported by clear rationale.

Engineers have shared implementation guidance rather than rebuilding components repeatedly.

Product teams begin new work from an established foundation instead of a blank canvas.

Perhaps the most significant outcome was cultural.

The project demonstrated that Design could identify organisational problems, build practical solutions and work alongside Engineering to solve them—even when the ideal resources weren't immediately available.

Version two is already expanding upon these foundations, migrating into GitHub, extending documentation and introducing reusable journey patterns.

The direction is now established.

Reflection

Looking back, I'm proudest of the decision not to wait.

When it became clear that a fully engineered design system wouldn't be prioritised, the easiest response would have been to accept the constraint.

Instead, I looked for another path.

By combining strategic design thinking, close engineering collaboration and AI-assisted development, we created a solution that not only accelerated delivery but fundamentally changed how Design and Engineering worked together.

My contribution wasn't simply creating a design system.

It was recognising an organisational bottleneck, taking ownership when no one else could and leaving behind a capability that will continue enabling better products long after the individual components evolve.