When I joined the company there wasn't much in the way of an actual design process at all: no consistency, structure, or shared understanding of how design should transition into development. The consequence of this was inconsistent implementation, design decisions lost, and ultimately tension between designers and developers.

There was no official project brief and no mandate to fix things. But I believed the work deserved better. So I started working on something on the side.

Spotting the Patterns

After working across several projects, it became clear that many of the challenges weren’t down to individual effort, but to a lack of shared process. Handoff looked different every time. Some designers created specs in a separate document, others relied solely on Figma. Developers often didn’t know what "done" looked like. Design reviews were ad hoc, and once something was handed off, designers often lost visibility of it.

There was a gap between what designers delivered and what developers needed. And that gap was costing time and product quality. Equally, there was a lack accountability from developers in terms of how designs were executed.

Taking Initiative

With no formal Design Ops function in place, I began researching and looking into simple ways to reduce friction.

The False Economy of Skipping Process

You can ignore the need for a design process for a while, just like you can ignore a toothache. But the pain doesn’t go away. It builds quietly in the background until that quick filling turns into a root canal.

Avoiding process might feel efficient in the moment, but it’s a false economy. You save time now but you pay for it later in miscommunication, rework, and  frustration across teams. Every unclear handoff, every guesswork implementation, is interest accumulating on a debt you didn’t realise you were taking out.

Building process doesn’t have to be heavy-handed.

I started with templates: a handoff checklist, a consistent spec format and a  documentation system to clarify design intent. I tested these tools on the in-app messaging functionality we were rolling out in one of our enterprise products. This gave me the chance to test and iterate on what I'd been working on with information from the developer's perspective.

The Mechanics of Better Handoff

How I structured the handoff process on one project to reduce friction and improve clarity:

Embedding Design into the Wider Workflow

Improving the mechanics of handoff was just the start. I also wanted to shift how design was perceived by other teams. I wormed my way in sprint planning sessions and dev stand ups, contributing to QA reviews as well as product roadmapping.

Design QA From A Developer's Perspective

One thing that really stood out in the pilot project I tested this out in was that there were a lot more questions from the developer working on the project. This signalled to me that design wasn't an afterthought (or something he wasn't considering at all) but instead was a part of his process.

He knew where to find the final design spec, what to check against, and how to flag questions or tradeoffs. Design execution was being treated as a shared responsibility.

What I've Learned

• Change doesn’t always need permission. Sometimes it starts with one person seeing a better way and testing it quietly.
• Design Ops is cultural as much as it is procedural. Tools and templates help, but it’s the relationships, rituals, and habits that sustain the change.
• Start small, stay consistent. You don’t need a full system to start improving the system. Small, repeated wins build momentum.

What’s Next

This work is still early—and that’s exciting. I’m continuing to evolve the handoff framework, onboard more designers to the process, and explore ways to measure its impact more formally.