Abductive Coding: Follow a Surprise to a Better Explanation

Abductive coding starts when a finding does not fit what you thought would happen. Mark the odd line. Write down your prior view. Then ask what else could explain what you found.

Suppose a library adds a fast book locker. Some people still queue at the desk. A code such as “chooses staff desk” helps you find those lines. It does not tell you why. Do they seek a chat, struggle with the screen, or need help with a hard task?

Atlas can help you compare texts you add and open cited lines. You must decide what surprised you. You must also read each full case before you trust an account.

What abductive coding does

Abduction means finding a likely cause for a surprise. The surprise has to clash with a prior view of how people or events work. If you had no such view, the line may be new to you, but it has yet to test an account.

Timmermans and Tavory link odd findings to new theory. They ask researchers to revisit a case and view it in a new way. A desk visit, for example, may be about care as well as book pickup.

Codes help you find and group text. One code can mark an odd line. Another can mark the old theory at work. You make the claim only after you read the full cases and weigh other views.

Vila-Henninger and coauthors show one way to do this. Their team began with broad codes from theory. They marked the cases those codes could not explain, then read the data again.

Why a case looks surprising

That is one way to code. Van Hulst and Visser show why the work often loops. A new field visit may change an old idea. Doubt may lead you back to a book, a person, or an earlier note.

Write down the prior view. “People used the desk” is a fact to check. “We thought speed would move patrons to the locker, yet some came back to the desk” names the clash.

A code is a retrieval aid

A code helps you find lines again. “Staff contact” can tag each call or desk visit. It cannot tell you if the visit grew from trust, habit, a hard task, or trouble with the locker.

Read the text around the line. Then look at other cases. Save the full quote, its place in the case, and why it stood out. A vivid line can seem to prove too much when torn from its setting.

Surprise depends on what you expected

You bring past work and daily beliefs to a study. Van Hulst and Visser explain that those beliefs help you see a surprise. A line looks odd because it clashes with what you had in mind.

Name your first view before you change it. If you thought ease meant less staff time, a patron who seeks a chat may seem odd. If you thought people prized being known, the same visit may fit.

Your memo should show which view was in use when the line first looked odd. This lets readers see your role in the claim. The surprise lives in the clash between text and prior view.

How it differs from other coding

The three modes start with different questions. Deduction asks whether the data fit a prior claim. Induction builds a pattern from the data. Abduction asks what could explain a finding that the prior claim cannot.

CASRAI's reasoning comparison is useful at this broad level. Research projects can move among these modes. A coding pass need not fit one label forever.

The published diagram below sketches how theory and data can play different starting roles. The arrows are a simple starting point. Real studies move back and forth. In abductive coding, you must name the surprise and compare accounts; the image does not show that work.

Deductive coding starts with categories

A team may derive “speed,” “accessibility,” and “staff support” from a service model before reading interviews. It can apply those categories to passages and ask how well the model fits.

When a case strains the model, keep that passage visible. Do not force it into the nearest category merely to preserve a tidy codebook. Vila-Henninger and colleagues used theory-informed codes as a starting point for noticing what needed a new explanation.

Inductive coding starts close to data

A researcher can also label repeated phrases and actions without first assigning them to a theory. “Waits to ask about returns” may become a useful code after several interviews.

Inductive thematic analysis develops patterns in a dataset. Abduction may use those data-led codes, but its defining question is narrower: what explains an observation that conflicts with a stated expectation?

The Delve practitioner guide describes abductive coding as moving between theory and data. That movement is helpful, but mixing prepared and new codes alone does not show why a particular explanation was proposed or challenged.

Abductive coding revises an account

An abductive memo should show at least four things: the expectation, the surprising passage, plausible alternatives, and evidence that could change the researcher's view.

This differs from simply adding an “other” code. The work is to re-examine the case and its conceptual frame. Timmermans and Tavory call attention to alternative casing: a new way to understand what sort of case the researcher is seeing.

In the library example, “failure of the locker” and “value of a social encounter” frame the same desk visit differently. Each frame directs the researcher toward different passages and follow-up questions.

Code a surprise in five moves

These moves give you a way to organize the work. You can return to any earlier move. In the van Hulst and Visser paper, a later field visit can send a team back to its first idea.

State the prior account

Write one sentence about what you thought would happen and why. In this example: “A faster pickup route should reduce desk visits among regular users.” Name the source of the expectation, whether a theory, prior study, or service assumption.

