The research operating system I built by doing the work.
This isn't a methods textbook. It's the system I've assembled across 6+ years, 5 companies, and 3 countries — from running sentiment analysis in R at Cognizant to redesigning kiosk journeys at Verizon to directing mixed-methods evaluations at Microsoft. Every framework here has been tested on real stakeholders, with real constraints, under real deadlines.
01 — Framing the Brief
Most research goes wrong before the first interview.
The brief usually arrives as a solution disguised as a question. "Why aren't agents using the feature?" already assumes the problem is with the agents. "Test whether users prefer layout A or B" skips past whether either layout solves the right problem.
Before I design a study, I rewrite the brief. Not to be contrarian — but because a badly framed question produces confidently wrong answers. The reframe is often the most valuable thing I deliver.
A reframe in practice
The team asked: "Why aren't agents using the churn nudge?" I shifted it to: "What's happening in the moment the nudge appears?" That one change turned a training problem into a design problem — and changed the entire study.
1.
Separate the business objective from the research question
The business wants to increase retention. The research question is about what happens during a live call when the nudge surfaces. These are connected but not the same question — and conflating them leads to research that validates assumptions instead of testing them.
2.
Identify what would change the team's decision
If the answer won't change what the team builds, the study isn't worth running. I ask: "What would you do differently if the answer surprises you?" If they can't answer, the research objective isn't clear enough yet.
3.
Write the debrief headline before you start
I draft what the summary slide might say — not to predict findings, but to pressure-test whether the study design can actually produce that kind of answer. If the methods don't match the headline format, something's misaligned.
02 — Designing the Study
Picking methods that match the question, not the timeline.
Method choice is a series of trade-offs. Think-aloud surfaces real-time reasoning but disrupts natural behaviour. Surveys scale but flatten nuance. Diary studies capture context over time but depend on participant commitment. I don't have a default method — I have a decision framework.
🎙️
Semi-Structured Interviews
My most-used method. I keep a guide but treat it as a floor, not a ceiling. Some of my most consequential findings — like agents building their own mental models of churn — came from threads I hadn't planned for.
At Verizon, a semi-structured format let agents describe their own informal churn signals — something a rigid script would have cut off entirely.
🧠
Think-Aloud Walkthroughs
When I need to understand real-time decision-making under pressure — not what people remember doing, but what they actually do. I pair this with scenario recreations, not live systems, to control for variables without losing ecological validity.
At Verizon, retrospective recall would have given me agents' rationalised version of their behaviour. Think-aloud gave me the real version.
📊
Survey Design & Statistical Analysis
I design surveys in Qualtrics with programmed skip logic, randomisation, and attention checks. Analysis in SPSS or R — regression, factor analysis, significance testing. I don't just collect data; I design instruments that produce analysable data.
At Cognizant, I ran sentiment and behavioural analysis in R for U.S. healthcare B2B providers, combining qualitative coding with statistical patterns.
👁️
Contextual Observation
Some things only make sense when you're in the room. The dual-monitor setup, the ambient noise, the queue pressure — at Verizon, these weren't background details. They were part of the finding. I build observation into studies where environment shapes behaviour.
A remote session would have removed the contextual layer that made the timing problem visible. The environment was data.
On mixed methods: I default to mixed methods not because it sounds rigorous, but because qual and quant answer fundamentally different questions. Analytics tell you what's happening; interviews tell you why. At Microsoft, integrating bi-weekly Clarity telemetry (session recordings, heatmaps, funnel data) with qualitative interviews produced a 22% adoption increase that neither method alone would have delivered.
03 — Running Fieldwork
The logistics are part of the research.
Scheduling 45-minute sessions with call-centre agents across active shifts. Getting executive sign-off for on-site access. Recruiting across tenure levels, channels, and shift patterns. These aren't administrative overhead — they shape who you talk to, what they tell you, and whether they trust you enough to be honest.
Customer support agents are evaluated on metrics. Being observed by a researcher can feel like an audit. I spend the first minutes of every session making clear: I'm here to understand the tool, not to evaluate you. Most people open up once they believe that. At I-PAC, I worked with diverse rural user segments who had never participated in research — trust-building was the entire first phase.
Recruitment
Getting the right people, not the available ones
I recruit for variation, not volume. At Verizon, I filtered for 6+ months tenure because newer agents hadn't formed stable habits around the feature. Settled behaviour was the data — not first impressions. I also recruit across channels, roles, and seniority to prevent skewing findings toward one team's culture.
Moderation
Listening for what people almost don't say
The most useful thing a participant says is usually the one they almost hold back. I watch for hesitation, self-correction, and qualifiers ("I mean, I know I'm supposed to use it, but..."). Those are the seams where the real answer lives. I probe gently and let silence do the work.
04 — Synthesis & Analysis
Pattern recognition is a skill, not a step.
Synthesis is where most research either becomes actionable or becomes a report nobody reads. I don't treat it as the thing that happens after fieldwork — I start forming patterns during sessions and pressure-test them in the remaining interviews.
Qualitative
Affinity mapping & thematic coding
I code transcripts by behaviour, not by question. Affinity mapping in Miro or FigJam — physical when possible, digital when remote. I use Dovetail for tagging and pattern retrieval across projects. The framework survives messy data because it's built around what participants did, not what I expected them to say.
Quantitative
Statistical analysis that answers the actual question
SPSS for survey analysis — significance testing, cross-tabs, regression. R for behavioural and sentiment analysis, especially when the data is unstructured. SQL for pulling and shaping telemetry and product data. I pair these with qual findings, not as validation, but as a different lens on the same phenomenon.
Triangulation
Making qual and quant argue with each other
At Thence, I diagnosed a 68% product page exit rate by triangulating user interviews with Hotjar behavioural analytics. The numbers said people were leaving. The interviews said they couldn't find the information they needed. Neither alone would have been enough to persuade the team to redesign the entire product display page.
✦AI in my synthesis workflow: I use ChatGPT and Claude for desk research and rapid literature review. NotebookLM for navigating large qualitative datasets. Dovetail's AI tagging for pattern surfacing across sessions. Custom GPTs I've built for research operations. I've also created chatbots and research agents for workflow automation. AI scales the search — the interpretation stays human.
05 — Tools I Work With
Not a list of logos. What I actually use each one for.
Qualtrics
Survey design with programmed skip logic, randomisation, piping, attention checks. End-to-end from instrument design to distribution to data export.
SPSS
Survey analysis — cross-tabulation, regression, factor analysis, significance testing. My go-to for structured quantitative data.
R
Behavioural and sentiment analysis for unstructured or semi-structured data. Used extensively at Cognizant for healthcare B2B providers.
SQL
Pulling, shaping, and querying product telemetry and user behaviour data. Connecting research questions to existing data infrastructure.
Dovetail
Qualitative data repository — tagging, pattern retrieval, AI-assisted highlights across projects. Keeps insights findable after the study ends.
Microsoft Clarity
Session recordings, heatmaps, funnel analysis. At Microsoft, bi-weekly Clarity reviews fed directly into qualitative interview planning.
Figma / Miro / FigJam
Wireframing for research stimuli, affinity mapping, journey mapping, service blueprints. I create low-fi wireframes to bridge research and design.
Google Analytics / Hotjar
Behavioural analytics for web products — conversion funnels, click patterns, scroll depth. Paired with qual at Thence to diagnose a 68% exit rate.
AI Suite
ChatGPT + Claude for desk research. NotebookLM for large dataset navigation. Custom GPTs and research agents I've built for operations and synthesis.
06 — Socialising Findings
The deck is never the deliverable. The decision is.
Most research dies in a slide deck. The findings are technically correct, the methodology is sound, and nobody acts on any of it. I've learned — sometimes the hard way — that insight socialization is its own discipline, separate from analysis and equally hard.
What I optimise for
Not "did they read the report?" but "did they change what they were going to build?"
Audience
Different stakeholders need different versions
The product lead wants implications for the roadmap. Engineering wants specificity. The VP wants a one-line summary and a confidence level. I prepare all three versions — not because I love making decks, but because the same finding lands differently depending on who's hearing it and what they're deciding.
Format
Match the format to the decision context
Sometimes the right deliverable is a 40-slide deck. Sometimes it's a 2-minute Slack summary that reaches the right person at the right moment. At Microsoft, structured stakeholder briefings aligned research with global KPIs. At I-PAC, the team needed research findings translated into action steps that non-researchers could execute immediately in the field.
Impact
The most important outcome is sometimes "don't build that"
At Verizon, the biggest impact wasn't a redesign — it was convincing the team to pause development until the underlying problem was understood. The research prevented investment in a feature iteration that would have built on a flawed foundation. That decision was a research outcome.
07 — Operating Principles
The things I've learned that no methods course teaches.
🔍
Low adoption is a research brief, not a verdict
When a feature isn't being used, the instinct is to fix the user. I've learned to investigate the tool first. People are usually making rational decisions — they just look irrational from the outside.
🧭
Usage data alone will never tell you why
Analytics will show you low engagement. It won't show you the moment-by-moment decision a person made in real time. The qualitative layer isn't a supplement — it's often the primary source of insight.
🤝
The participant probably already knows the answer
Experienced agents at Verizon had built their own churn signals from thousands of calls. Developers at Principal already knew where their SDLC workflow broke. Expertise lives in the field — research makes it legible to the org.
📐
Rigor isn't about sample size
12 well-recruited, well-moderated sessions can produce more actionable insight than a 500-response survey with ambiguous questions. Rigor is about whether your method matches your question — not about how many data points you collected.
💬
Research that nobody acts on is noise
A beautifully analysed finding that sits in a Confluence page is worth zero. I measure my own work by whether it changed a decision, prevented a mistake, or opened a question the team hadn't considered.