Structuring your UX Ops team: from one-person army to strategic powerhouse
In an earlier post, I talked about the need for multiple ops pillars in a modern design org: Design Ops, Research Ops, AI Ops, and UX Intelligence. But understanding the need is one thing, building the team is another.
Whether you’re just getting started or scaling fast, the key is to match your ops structure to your org’s complexity, maturity, and appetite for change. Not every team needs a full-fledged ops department on day one. But every team needs intentional structure if they want to grow without breaking.
Here’s how to think about structuring your Ops team, stage by stage.
Stage 1: the solo operator
Design org size: 5–20 people
At this size, you're likely flying with one scrappy ops lead, sometimes called a "Design Program Manager" or "Design Ops Manager." Their role is a little bit of everything:
Hiring coordination and onboarding
Tool and template setup (Figma, Notion, Miro, Jira, etc.)
Ritual design: crits, standups, reviews
Resource tracking (often in spreadsheets)
Process cleanup and facilitation
Workshop facilitation and light project wrangling
They’re probably also low-key coaching junior designers, running retros, and fielding “can you just” requests constantly. This is foundational work, but it doesn’t scale forever.
Tip: Focus on codifying the most painful recurring tasks first. The goal here is to reduce chaos, not build an empire.
Stage 2: the ops pod
Design org size: 20–50 people
Now things get real. You’ve got multiple teams, more hiring, more cross-functional complexity, and one person can’t cover it all. Now is the time to start specializing.
Typical structure:
Design Ops Lead (team of 2–3)
Owns rituals, staffing model, tooling, team health, onboarding
Starts building systems and documentation
Research Ops (part-time or embedded)
Begins standardizing participant management, consent, and study storage
Could be a dedicated role or shared with a researcher if research roles exist in your org
AI Ops pilot (optional but forward-thinking)
May fall under Design Ops or Innovation/Platform
Tracks AI tool usage, opportunities, and early governance
Tip: Start using OKRs or a roadmap to track ops priorities. Otherwise, they’ll get buried under “just-in-time” requests.
Stage 3: specialized functions
Design org size: 50–100+
This is where org complexity increases exponentially. You likely have platform teams, multiple product lines, and different maturity levels across squads. Ops becomes a strategic necessity, not just a nice-to-have.
Recommended structure:
Design Ops (core systems)
Design Ops manager
Design program managers aligned to ops pillars or horizontals (e.g., hiring/onboarding, tooling/budget, learning/training/development)
Systems designer(s) - focused on reusable workflows frameworks, templates, and scalable models for design and delivery processes, activities, and artifacts
Research Ops
Research Ops manager
Coordinator(s) for participant logistics, tagging, tooling
Possibly embedded specialists by product area, depending on research volume
AI Ops
AI Ops Lead (partnered with Design Platform + Data teams)
Prompt engineers, tool integrators, AI QA processes
Strategic initiatives around prompt libraries, ethics, usage guardrails
UX intelligence: visibility and metrics
UX Intelligence Lead or Design Analyst
Analysts / Dashboard Specialists partnered across Design and Research Ops
Tooling Integrators connecting Figma, Jira, research repositories, and HR systems for unified reporting
Focus areas:
Operational health: utilization, velocity, and capacity tracking, headcount planning, design-dev ratios
Practice health: skill mix, workload balance, learning engagement, design debt trends
Product design process tracking: visibility into how design flows through the SDLC — cycle time, handoff quality, QA feedback
Research impact: study volume, reuse, and coverage by product area
AI visibility: adoption, accuracy, time savings, and ethical adherence
Business outcomes: linking design maturity to measurable product impact
Getting org design right
This stage is where org design really matters.
Centralized under D\design: Keeps Ops close to practice needs and cultural alignment.
Cross-functional (design + product): Enables scale and shared metrics, but requires tight governance.
Hybrid / dotted lines: Works best when AI Ops or UX Intelligence need alignment with Platform or Data.
Get this wrong, and your Ops team becomes a dumping ground. Get it right, and they become force multipliers.
Common mistakes to avoid:
Treating Ops like admin. These are strategic roles. They drive efficiency, enablement, and scale.
Letting it become invisible work. Track impact. Share wins. Visualize outcomes.
Over-centralizing or under-resourcing. Ops needs to be close enough to the work to be useful, and empowered enough to help shape it
Isolating from design teams. Designers and design leaders are Ops’ end users—collaboration isn’t optional. Ignore it and your Ops roadmap will miss the real problems, and Ops’ impact becomes a moving target.
The takeaway
YYou don’t need a massive Ops org overnight. You do need intentional structure, clear scope, and executive support.
A well-structured Ops function protects your designers’ time, matures your organization, creates visibility into UX impact, and unlocks efficiency you’ll never achieve through brute force.
Simply put: Ops is how design scales — strategically, sustainably, and intelligently.