Keep that sentence in the memo. If you change it later, retain the first version. A visible revision shows how evidence affected the claim and guards against writing the original theory as though it had predicted the result all along.

Mark the awkward passage

Select the full passage that challenges the account. Include enough context to know who spoke, what happened, and what question prompted the response. Give it a descriptive code, such as “returns to staff desk.”

Search for other lines about that action and for cases that used the locker as expected. One striking line gives you a question to check across cases. Vila-Henninger and colleagues show how anomaly codes can prompt a fresh reading of data.

Propose more than one account

Ask what else might produce the observation. Staff interaction could provide recognition. The locker might be hard to use. A patron may have a task that the locker cannot handle.

Write each explanation so it predicts a different kind of supporting or weakening evidence. “Patrons like staff” is too broad. “Regular patrons seek staff recognition even when pickup is simple and the locker works” can be checked against cases.

Revisit cases and theory

Read the source passage in its full interview, then inspect relevant passages across other cases. Look for cases that strain each rival explanation. Return to the theory that made the observation surprising.

Sometimes the case is better understood through another concept. In this example, a service-design frame focused only on transaction speed may miss trust or the public role of a library. Timmermans and Tavory describe this kind of conceptual recasing as part of theory construction.

Record a provisional inference

Write what the current evidence supports, what it fails to explain, and what to examine next. “Recognition may matter for some regular visitors” is appropriately bounded. “People prefer a human service” overstates a small, selected set of passages.

Record the date, codebook version, cases reviewed, excluded or missing cases, and next question. The memo is a map of reasoning. It is not a certificate that one account is true.

A worked library-service example

The following people, interviews, and quotations are fictional teaching material. They are not a study, a product test, or evidence about real libraries.

Imagine a researcher interviewing people after a library introduces a pickup locker. A simple service model predicts that regular patrons will use the faster locker for routine holds. The researcher notices an unexpected return to the staffed desk.

The table keeps each invented excerpt beside an initial code and a question for analysis. It does not turn a sentence into a finding on its own.

Table 1: The first and fourth lines give the relational account a reason to be considered. The second favors a usability account. The third makes a task-complexity account plausible. None is enough to settle the question.

The researcher should retrieve the full fictional accounts. Did Maya help select books during the same visit? Could the first patron use the locker independently? Did the last speaker visit even before lockers arrived? Those details change the interpretation.

What the first codebook missed

An initial codebook might include “fast pickup,” “successful pickup,” and “technical barrier.” It could count the first quote as another desk transaction. That loses the speaker's reason for choosing the desk.

A new code such as “known staff relationship” makes those passages easier to find. It remains a descriptive tool. The explanation develops only after the researcher checks whether recognition appears across cases and whether counterexamples exist.

In one published approach, Vila-Henninger and colleagues combine theory-informed and data-driven codes to locate connections worth reanalysis. Their “code equations” are a method-specific way to organize intersections. They do not make an explanation valid by themselves.

Change the case, then check it

The case could be framed as “why a technology failed to displace a desk.” That frame steers attention to interface friction. Another frame is “what kinds of help a public service makes available.” It brings recognition and tailored advice into view.

Neither frame should be chosen because it sounds compelling. Inspect passages that each frame explains badly. Alternative casing in Timmermans and Tavory's account is useful because changing the question changes which evidence matters.

In a live project, obtain consent and follow your data plan before handling real interviews. The example here is only a way to practice the reasoning.

Compare rival explanations

A good abductive account has to face rivals. For the made-up library cases, write each claim and what could weaken it. Read the text to judge the fit. A score would hide the reasons.

The van Hulst and Visser discussion treats doubt as a useful cue. You can keep more than one view alive while you seek more text.

Recognition and trust

One explanation is that some visitors value being known by staff. The first and fourth fictional passages support it. Yet the first speaker also needs tailored book advice, so the line does not isolate recognition from practical help.

Look for routine pickups where the locker works, the request is simple, and the visitor still chooses the desk. Ask about previous relationships with staff. A regular who prefers the locker in the same circumstances would narrow this account.

Interface access

Another explanation is that the locker design creates avoidable friction. The second passage supports it. Yet a visitor who greets staff on a no-pickup day does not fit a purely interface-based explanation.

Check whether the screen, code delivery, physical access, or instructions caused trouble. Compare people who encountered the same barrier with those who did not. An accessibility problem may coexist with a desire for conversation.

Task complexity

