Method 12 of 100:Teachback

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

By Chauncey Wilson

This is the 12th in a series of 100 short articles about UX design and evaluation methods. Today’s method is called “teachback”. In the teachback method an expert explains concepts, workflow, procedures, or instructions, associated with a particular domain to a non-expert (who could be a user or an interaction designer). The non-expert then tries to teach back what the expert had explained. During the teachback session, the expert corrects any misunderstandings. The misunderstandings and the actual expert discussion are both data that interaction designers can use as input for product design.

As an example of how teachback can be used for design, consider an interaction designer with some basic knowledge of a product or domain. That designer is tasked to work on some new features that are complex, so she finds several experts and asks them, one at a time to explain work related to that new feature. She then teaches back what she learned from each expert and asks the expert to correct any errors or misconceptions. The interactions are recorded. After several teachback sessions, the interaction designer should have a much deeper understanding of the issues and concepts associated with the new features and probably discovered some use cases that had been missed.

Method 12 of 100: Teachback

When to Use:

Teachback is a technique for extracting information from experts that would be useful for gathering requirements, learning about workflow, and understanding mental models. The method is also used in healthcare to determine if patients understand instructions about medication or medical procedures. In the healthcare arena a medical provider, home health aid, nurse, or doctor, would describe a procedure to a patient and then ask them to “tell me in your own words how you would…”

Procedure:

The teachback requires a domain or subject matter expert, a non-expert (the “learner”), and, optionally, a facilitator who takes notes and handles the recording. The learner and the facilitator can be the same person.

1. A subject matter expert is asked to describe a concept, task, or something else about a particular domain or product. A facilitator records the sessions with audio or video (or just takes notes if electronic recording is not possible.
2. The non-expert (e.g., the interaction designer listens carefully to the expert.
3. The non-expert is then asked to “teach back to the expert” what the expert had previously described or explained.
4. When the non-expert is teaching back what she learned, the expert corrects any misinterpretations, errors, or simplifications.
5. The session is repeated with another expert who again teaches the non-expert.
6. The transcripts from all the sessions are examined for common misinterpretation, errors, or simplifications.

Strengths and Weaknesses:

+   The basic approach is simple. An expert discusses or explains something to a non-expert related to a particular domain or product. The non-expert then describes back what he/she learned.

+ The method can highlight concepts that are hard to understand, instructions that are difficult to grasp, or gaps in mental models.

- The teachback method is not highly structured. The expert can present information in different ways using different styles, which might create problems for the non-expert.

- The non-expert needs to have some basic awareness of the concepts for a product or process so the expert doesn’t feel that his or her time is being wasted.

- The non-expert might feel bad if the expert’s corrections are too harsh.

- If you choose an expert who is arrogant and obnoxious, you might have an unhappy learner and a wasted session.

References:

Johnson, L. & Johnson, N.E., (1987). Knowledge Elicitation Involving 

Teachback Interviewing in Kidd, A.L., (Ed.), 1987, Knowledge Acquisition for Expert Systems: A Practical Handbook.

---

What’s Next in the Series?

The next UX method posting will describe some ideas on how to do consistency reviews. This is a long-delayed continuation of an earlier column about consistency in software design. The next posting will be somewhat more general than earlier ones.

 

Comments

[Johan Strandell]

Interesting, it's not a method I've heard of before but it sounds useful - I was just thinking about methods for knowledge extraction from experts the other day.