UX Researcher Interview Questions for AI Training Work

I look at whether there's already a concrete design or concept to react to. If there isn't, the work is generative: open-ended interviews or diary studies aimed at understanding the problem space before any solution exists. Once there's something concrete to test, like a prototype or an existing flow, the work shifts to evaluative methods that measure how well that specific solution performs against real tasks.

Qualitative methods answer why something happens and give me the context behind a behavior, which is what I need early or when the mechanism itself is unclear. Quantitative methods tell me how common a pattern is across a larger group, which matters once I already have a hypothesis and need to know its scale. On higher-stakes questions I run both: a qualitative round to surface the real issues, then a survey or analytics check to confirm how widespread they are.

I use a think-aloud protocol so I can hear the participant's reasoning as they move through the flow, since the reasoning matters as much as whether they reach the end. Beyond task success and time on task, I note every point of hesitation, backtracking, or misread label, since that's usually where the real design problem lives even in an otherwise successful session. I stay careful not to prompt or explain during the task, since even a small hint changes what the session measures.

I read through a handful of transcripts first without coding anything, to let recurring themes surface naturally rather than forcing the data into categories I expected going in. Then I build a codebook from what showed up and apply it consistently across the rest of the batch, revising it if a later transcript surfaces something the early pass missed.

UX research is about understanding user needs, behavior, and problems across the whole experience, while UI design is the specific visual and interaction layer someone builds to address those needs. In practice the boundary blurs on smaller teams, where a researcher's synthesis, like a recommended flow or hierarchy, starts to look like a design decision. I try to hand off findings framed as problems and constraints rather than finished layouts, so the actual design decision still belongs to the designer.

I check whether each finding traces back to something concrete, an observed behavior or a direct quote, rather than reading as a plausible-sounding generalization with nothing underneath it. I also check the framing of severity: real usability findings get prioritized by how many participants hit an issue and how badly it blocked them, rather than listed as a flat set of observations. A deck that states conclusions confidently but skips the evidence trail is the clearest sign it isn't reflecting a real study.

I'd present the specific behavioral evidence, how many users struggled and exactly where, rather than a general objection to the decision, since specific evidence is harder to dismiss than a vague concern. I'd also come with a concrete alternative so the finding reads as something the team can act on.

I'd look for proxy access first, like internal subject matter experts, existing support tickets, or forums where that audience already discusses their workflow, before falling back to a smaller recruited sample. Some imperfect real input is still far more reliable than designing purely from assumptions about a group I've never talked to.

I assumed users wanted more visible customization options in a settings flow, but interviews and testing showed the opposite: they wanted fewer, smarter defaults and felt overwhelmed by choice. I redesigned the recommendation around that finding instead of my original assumption, since the evidence was clear enough to override what I'd expected going in.

A synthesis summary claimed a consistent pattern across the participant group, but when I checked the coded transcripts, only two of eight participants had said anything close to that claim. I flagged the specific transcripts the claim was missing evidence from rather than just disagreeing with the conclusion, which made it easy for whoever wrote the summary to see exactly where the overreach happened and correct it.