My Master's thesis on industrial XR interaction rests on six expert interviews. The findings — what actually works when the user is wearing gloves, working in noise, and can't afford to be confused by the interface — live in the thesis case study. These notes are about something that turned out to matter longer: the interviewing techniques the study forced me to learn. I have used them in every discovery call, stakeholder interview, and user session since, and none of them require a thesis to practice. If you talk to experts for a living — and if you work in design, you do — they are worth stealing.

Earn the vocabulary before the first question

I recruited my participants at XR industry meetups — four lead UX designers, a research director, a software development engineer. But the meetups earned their time twice over, because before I asked anyone for an interview, they gave me a terminology review: the words practitioners actually use for displays, input techniques, and deployment problems.

That preparation changed the interviews themselves. Walk in with the wrong vocabulary and the expert spends the hour translating for you — politely, shallowly. Walk in with their words and they talk to you like a colleague. I now do the same thing before any stakeholder or domain-expert interview: find where the practitioners talk to each other — forums, meetups, internal Slack channels — and listen until I can ask questions in their language. The interview should never be the first time you hear the domain speak.

Don't accept the conclusion — ask for the incident

Experienced practitioners have answered the obvious questions many times before. Ask what input technique works in the field and you get a polished conclusion: speech is the most viable channel. True, and nearly useless — it is the same sentence you could pull from a vendor's slide deck.

The technique that unlocked the interviews was refusing to move on at the conclusion. Instead of "why do you think that?", which invites more theory, I asked for the incident: the last project where it played out, the specific site, what happened. That is where the real data lived — gloves that break touchscreens, machinery noise dictating microphone placement, technicians who worry how a headset looks in front of a client.

Stakeholders in product work answer in conclusions too ("our users won't adopt that"). The move is identical: ask for the last time it happened. Stories contain the reasons; opinions only contain the verdicts.

Write the limitation down the moment it bends the data

The study collected constraints the way fieldwork always does. COVID moved every interview to video, removing any chance of observing participants in their own environment. NDAs meant people could only describe projects that were already public. All six participants were Finnish, which makes cultural context a variable rather than a constant.

The habit I built — and kept — was logging each constraint at the moment it bent the data: noting mid-interview that an answer stopped at an NDA boundary, not reconstructing it weeks later for a limitations section. Then reporting those limitations as plainly as the findings. I do the same in research debriefs now, and it has a compounding effect: a caveat delivered with the claim buys credibility for everything else you say. A seam someone else discovers costs more than the seam itself.

Let the analysis tell you what the study was about

Grounded theory means the theory comes out of the data instead of being tested against it: transcribe, translate, open code, and group codes into concepts and categories through constant comparison — with the literature review done after the interviews, guided by what they surfaced.

That discipline paid for itself in one specific way. I went in expecting a study about input techniques. The coding kept producing a second center of gravity: technology acceptance. Technicians self-conscious about wearing a device in front of clients, the intimidation of carrying expensive hardware into a harsh environment, reporting burdens eating a quarter of a work shift. A hypothesis-driven study about gestures versus speech would never have gone looking for that — and it turned out to be the biggest barrier the interviews named.

The transferable technique is synthesis patience: don't sort the evidence into the boxes you brought with you. Budget real time to let the categories emerge, and only then check them against the canon. The finding that changes your roadmap is usually the one you didn't have a box for.

Sell small samples as a lens, not a proof

Six participants is a small sample, and no amount of careful coding changes that. What six deep interviews with the right experts can produce is a structured account of what practitioners have already paid to learn — the categories, the reasoning, the trade-offs. What it cannot produce is a prediction of what will work in any specific deployment.

Most product research runs on samples this size, so the framing matters beyond academia. I present qualitative work as a design lens: here is what to stress-test your decisions against, not here is what will happen. Oversell an n-of-6 and the first contradicting data point sinks the whole study; frame it honestly and it keeps informing decisions for years.

If you are about to interview experts

  • Learn the domain's language before the first interview, from places where practitioners talk to each other — not from the interview itself.
  • Ask for the last time, not the general case. Stories carry reasons; opinions carry verdicts.
  • When an answer stops at a boundary — NDA, politics, memory — write it down right then, and report it next to the finding it touched.
  • Keep your synthesis honest: let categories emerge from the material before you reach for the literature or your own expectations.
  • Offer small-sample findings as a lens to test decisions against, never as proof. The honesty is what makes them durable.