Research Ops is Part of Design Ops
When I returned to Poland three years ago, I almost took a job with the title Design Researcher. My background in Human-Technology Interaction (HTI) and my experience planning complex user research for ROV truck steering prototypes-work that put me shoulder-to-shoulder with experts at RISE and other leading Swedish labs-made me a perfect fit for Emerson's new hub opening in Warsaw. The role looked thrilling, but the workload signalled endless travel and 6 a.m. and p.m. syncs across time zones. I chose a different path, joining Silk Software House and later launching Effect-Driven Design.
That work offer back then forced me to think deeply about how user research is designed, resourced, and embedded in product teams-in other words, about research operations. Over the past three years, I have led or advised half a dozen projects, from skunk-works pilots to enterprise programs. In every case the same truth reappeared:
Research operations ("ReOps") is not a side-quest; it is a pillar of design operations ("Design Ops"), which itself sits inside the wider discipline of product operations.
Below is a field report on why that hierarchy matters.
From Lone Studies to Repeatable Systems
When I first began leading multi-disciplinary design teams, I learned quickly that "doing research" and "operationalising research" are two different sports. Planning a single diary study is one thing; building an engine that lets any designer spin up a study next Tuesday without reinventing the legal agreements, recruitment templates, or data-privacy checklists is another. That engine is research operations, and it makes or breaks both budget allocation and insight quality.
Sometimes I inherit a robust engine. In my Talent Alpha engagement, for example, a sharp product owner already held semi-structured user interviews and logged everything in Confluenca. Other times-like in two projects I am running right now-the in-house designers are motivated but junior; they sense the value of user research yet need mentorship to shape hypotheses, pick methods, schedule sessions, and share findings in a format the rest of the company can act on.
The pattern never changes: Solid research operations safeguard quality, speed, and relevance. Weak ReOps bleed money and goodwill.
Why ReOps Belongs Inside Design Ops
Many teams treat research operations as a parallel universe: "Design does the screens; Research does the interviews; Ops is… spreadsheets?" That split misses the overlap. Design operations is the orchestration layer for everything that turns intent into product-from component libraries to sprint rituals to, yes, research pipelines. If design operations are responsible for efficiency and consistency, then the systems that power user research have to sit under the same roof.
A neat way to picture the hierarchy:
Product Operations
└── Design Operations
└── Research Operations
Thinking this way helps set priorities. Design Ops keeps the interface library accessible, the review cadence sane, and the build process humane. Research Ops ensures research methods choice, participant recruitment, data governance, and insight distribution happen without bottlenecks. Treating ReOps as Design Ops' little sibling gives it the mandate-and the budget-to matter.
Two Current Projects, Two Different Risk Profiles
1. Early-Stage Marketing SaaS (Stealth)
The first product is a stealth-mode SaaS in the marketing-automation arena (earlier described here). Three technical founders, seed-stage runway, zero legacy. Our north star is simple: find out which workflow solves the most painful content-ops bottleneck for mid-size teams.
- Unknowns everywhere. Market, pricing model, even the core utility metric are unproven.
- Low switching cost. If we fumble, prospects churn to the next alpha app.
- Technical horsepower on tap. The founders can code a new feature before lunch.
How we run user research
We start in FigJam, mapping hypotheses on virtual index cards. Once a flow stabilises we feed the diagram into ChatGPT:
"Generate a minimal Next.js interface with a left sidebar, editable stages in the main panel, and placeholder modals for configuration."
Within minutes we have a testable scaffold. We bolt in fake data, invite five design partners, and record screen-shares. Research operations here is lightweight but deliberate: a shared Calendly for sessions, a single GDPR-ready NDA template, and a centrally labelled Figjam board for synthesis.
Why the light touch? Because every extra hour spent polishing mocks is an hour we postpone the only metric that matters right now-validated learning. In this context speed is design quality; insights trump pixel-perfection, and ReOps' job is to keep the user-research treadmill greased.
2. Growth-Stage Web3 Investment Platform (Case Study)
The second product is a consumer investment dashboard (earlier described here) operating in the web3 space. The domain is crowded; competitors already define most interaction patterns. Users connect wallets, view portfolio charts, and can trigger trades that move real assets.
- Financial blast radius. A mislabeled button could wipe holdings or invite regulatory heat.
- Rigid mental models. Traders expect conventions forged by mainstream brokerages.
- Multi-disciplinary governance. Legal, security, and customer support sign off on every public release.
How we run user research
Here we still lean on AI but plug it into a classic research operations pipeline:
- Expert and user interviews scoped with legal oversight.
- Low-fidelity wireframes are pressure-tested for compliance.
- High-fidelity UI built in the audited design system.
- Incremental feature rollout behind flags-3 % of traffic at first, then 20 %, then 100 %.
ReOps handles participant incentive budgets, keeps consent forms updated as crypto regulations evolve, and manages a secure repository where recordings auto-transcribe and index for search. Design operations owns the playbook; research operations keeps the playbook running.
Why the extra ceremony? Because the cost of a UX slip is not a bounced onboarding-it is a potential lawsuit. In growth-stage fintech, polish isn't vanity; it is a risk-mitigation strategy.
Lessons from IBM's ReOps Scale-Up
The IBM design research team famously ballooned from roughly 15 people to more than 100 in a single year. According to internal talks and public write-ups, they avoided chaos by building an eight-pillar framework that covers everything from participant recruitment to knowledge management. These pillars-environment, scope, people, organisational context, recruitment & admin, data & knowledge management, governance, tools & infrastructure-form a checklist any company can borrow. condens.io
The lesson is clear: as teams scale, repeatability beats heroics. You cannot rely on one staff researcher's Swiss-army skills; you rely on well-oiled research operations that live inside the broader design-operations remit.
A Personal Checklist for Choosing ReOps Rigor
My own decision matrix-evolved through projects large and small-boils down to three questions:
- Is the value proposition proven?
No. Optimise for discovery; keep research ops light.
Yes. Optimise for reliability; tighten processes. - What is the cost of a UX or research misstep?
Minor annoyance. Learn in production.
Financial or legal impact. Validate in a controlled sandbox. - How volatile are specs?
Weekly pivots. Extensive documentation rots-skip it.
Quarterly roadmaps. Document everything; future you will need the trail.
These questions decide whether I spin up a scrappy Calendly + Gmeet workflow or reach for elaborate panels, secure data rooms, and automated knowledge bases.
Why Technical Founders Still Need Research Ops
A quick detour: both of my current products involve founders who can code circles around me. Does that reduce the need for research operations? In practice, no. Technical founders often prefer code over coordination; they can recruit users, schedule tests, and tag transcriptions, but doing so steals hours from architecture and performance tasks only they can solve.
By embedding research operations inside design operations, we let the founders keep shipping while guaranteeing that every sprint rides on fresh evidence. It also demystifies the process for junior designers: they can observe moderated sessions, then step into facilitation roles with guardrails already in place.
Closing the Circle: Research Ops → Design Ops → Product Ops
Returning to the hierarchy, here's why it matters:
- Research operations ensures user research happens ethically, efficiently, and at the right cadence.
- Design operations absorbs those insights, leads UX, keeps the component library healthy, and aligns cross-functional rituals so decisions flow.
- Product operations connects those design outputs to roadmap governance, OKRs, Software Teams, and ultimately business impact.
Neglect any layer and the stack wobbles. Over-engineer a study with fourteen tasks and you burn the sprint budget. Under-engineer participant screening and you base strategy on the wrong audience. Both scenarios are symptoms of weak research operations-and by extension, weak design operations.
Final Thoughts
I skipped that original Design Researcher role because I feared the lifestyle, yet the questions it raised have steered every project since. Whether I am fine-tuning a bleeding-edge marketing SaaS or hardening a web3 investment platform, I start by asking:
- What does success look like for user research here?
- What shape must research operations take to achieve it?
- How does that fit inside our design-operations cadence?
Answer honestly, invest in the right systems, and even a three-person start-up can run research like IBM-scaled appropriately. Ignore the questions, and you will spend the same budget fixing avoidable blind spots later.
So yes: Research Ops is part of Design Ops. Knowing that is not just tidy taxonomy; it is the compass that keeps discovery and delivery moving in lock-step as products evolve.
I would love to hear how other teams fuse user research, research operations, and design operations, especially in AI-accelerated workflows. Ping me on LinkedIn or drop a comment-let's refine the playbook together.