Audience Dialogue

Coding without transcription

One of the problems of qualitative interviewing is the sheer amount of data it can generate. Since the average speed of speech in conversation is 150 to 200 words per minute, the number of words spoken in a one-hour interview is around 10,000. A fast typist, listening to a high-quality recording, will take 6 to 8 hours to transcribe this - longer still, if some speech is unclear. Transcription services are usually available in large cities, but typists can make strange mistakes when transcribing phrases and words that they are not familiar with.

The transcript of a one-hour interview, at 10,000 words, with normal paragraphing, will fill 30 to 40 typed pages. If you are doing semi-structured or in-depth interviews, saturation is normally reached at 20 to 30 interviews. So if you analyse transcripts of all of these, there will be about a thousand pages to code. This can be done manually, or using software such as NVivo and Atlas TI. Software enables more complex coding, but, because of that, often takes longer than manual coding.

If you are writing a doctoral thesis, or studying an area that's quite new to you, it's valuable to spend a lot of time transcribing and coding, but for less detailed analysis of qualitative "data" (i.e. text) this standard method is so time-consuming that either qualitative research is avoided, or the data is barely analysed at all.

But there is a simpler way. Over the last ten years or so, I've been developing a method that I call "live coding." It begins the same way as full coding: interviews are done, and recorded on audio or video media. The key to live coding is not transcribing everything - because, frankly, most in-depth interviews don't have very much in-depth interaction. From a typical one-hour interview, you are likely to get five minutes of really interesting and relevant material, and 55 minutes of introduction, repetition, indecision, and waffle. The rest of it is usually not worth coding, let alone transcribing. So the quest is how to find the gems among the dross. I've developed two methods, depending on the kind of material.

Method 1: summarizing on the fly

For this, you need a recording of the interview, and a reasonably fast typist. The machine on which you play back the recording needs a fairly accurate time display. Transcription machines used for audio cassettes do this quite well, but because tapes can stretch, the times can be out by up to a minute at the end of the tape. However as long as the machine is consistent, and the same machine is used, this isn't a major problem. The newer digital recorders - including Minidisc, DAT, MP3 files on CD or solid-state recorders - have completely accurate displays, but are often quite difficult to use, and easy to make mistakes with. Full-sized machines (about 45 cm wide, the size of a standard DVD player) are much easier to use, as they have larger and clearer displays.

A problem with normal transcription is that you are constantly going back a few seconds, to remember or confirm the words being spoken; this is much easier with the old cassette transcribers than with newer equipment (though dictation software, and foot-pedals are now available for Windows and Mac - see, for example). But with this method, there's no need to bother with going back.

The method is to play back the recording, type as fast as you can, and insert the time about once a minute. Whenever you heard something that sounds really interesting and relevant, don't try to write it in full, but insert a unique symbol. (We use the \ symbol because it's easily accessible on keyboards in English, doesn't require pressing the shift key, and is never used in normal text.) Whenever there's a passage that contains nothing of relevance, insert another symbol. (We use #.)

You can pause the machine while your typing catches up, but soon you will be able to do it in real time. In one hour of playback time, you'll be able to summarize a one-hour interview. It will look like a mess, but never mind that; it can easily be tidied up.

What you have just created is a contents listing for the recording, with the most relevant and interesting parts indicated with \ and the irrelevant parts with # (or other symbols). Depending on your typing speed, and whether you've paused to catch up, the contents listing is likely to be two or three pages long. You are now in a position to do a selective transcription - transcribing only the passages with a \ symbol. Because you have recorded the times about once a minute, you can go straight back to that minute and listen again, without wading through the irrelevant parts. Using this method - creating a contents listing, and transcribing only the few highly relevant passages - a typist who would otherwise take most of a day to transcribe an hour's interview can get 90% of the relevant content in two hours.

As for coding, some can be done from the contents listing, and the rest from the more detailed transcriptions.

Method 2: coding on the spot

This assumes that you have already developed a coding frame. If you don't have one - for example, if you are using a grounded theory approach - you'll need to make a first pass through some of the interviews to develop the coding frame. Method 1 can be used for this.

With this method, you divide the interview into one-minute segments. You play back the recording for exactly one minute at a time, then pause it, and summarize what has been said (or has happened) in that minute. This can also be used for content analysis of radio and TV and video programs. For video, transcribing only the words spoken is inadequate: you need to "transcribe" the image as well - and there are many different ways to do that, depending on the topic being studied.

This method also produces a contents listing, but because of the pauses after each minute, it's a more considered summary than with the on-the-fly approach of Method 1. Using this more detailed contents listing, you can code the content. Most of this coding is quite straightforward and unambiguous, but any passages that are doubtful can be listened to or viewed again, to clarify the coding.

With Method 2, if you have a detailed a priori coding frame, and are not looking for "other" instances, the coding frame can sometimes be laid out as a checklist. It's then only necessary to tick the codes that apply during each minute, with no need to write a summary.

And of course, the two methods can be mixed: the major difference between them is that with Method 2, you pause after each minute to summarize, while with Method 1 you just keep going.