What design ops actually does (and what it shouldn't)

Design ops gets explained as "the systems and processes that allow design to scale." Which is accurate and tells you almost nothing about what the person in the role actually spends their time on.

In practice, the job is different at every company. At some places it's program management. At others it's tooling and workflow, or research ops, or whatever process improvements nobody else owns. The role attracts motivated people and buries them in administrative work they didn't sign up for.

The version that works

Design ops earns its cost when it removes friction from the design process. Specifically: friction that repeats. If designers at your company spend an hour every week dealing with the same tooling issue, the same access request, the same unclear handoff, that's where design ops should be.

The useful design ops work tends to be invisible once it's done. A well-run research recruitment process that designers don't have to think about. Figma libraries that stay organized without anyone managing them heroically. Onboarding documentation that actually reflects how the team works, updated when things change.

None of that is glamorous. It doesn't generate portfolio work. It makes everyone else's work easier, which is the point.

The failure mode

Design ops fails when it takes on strategy work it doesn't have authority to execute. This usually happens for understandable reasons. The role attracts people with strong opinions about how design should work, and there's often a real gap between how the design organization runs and how it could run.

But design ops isn't a design leadership role. It can inform strategy; it can't own it. When design ops takes on questions like "what's the right organizational model for design" or "how should design relate to product," it either gets ignored or creates confusion about who actually owns those decisions.

The clearest sign a design ops function is overextended: the people in it are frustrated that their recommendations aren't being followed. They've diagnosed problems correctly and proposed good solutions and nothing is changing. That's not a design ops problem. It's a leadership problem, and design ops doesn't have the lever to fix it.

What to give to design ops and what not to

Give it: tooling decisions, process documentation, cross-team coordination overhead, vendor relationships, research operations, onboarding.

Don't give it: design direction, organizational structure, hiring decisions, what the standards are. Those require authority that design ops doesn't have.

The cleanest design ops setups have a clear scope, a direct relationship to design leadership, and explicit decisions about what's in and out. The messiest ones have accumulated scope over time with no one deciding what the role is actually responsible for.