Interface Design Tutorials and Notes

Think Aloud Protocol

What is Think Aloud?

During the course of a usability test, the test users are asked to verbalize their thoughts, feelings, and opinions while interacting with the system. It is very useful in capturing a wide range of cognitive activities. Two variations of thinking-aloud protocol technique are:

1. Critical response - This requires the user to be vocal only during the execution of certain predetermined subtasks.
2. Periodic report - This is used when the task is complex and makes it difficult for users to think aloud while performing the task at the same time. The user, therefore, verbalizes at predetermined intervals of time and describes what he/she is currently trying to achieve. The length of the interval depends upon the complexity of the task. This technique is very time consuming, so it is recommended for subdivisions of a task.

Why Use it?

Thinking aloud allows testers to understand how the user approaches the interface and what considerations the user keeps in mind when using the interface. If the user expresses that the sequence of steps dictated by the product to accomplish their task goal is different from what they expected, perhaps the interface is convoluted.

The terminology the user uses to express an idea or function should be incorporated into the product design or at least its documentation.

Participants Needed

Experts

One usability expert is required for the exercise.

users

A minimum of 4 users should be observed - the more users that can be observed, the better the results. Different Users will have different problems. After 6 users, the cost-benefit ratio is reversed.

Task List

• Describe the interface being presented
• Give users informed consent form (.doc) / informed consent form (.rtf)
• Explain goals of the session
• Explicitly mention in-room observers and/or videotaping
• Explain that you are testing the interface not them
• Reassure users about what will happen if they encounter difficulties
• Explain that the design will evolve from the current version
• Explain that you will record their suggestions but don’t promise to implement them
• Explain how to interact with the prototype
• Discuss thinking aloud and asking questions
• Confirm ending time and reassure them that they can take a break at any time
• Clarify tasks if confusing
• Have user sign informed consent form (.doc) / informed consent form (.rtf)

For every task complete the following list:

• Task number & name - Give each task a brief descriptive name and number.
• Goal/Output - What will users have accomplished when they have finished the task? How will they know the task is complete?
• Inputs - List all the information or resources a user might need (tangible or intangible) to complete the task. Examples include valid login, business policies, text book, credit card, file names etc. All these need to be available to the user during the usability test.
• Assumptions - Conditions and prerequisites that are in place at the start of the task. Example – a database with a built in error to see how the user handles it.
• Steps - Write down the steps you expect the user to go through, while completing the task. Example – Open order form. Fill out form. Submit form. Be sure to include choices. Example – Search OR Navigate
• Time for Expert - Ignore time taken by system to process. Focus on time spent entering data and clicking buttons. Some tasks require time for creative effort so allow time for that. Use this estimate to help you decide how many tasks will fill your allocated time. Multiply by a factor of at least 3.
• Instructions for User - May be basic or complex depending on task.
• Notes - Why you created the task. How you’ll conduct it. Specific things to watch for. Questions to ask users after task is complete.

Conditions required

• Stay for the entire test - The goal is to make the users forget that anyone else is in the room. While you are observing the test you are not available for any interruption short of an emergency. Turn off mobile phones!!
• Remain silent while the users are working - You may notice a problem so surprising that you are tempted to laugh or exclaim out loud. This is not unusual. Unfortunately the users will think you are laughing at them. Please do your best to keep quiet. There will be opportunities to ask questions after each task and at the end of the test.
• Be conscious of your body language - Sit quietly without fidgeting. Keep busy taking notes. If you feel you understand the issue, have the user end the task and begin the next.
• Don’t reveal how many tasks you have - It is often more useful to explore an area of difficulty, rather than trying to get through all the tasks. Users may rush one task if they feel they are spending too much time on others.
• No helping - Instead try to understand why the user got stuck or went down the wrong path.
• Avoid ‘design’ questions - These can take up a lot of time and provide limited results. Focus on trying to understand the problem. Come up with solution later with your design team.
• Respect participants and the confidentiality of their data - Use the assigned participant number when referring to a particular user. Don’t include names on reports or emails. Do not make negative comments on people. There is always a chance that a derogatory comment may be overheard or otherwise make its way back to the user.

Limitations Of method

Reading

. CSS . XHTML . WCAG AAA .

created & designed by Vivienne Trulock for ilikecake