Introduction to Thinking Aloud Testing

The thinking aloud method is one of the most popular user research methods. In fact some people actually refer to tests using the thinking aloud method every time they talk about usability testing. The method aims to show, how people interact with products and why they use products in the exact way they do. The main assumption behind the method is that people are able to give an accurate description and explanation of their actions when they speak about them.

History and background

Thinking aloud originated from the introspection method used in early cognitive psychology. The main idea behind this method is that events that take place internally (in the consciousness of people) can be more or less observed in the outside world. Consequently the research data used are events that are not directly visible or measurable.


In fact the relevant data is only visible to one observer: the person leading the thought process. In order for researchers to be able to gather the needed data, the examined person needs to provide details about their thoughts. This fact poses a major problem: it is impossible to be absolutely certain the data is unbiased as it is always self-reported. To avoid speculation, interpretation and biased data as much as possible, the subjects are usually instructed to only verbalize directly what they are thinking. These verbal protocols–in the form of audio/video recordings, transcripts or notes are then treated as data and objectively interpreted.

Possible Problems

Thinking aloud sessions are oftentimes the tool of choice when doing usability tests as they require little more than representative users, a representative task and recording equipment. A very simplified plan for doing thinking aloud sessions (as proposed by Nielsen and Norman) is: recruit users > give them a representative task > listen closely/record/take notes.



As with every method there are some problems you can run into when doing thinking aloud tests:

• The act of thinking aloud might change or at least influence the way subjects think. User might start behaving differently because they are made aware of what they are doing and thinking


• Protocols easily start becoming incomplete. Users quickly tend to run into trouble trying to keep thinking and verbalizing in sync. Usually people think and act faster than they can speak which leads to holes in the protocol.


• Depending on the task people can have problems with verbalizing what they’re doing. If processes are not easily verbalized users run into trouble as verbalizing costs time as well as working memory capacity and can also interrupt the investigated process.

Running a thinking aloud analysis

The first step in doing user research using thinking aloud is obtaining the protocols. This is most commonly done by either audio or video recordings of the users’ actions and statements. Once the appropriate users are found and the representative tasks they are supposed to perform are defined, there are a few other guidelines to be considered. While the setting should of course make the subjects feel at ease, the focus should be on the task. One strategy to make people feel more at ease is to emphasize that you’re solely interested in the way they solve problems and not in their hidden emotions or thoughts.


The instructions given to the users should inform them that their task is to solve the problem at hand and verbalize their thought process as detailed as possible while doing so. Also the experimenter should interfere as little as possible to avoid influencing this thought process. However, when the examined person stops verbalizing their thoughts, the experimenter should interrupt them and instruct them to keep talking.


When recording the verbalized thoughts and statements, you should always double check your equipment. Check if it works flawlessly before you start you sessions and keep track of the available memory space.

Transcribing and protocols

When using the thinking aloud method in psychology, usually every little thing that happens is transcribed. In engineering or usability testing it’s sometimes sufficient to only transcribe the first few sessions completely and then transcribe more selectively. You could for example only take note of new statements. However–if available time and resources allow for it–it never hurts to gather as much data as possible by actually transcribing every protocol.


Things that should be marked when transcribing thinking aloud sessions are long pauses, silences or when the subject gets stuck on their task. Should the person transcribing the audio/video files be unable to understand what the user said, they should take note of this fact instead of trying to fill the gap with their own ideas or interpretations. You should also never make any improvements or corrections to what the user said.


Another problem that often arises is the question whether to use punctuation or not. As punctuation in itself can be a form of interpretation, a certain degree of caution is advisable. Once you put down a question mark in the transcript, people who later interpret the transcript without listening to the original files will of course assume that the subject questions the previous sentence.

Analyzing transcripts

When analyzing thinking aloud transcripts you need some kind of guide on how to categorize statements. Usually coding schemes are written to define which statements should be put into which categories. A simpler and maybe more intuitive method–especially in the context of UX/usability–is defining a number of tags to be used for certain statements. E.g. “positive statement” “negative statement” “trouble while logging in”…



When analyzing transcripts it’s especially important to note when participants give a reason as to why they did something or how they expect things to be. These comments can help product designers to tailor their product exactly to the needs of their users. That way your protocols can show which mental models participants use to solve problems.



Once you identified the models your users apply when executing tasks with your product, you can compare them to your idea of how the product should be used. Differences in the anticipated and actual user behaviour can be analyzed and used to increase the user-centricity of your products. This means that you no longer have to anticipate user behaviour but can predict it in a fairly accurate way.


If you use insights from multiple protocols, the transcripts have to be compared. Statements participants made concerning certain actions should be clustered by emerging themes (e.g. unclear navigation, trouble locating the contact form…). Statements can be further further analyzed and grouped according to their frequency and the gravity of the described problem. This grouping or tagging helps to evaluate which problems arise a lot and which elements of the product need improvement, it also informs developers’ decisions so they can decide more confidently which issues are the most time-sensitive and how to prioritize.




You want to transcribe, tag and analyze thinking aloud protocols but can’t the right tools to support your research? No worries, we’re working on a solution! Get more information and updates here.

If you want to share your thoughts feel free to leave a comment or hit us up on twitter @usertimesHQ.