The layers of UX Ops
Building out design, research, and AI Ops
When most people talk about “UX Ops,” they’re lumping everything into a single catch-all: tools, templates, onboarding, hiring coordination, OKRs, metrics, team health, research processes, prototyping platforms - basically all the things. But if your design org is growing (or already too big and feeling the pain), you can’t run it all through one overworked generalist with a Trello board and a dream. You need layers. Functional specialization. Actual strategy.
UX Ops at its core is meant to force multiply the UX practice, and done right, enables designers and design managers to focus on design. And that focus unlocks innovation, consistency, and quality at scale. Designers and managers should be digging into design strategy, understanding the problems, and driving vision for solutions, not drowning in organizational or design process chaos or tooling confusion.
I’ve been doing this ops thing for about 15 years now. Long before it was even called that. While it’s not my primary focus at the moment, I’ve got a deep well of experience in it, and a good amount of perspective. In those early days, I was that generalist with a Trello board and a dream. Whether I was an IC or as a manager, I was hanging on for dear life, building out ops practices while also doing my “real” design job. These days, I’m glad to say that ops is a more well-defined discipline, and there are dedicated roles and teams, but it’s set to morph again with the addition of AI.
So let’s talk about the ops stack you really need, and what that structure could look like in practice.
Layer 1: Design Ops – the backbone of scale
Design Ops is the most well-known variety in the ops world. Think of it as the connective tissue that holds the design org together. It's the backbone, the operating system, the thing that makes good design repeatable and sustainable.
But here's where people get it wrong: Design Ops is not the department of “make it easier.” It’s not just project wrangling or tool onboarding or cracking the consistency whip. When done well, Design Ops is a strategic capability that:
Maps design team allocations to org priorities and creates realistic capacity planning
Creates scalable hiring, onboarding, and growth workflows that set consistent expectations and results across hiring managers
Aligns hiring with actual skills gaps (not panic-fueled headcount requests)
Designs rituals for critique, collaboration, and creative safety
Balances governance with enablement
Creates systems and templates for scalable delivery — requirements, design QA, templates for workshopping, spec handoff, etc.
Builds frameworks for design intelligence that enable clear conversations and visibility of design work, capacity, and risks
If your Design Ops team is only responding to intake requests and not seeking out the problems to solve via collaboration with design leaders, they’re operating in reactive mode. Just like designers shouldn’t be Jira ticket takers cranking out wireframes on demand, a design ops team should be proactive in anticipating needs and priorities, and build a collaborative roadmap with their design leadership partners.
Layer 2: Research Ops – the engine of evidence
As soon as your research maturity moves beyond scrappy interviews and wiki summaries, you need Research Ops. Not because researchers can’t handle logistics, but because logistics are just part the job and they can become a distracting add-on to actually executing research.
Strong Research Ops makes it easier to do research and enables:
Participant sourcing and management (with ethical guardrails and legal considerations)
Research repository structure and taxonomy, including a centralized insight library that supports patterns over time—not just one-off decks (I once did an experiment using Obsidian as a research repository…maybe I’ll write about that someday)
Research processes and decision making frameworks to accelerate time to insights
Tools, templates, and infrastructure that reduce friction and eliminate bias (e.g., screener templates, consent management, AI summaries with human QA)
Standardized tagging, prioritization, and feedback loops with product and design
Amplification of research impact
Done well, Research Ops creates leverage, and insights stop getting lost in the wiki wasteland and start shaping roadmaps.
Layer 3: AI Ops – the new frontier (that’s already here)
AI Ops in a design org isn’t just for the platform or MLOps teams anymore. If you’re even thinking about using AI to generate flows, assist with copy, translate designs into code, or even suggest layouts, you now have AI components inside your creative workflow. Now is the time to get ahead and lay the right foundation from the start.
That needs AI Ops.
Here’s what that might include:
Vetting and integrating AI tooling into your design process
Creating prompt libraries and safe defaults (prompt hygiene is a thing)
Standardizing workflows for co-creation with AI agents
Training designers on when to use AI and how to refine and QA its output for all areas of UX - design, writing, research
Ethical guardrails to protect privacy, originality, and bias mitigation
Tagging and telemetry to track how AI-generated work performs at scale
AI Ops helps prevent prompt and agent sprawl with dozens of half-baked attempts to use AI that never scale, never get documented, and never repeat. If you want AI to be more than a novelty, you need structure around it.
Right-sizing ops for your org
The way you structure Design, Research, and AI Ops depends on your org’s size, complexity, and maturity, but here are some loose guidelines:
Small orgs (5–20 designers):
Start here, start now. You’ll thank yourself later (and so will your team) as you scale smoothly. One Design Ops lead can cover core workflows, with light support for Research and AI Ops baked in.Mid-sized orgs (20–50 designers):
Design Ops expands into a small team. Research Ops typically splits into its own function. AI Ops emerges as a cross-functional collaboration.Large orgs (50+ designers):
Each Ops layer becomes its own dedicated function with shared infrastructure, clear ownership, and measurable impact.AI-forward orgs (any size):
Don’t wait for Eng or Data Science to define AI workflows. Design needs a seat at the table early to shape systems and guardrails.
Final thought: Ops isn’t useless overhead. It's your scalability strategy.
If you’re still thinking of ops as “support,” you’re setting yourself up for chaos. Ops roles are multipliers. Without them, your best designers and design managers spend their time reinventing the wheel, firefighting, and eventually burning out. And you get inconsistent output that leadership can’t trust.
A well-layered ops stack builds institutional memory, enables sustainable delivery at scale, and frees your design team to do what they do best: design great products.
Curious about Design Systems?
Sure, design systems have a lot of seemingly ops-related pieces—processes, tokens, standards, Figma libraries—but they’re not just an operational layer. They’re a product. I wrote a whole post about this. Read about how I think about Design Systems as Product
