Design system alignment program

Embedded DS specialists

3

Product design teams served

5

Designers across all teams

20+

Months of active engagements

12

Getting closer to
the work, on purpose

The model wasn't complicated in concept. Embed DS expertise inside product teams, work alongside them rather than in response to them, and leave something behind when you go. The difficulty is in the execution: specifically in resisting the urge to arrive with answers before you understand the problem, and in planning the exit from day one rather than treating it as an afterthought.

I designed the engagement framework and led the initiative across all five verticals. In most engagements my role was strategic: aligning with directors and vertical leads, managing program direction, making sure the embedded designers had what they needed to operate. In one engagement, with our largest vertical and a team being simultaneously reorganised into new pillars, I was closer to the day-to-day: not in the files, but more present in the communications and alignment work. That one was the hardest to navigate and, looking back, produced some of our most self-sufficient champions.

1. 01

   Listen first

   Each engagement started with the embedded designer joining team rituals and design reviews as an observer. No output, no deliverables pushed, just presence. Understanding how the vertical actually worked and what drove the decisions that drifted from the system. You can't co-create with a team you don't understand yet.

   Phase 1 · Observe
2. 02

   Build with, not for

   Working sessions on real projects, not hypotheticals. Helping teams swap themes and fix broken Figma style connections, and running Quality and Coverage sessions: file walkthroughs on what was working, what wasn't, and why things had drifted. Sometimes that meant replacing components, sometimes building a domain-specific extension the core system didn't cover yet.

   Phase 2 · Co-create
3. 03

   Leave them stronger

   Every engagement was planned with a structured handoff from the start. We identified designers who engaged more deeply with the system and gave them more exposure and context. Not gatekeepers, but advocates. Handoff sessions were recorded, Slack support channels stayed open, and the exit was a gradual step back as confidence grew.

   Phase 3 · Hand off

Systems work
is people work
in disguise

A few things worth making explicit about how this actually worked.

1. 01

   The engagement framework was lightweight by design. Each one started with a kick-off conversation between me, the embedded designer, and the relevant product design director or manager. Not to set rigid deliverables, but to understand their priorities, pain points, and what would actually unblock them. We then aligned with the front-line designers to understand where they felt the gaps in knowledge and confidence. This set expectations for everyone and meant the embedded designer could hit the ground running, rather than spending weeks figuring out what to focus on.

2. 02

   The Quality and Coverage sessions were deliberately run as conversations, not evaluations. We’d sit with a designer, open their files, and talk through what we were seeing together. Teams often already knew where the drift had happened: “yeah, we know we’re using all different button styles in here.” What they needed was the context to understand why it mattered and a partner to fix it with them, not a report telling them they’d done it wrong.

3. 03

   Knowledge transfer was built into every exit. Handoff sessions were recorded where possible so future team joiners could benefit too. Slack channels stayed open. Check-ins were scheduled and a governance model was shaped to help teams maintain progress without needing the DS team back in the room.