Discourse Analysis in UX Research

WHY IT EXISTS: Users do not simply report facts when they speak or write. They perform identity, manage social face, and negotiate meaning through the very structure of their language. Discourse analysis exists because surface-level content misses the invisible architecture of assumptions, power, and context embedded in how things are said. It was developed to examine not just what is communicated, but how communication itself constructs reality.

THE MENTAL MODEL: Think of language as compiled code. The literal words are the binary, but the compiler flags, memory layout, and runtime context reveal the actual execution path. Discourse analysis reads the source and the compiler logs simultaneously. It assumes that every pause, pronoun choice, repetition, and shift in register is a meaningful signal. The analyst does not ask what the user prefers; they ask how the user is positioning themselves, the product, and the interviewer within a shared social reality.

HOW IT WORKS: The approach begins by collecting naturally occurring language, such as interview transcripts, support tickets, or session recordings. The analyst then examines structural patterns across multiple levels. Turn-taking reveals power dynamics. Word choice exposes framing devices. Pronoun shifts indicate identity work. Overlapping speech or hedging marks moments of uncertainty or politeness. Rather than counting themes, the analyst traces how specific linguistic devices accomplish social actions like blaming, justifying, or recruiting alliance. The method is iterative and interpretive, moving between fine-grained line-by-line reading and broader pattern recognition across the corpus.

WHEN TO USE IT: Use discourse analysis when you need to understand the unstated rules governing user behavior. It is essential for studying how users talk about sensitive topics like money, health, or failure. It also surfaces how organizational language shapes internal tool adoption, or how support conversations silently encode customer hierarchies. If your research question is about meaning-making rather than frequency, this is the right lens.

WHEN NOT TO USE IT: Do not use it when you need predictive statistical generalization or rapid thematic sorting for a feature backlog. It is slow, requires specialized training, and produces interpretive rather than probabilistic claims. It also fails if you treat quotes as transparent windows into user intent rather than constructed social performances.

ONE CANONICAL EXAMPLE: Consider analyzing customer support transcripts for a software platform. A thematic coder might note that users frequently mention confusion about billing. A discourse analyst would notice that users switch from we to I when describing payment failures, suggesting a shift from organizational to personal accountability. They would track how agents use conditional politeness, and how the turn structure places the burden of proof on the customer. These patterns reveal that the billing confusion is not merely a UI problem but a socially fraught identity negotiation, pointing to entirely different design interventions.