I often see interview data treated as if one table will solve every problem. It will not. A table can help sort, compare, and track interview material, but the right setup depends on what the table needs to do.
That is the real question here. What kind of interview table helps with planning, and what kind helps with analysis?
I start with a simple rule. A table is a tool for order. It is not the interview itself. It turns scattered notes into something that can be checked, sorted, and compared.
In practice, I find three common table setups. Each one serves a different job. One tracks the interview as a unit. One supports coding. One helps compare themes across people.
The first setup is the interview log. This is the plainest table. One row usually means one interview. The columns hold basic facts like date, place, participant ID, language, recording status, and transcript status. This table is useful early in a project because it keeps the work visible.
Its strength is control. You can tell what has been completed and what still needs attention. Its weakness is that it does not show meaning. It records the interview, but not the ideas inside it.
The second setup is the coding table. This is more analytic. It breaks interview text into pieces and places them under codes or themes. A code is a short label for a recurring idea. In this setup, one row may hold a quotation, a line number, a code, and a short memo about why the passage matters.
This format works well when the goal is close reading. It makes the logic of interpretation more visible. The weakness is that it can become heavy fast. If every line gets its own row, the table grows awkward and hard to scan.
The third setup is the theme-by-participant matrix. This is the most useful table for comparison. Rows may list themes. Columns may list participants. The cells hold short summaries, not full transcripts. That makes it easier to see who said what, and where patterns repeat or split.
This is the setup I trust most for final sense-making. It is still selective, though. The table shows a distilled version of the data. It cannot carry the full tone of the interview. It also depends on the coder’s judgment, so the summary must be handled carefully.
A small example makes the difference clearer. Suppose I interview five graduate students about database search habits. An interview log would show that one session took place on March 4, with transcript status marked complete. A coding table might mark one passage as “search frustration.” A matrix might show that four of the five students mention the same problem in different ways.
That progression matters. The log tracks process. The coding table tracks meaning. The matrix tracks pattern.
I also think the weaknesses deserve plain words. Tables can flatten voice. A short cell cannot carry hesitation, irony, or the long pause before a hard answer. Tables can also make analysis look cleaner than it is. Once a response is reduced to a phrase, the messy part of interpretation can disappear from view.
There is another risk. A table can tempt the researcher to force answers into fixed boxes too early. That is especially true when the table is built before the interviews are fully read. A good table should support thinking, not replace it.
So I separate the methods by purpose. If the goal is to manage a study, the interview log is enough. If the goal is to mark meaning inside the text, the coding table fits better. If the goal is to compare across cases, the matrix does the most work.
I also care about when a table should not be used. Not every interview question belongs in a rigid grid. If the material is deeply narrative, relational, or shaped by storytelling, a table may hide the point of the response. In those cases, the table should stay modest and support the analysis rather than dominate it.
That is why I prefer to think of table setup as a sequence, not a single choice. The same project may move from log to code to matrix. Each step asks for a different kind of attention. The first asks, what do I have? The second asks, what does it mean? The third asks, what repeats across people?
For readers working with interview data, the main lesson is simple. Pick the table to match the task. Do not ask one table to do all the work. A clean setup at the start saves confusion later, and a careful setup at the end keeps the interpretation honest.
I can now separate the main table methods used with interview data, explain what each one is for, and see where each one falls short. That is enough to build a clearer working structure before the analysis starts.
The Source List fits that same habit of care: one digital source worth knowing, one search tip, and one honest limitation.