The behind-the-scenes work that determines whether a design team can scale without falling apart.

Design Ops is the practice of improving how a design organisation functions — its tools, file structures, workflows, rituals, and infrastructure — so that designers can spend their time designing rather than managing coordination overhead.

If design leadership is responsible for the quality of the work, Design Ops is responsible for the conditions that make high-quality work possible. The two are related but distinct, and confusing them is one reason many teams under-invest in operations until the pain becomes obvious.

The term became common in the mid-2010s as design teams at large tech companies — Facebook, Dropbox, Airbnb — grew large enough that coordination and tooling became a full-time concern rather than something the design manager handled informally.

At companies that haven't reached that scale, Design Ops often doesn't have a name or a dedicated owner. The functions still exist — someone is managing tools, onboarding new designers, maintaining the Design System — they're just distributed and usually under-resourced. That works until it doesn't.

Design Ops touches a wide surface area:

• Tooling and infrastructure: Which tools the team uses, how files are organized, how components are named and versioned
• Design system operations: Who maintains the system, how contributions are proposed and reviewed, how changes are communicated to the product team
• Research operations: How usability studies are scheduled, how findings are stored, how research informs ongoing product decisions
• Onboarding: How new designers learn the team's processes, tools, and standards
• Rituals: Design reviews, critiques, cross-functional syncs — who runs them, at what cadence, with what outcomes
• Metrics: How the design team measures its own impact

A few patterns indicate a team has outgrown informal operations:

• Designers spend significant time managing files, tools, or handoffs rather than designing
• Research findings are documented but rarely acted on
• The Design System exists but is inconsistently applied across the product
• New designers take months to become productive because there's no structured onboarding
• Nobody can clearly say who owns which design decisions

These aren't discipline problems. They're infrastructure problems. Hiring more designers without fixing the infrastructure makes them worse, not better.

The highest-return first investment in Design Ops is usually file organization and naming conventions — unglamorous but immediately impactful. After that: a clear ownership model for the design system, a searchable research repository, and a lightweight onboarding guide.

Formal Design Ops roles make sense once the team reaches around 8-10 designers and operational overhead is visibly costing design capacity. Before that, the functions can be distributed — as long as they're genuinely owned and resourced, not just assumed to be someone's side responsibility.