DesignOps is a design discipline

I still introduce myself as a designer, even as I took on the role designOps. I just design human systems instead of software systems now.

It took me a while to notice this. I wasn't resisting DesignOps or thinking I had to leave design behind…I was just doing the work. But at some point I realised I was unconsciously shaping my DesignOps practice by drawing from my design practice. Same thinking, different canvas.

How it started

It began with small things: creating standardized research templates, sharing reusable UI components on Sketch (Figma wasn't a thing yet), organising meetups with other UX teams to exchange knowledge.

I wasn't trying to build a career in DesignOps. I was just noticing friction and trying to reduce it.

The turning point

When the three regions merged, I realized no one was coordinating the change for everyone. My manager asked me to form a small working group to tackle immediate problems—demand, intake, the operational stuff. That trust mattered, and so did having people to problem-solve with.

We started with the concrete issues, but quickly realized the harder problems were the unspoken human ones: different working styles, communication norms, expectations no one had named. The technical consolidation was straightforward, but the cultural integration required a completely different approach.

We ended up using anthropological methods instead of design sprints—the same human-centered thinking we all knew, just applied to organizational dynamics. The data was messier and the feedback loops were slower, but it was still fundamentally design work.

What I noticed

I was approaching DesignOps the same way I approached design: solving for human needs, iterating toward better solutions, making the invisible visible. Just with others and at a different scale.

And that's what leadership looks like for me: not managing people, but designing the conditions for people to do their best work.

What actually shifted

My scope expanded, but my identity didn't. We design conditions instead of solutions now, systems instead of interfaces, infrastructure instead of features. It's more ambiguous and harder to measure, but the approach stayed constant: observe, understand, design for real needs, iterate.

If you're making this transition, know that it starts smaller than you think. You need sponsorship, trust from your manager, and people to problem-solve with. And you're not leaving design behind—you're discovering what else can be designed when circumstances align.