About the cognitive walkthrough
The cognitive walkthrough is a formalised way of imagining people’s thoughts and actions when they use an interface for the first time. Walkthroughs identify problems that new users will have when they first use an interface. You select one of the tasks that the design is intended to support and then you step through the task, action by action, seeing if you can identify any problems with the interface.
Although the technique was developed over 20 years ago (by Cathleen Wharton, John Rieman, Clayton Lewis and Peter Polson) it is much less widely used than heuristic-based expert reviews. This is a shame because the technique simulates the way real people use an interface: by exploration rather than by reading the manual.
Creating the happy path
Before you can start a cognitive walkthrough, you need a complete, written list of the actions needed to complete the task with the interface — the ‘happy path’. For example, here’s the happy path for creating a customised voicemail message on an iPhone:
- Tap Voicemail.
- Tap Greeting.
- Tap Custom.
- Tap Record and speak your greeting.
- When you finish, tap Stop.
- To listen to your greeting, tap Play.
- To re-record, repeat steps 4 and 5.
- Tap Save.
Sometimes, creating the happy path is all you need to do to realise there is a problem with the interface. For example, configuring email on a Nokia 6233 requires 78 separate steps. If your happy path has this many actions, there's no need to continue with the review: you've found a serious problem already.
Once you have the happy path, you’re ready to start the walkthrough.
The 4 questions to ask in a cognitive walkthrough
The cognitive walkthrough is structured around 4 questions that you ask of every step in the task. You ask these questions before, during and after each step in the happy path. If you find a problem, you make a note and then move on to the next step of the task.
Q1: Will the customer realistically be trying to do this action?
This question finds problems with interfaces that make unrealistic assumptions about the level of knowledge or experience that users have. It also finds problems with systems where users expect to do a different action because of their experience with other interfaces or with life generally.
For example, my Sony Vaio laptop has two settings, ‘Stamina’ and ‘Speed’ (see Figure 1). The designers assume that I will switch to the ‘Stamina’ setting to save battery power and use the ‘Speed’ setting for graphics-intensive applications, such as games. Is this assumption reasonable?
Figure 1: Stamina or speed?
Q2: Is the control for the action visible?
This question identifies problems with hidden controls, like the gestural user interfaces required by an iPad where it's not always obvious what you can do. It also highlights issues with context-sensitive menus or controls buried too deep within a navigation system. If the control for the action is non-standard or unintuitive then it will identify those as well.
The world of TV remote controls provides a familiar example. Remote controls often contain a flap to hide features that are rarely used (see Figure 2). The problem occurs when you need access to those functions but, because you rarely use them, you don’t realise you need to lift a flap to reveal them.
Figure 2: Hidden controls on a TV remote
Q3: Is there a strong link between the control and the action?
This question highlights problems with ambiguous or jargon terms, or with other controls that look like a better choice. It also finds problems with actions that are physically difficult to execute, such as when you need to press three keys on the keyboard at the same time (and stand on one leg).
Figure 3 shows an example from a car park machine at Stuttgart airport that has a weak link between the control and the action. I used this machine over a period of 18 months while on assignment in Germany. The first time I arrived at the airport and wanted to leave the car park, I was confronted by the barrier and the control shown in the picture. The barrier has a slot at the top and two buttons, a green one on top and a red one below. I didn't have anything to put in the slot, so I guessed I had to press one of the buttons.
Figure 3: Green for Go or Red for Exit?
Question: Which button would you press to lift the barrier: the green one or the red one?
Convention dictates that you would press the green, upper button. In fact, this appeared to do nothing. Assuming that the barrier was broken, I pressed the red button, thinking that this would put me in intercom contact with the car park attendant who could then open it for me. To my surprise, the red button lifted the barrier.
Clearly, I was not the only person to experience this difficulty. When I returned some weeks later, the design had been upgraded (see Figure 4). As well as a large sign showing the correct button to push, some ‘help text’ had been added to the system (in both German and English) saying ‘Please press the red button’. To emphasise this, the designers had even printed the word ‘red’ in red ink. Which button would you press now?
Figure 4: Not the first time that documentation has been used to rescue bad design.
As if to prove that customers do not read documentation, when I returned some weeks later, the design had been changed again (see Figure 5).
Figure 5: When you're in a hole, stop digging.
Presumably, customers had not been using the help system. The hint text, now flapping in the breeze, had been almost discarded and the design had been changed to include a series of (red) arrows, indicating which button to press.
This month’s rhetorical question: how many participants would have been needed in a usability test to spot this blooper?
Q4: Is feedback appropriate?
This question helps you find problems when feedback is missing, or easy to miss, or too brief, poorly worded, inappropriate or ambiguous. For example, does the system prompt users to take the next step in the task?
Figure 4 shows an example from a control panel for an electronic toilet door on a British train. What button would you press if you want some privacy?
Figure 4: A toilet door control panel that only a trainspotter could love.
With this system, you first need to press the ‘Door open / close’ button and then you need to press the ‘Door lock’ button. If, like many people, you forget to press the ‘Door lock’ button, you may find your privacy interrupted as someone on the other side of the door opens it to reveal you seated on the toilet like a prize in a game show. This problem occurs because the door fails to provide adequate feedback on whether it is locked or unlocked.
Try it yourself
The best way to get going with a cognitive walkthrough is to try it yourself. Start off by writing down the happy path for sending a message on your mobile phone. Then walkthrough each step in the process and ask the 4 questions of the interface. If you want to explore the method in more depth, you should attend our training course: How to carry out an expert review.
About the author
Dr. David Travis (@userfocus on Twitter) holds a BSc and a PhD in Psychology and he is a Chartered Psychologist. He has worked in the fields of human factors, usability and user experience since 1989 and has published two books on usability. David helps both large firms and start ups connect with their customers and bring business ideas to market. If you like his articles, you'll love his online user experience training course.
Love it? Hate it? Join the discussioncomments powered by Disqus
Foundation Certificate in UX
Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details
Every month, we share an in-depth article on user experience with over 10,000 newsletter readers. Want in? Sign up now and download a free guide to usability test moderation.
User Experience Articles
Our most recent articles
- Apr 3: Is Usability a Science?
- Mar 6: Why iterative design isn’t enough to create innovative products
- Feb 6: The Beginners' Guide to Contextual Interviewing
- Jan 9: The 8 competencies of user experience: a tool for assessing and developing UX Practitioners
- Dec 5: Non-UX books that every UX practitioner should read
Our most commented articles
Search for articles by keyword
- 7 articles tagged accessibility
- 4 articles tagged axure
- 5 articles tagged benefits
- 16 articles tagged careers
- 8 articles tagged case study
- 1 article tagged css
- 8 articles tagged discount usability
- 2 articles tagged ecommerce
- 14 articles tagged ethnography
- 14 articles tagged expert review
- 1 article tagged fitts law
- 4 articles tagged focus groups
- 1 article tagged forms
- 6 articles tagged guidelines
- 10 articles tagged heuristic evaluation
- 7 articles tagged ia
- 14 articles tagged iso 9241
- 11 articles tagged iterative design
- 3 articles tagged layout
- 2 articles tagged legal
- 11 articles tagged metrics
- 3 articles tagged mobile
- 7 articles tagged moderating
- 3 articles tagged morae
- 2 articles tagged navigation
- 9 articles tagged personas
- 15 articles tagged prototyping
- 7 articles tagged questionnaires
- 1 article tagged quotations
- 4 articles tagged roi
- 16 articles tagged selling usability
- 12 articles tagged standards
- 44 articles tagged strategy
- 2 articles tagged style guide
- 4 articles tagged survey design
- 5 articles tagged task scenarios
- 2 articles tagged templates
- 21 articles tagged tools
- 53 articles tagged usability testing
- 3 articles tagged user manual