A third explanation is that the desk handles requests the locker cannot. The large-print example supports it. But it cannot explain every visit if some people seek staff when no special request exists.

Review the reason for each visit before classifying it. A simple pickup, an account problem, and a reference question are different tasks. A single “desk use” count would conceal those differences.

After this comparison, the researcher could write: “In these invented accounts, desk use may reflect several mechanisms, including recognition, access barriers, and task-specific help.” That statement is weaker than a universal theory, but it fits the evidence better.

The next sample should be chosen to distinguish the accounts. Seek a routine locker pickup by a person with a long staff relationship, or a visit after the interface barrier is fixed. A later case can still reveal an explanation the current list missed.

Keep the evidence trail in Atlas

Atlas can support a narrow part of this workflow: comparing supplied project material while retaining a path back to each passage. Its grounded question flow can return source citations, but the researcher still has to inspect the cited text.

Start with the relevant, permitted transcripts or documents in one project. In chat, type @ to select the source you want Atlas to consider. A specific mention is useful when the question concerns one interview rather than the whole project.

Ask a focused question such as: “Across these selected interviews, which passages support recognition, interface friction, or task-specific help as reasons for desk visits? Put contrary passages beside each account and cite each source.”

Open each citation. Check the speaker, nearby context, and whether the line actually bears on the proposed account. If the answer combines sources, ask for the contribution from each source separately.

Atlas can organize a multi-source comparison by selected source and citation. This helps organize a read; it does not establish that every relevant passage was retrieved. For broader guidance about where AI helps and where judgment remains with the researcher, see qualitative data analysis with AI.

Save a note with four fields: the prior expectation, the surprising passage, the rival accounts, and the next evidence to seek. Include the citations you verified and name any material you still need to read. A saved note preserves the researcher's decision path.

For the fictional example, the memo might read: “Locker speed was expected to reduce desk visits. One account mentions a known staff member; another reports a timed-out screen. Recognition and interface access remain live explanations. Review routine pickups after an interface fix.”

The researcher decides which sources belong in the comparison, whether the quotations are representative, and how the interpretation changes the theoretical account. Atlas cannot certify an abductive inference.

Keep the original passage in view

A concise answer is useful for locating candidate evidence. It can also omit a qualification. Always open the citation and read beyond the quoted line before moving the passage into a memo.

If the cited source is wrong, name the intended source and ask again. If a citation is absent, do not treat the answer as traceable evidence. The researcher's checked note should distinguish retrieved suggestions from verified passages.

This is especially important when the same phrase has different meanings across cases. “I like to talk” may refer to friendship, a service question, or frustration with a kiosk. The full account settles how much weight the line can bear.

Avoid weak abductive claims

Abduction is useful because it keeps an explanation open to revision. Its weakness appears when a pleasing story is treated as proven merely because it fits a surprising quote.

Do not choose only the most vivid anomaly. Keep the ordinary cases, those that support the first theory, and lines that strain a new one. Van Hulst and Visser treat surprise and doubt as reasons to keep reading and thinking.

Watch for three specific errors:

• A missing expectation. State what the prior account predicted; otherwise “surprising” becomes a label added after the fact.
• One favored explanation. List plausible rivals and describe what each fails to explain.
• A code treated as proof. A category gathers material. A claim needs context, comparison, and a stated limit.

Write down your own role in the study. Which source made one account seem likely? Did an interview question steer an answer? What new case would make you change your mind? This memo shows how your view grew.

If you need to compare codes and cases through many rounds, see the constant comparative method. Abductive coding uses such checks to explain a stated surprise.

Do not describe a chosen account as a causal finding without a design that supports that claim. Qualitative passages can make an explanation plausible and sharpen a question for later work. They do not, by themselves, establish that one factor caused the observed behavior.

The method does not require a specific coding program. Timmermans and Tavory's theory-construction account concerns how researchers reason. Their later book on qualitative data analysis also treats coding as part of the wider task of finding and explaining surprise. A paper notebook, codebook, or source-linked workspace can support that task.

Your next analytic move

Choose one observation that your current account handles poorly. Write the prior expectation in a sentence, save the full source passage, and propose at least two explanations that make different predictions.

Then read a case that could weaken your favorite account. Update the memo with what changed, which passages remain unexplained, and the next case or question that would help. This gives the next coding pass a purpose.

An abductive conclusion can be valuable while it remains provisional. Its strength comes from showing readers how the researcher moved between theory and evidence, including where the preferred account did not fit.