A cognitive walkthrough starts with a task analysis that specifies the sequence of steps or actions required by a user to accomplish a task, and the system responses to those actions. The designers and developers of the software then walk through the steps as a group, asking themselves a set of questions at each step. Data is gathered during the walkthrough, and afterwards a report of potential issues is compiled. Finally the software is redesigned to address the issues identified.
The effectiveness of methods such as cognitive walkthroughs is hard to measure in applied settings, as there is very limited opportunity for controlled experiments while developing software. Typically measurements involve comparing the number of usability problems found by applying different methods. However, Gray and Salzman called into question the validity of those studies in their dramatic 1998 paper "Damaged Merchandise", demonstrating how very difficult it is to measure the effectiveness of usability inspection methods. The consensus in the usability community is that the cognitive walkthrough method works well in a variety of settings and applications.
After the task analysis has been made, the participants perform the walkthrough:1
The CW method does not take several social attributes into account. The method can only be successful if the usability specialist takes care to prepare the team for all possibilities during the cognitive walkthrough. This tends to enhance the ground rules and avoid the pitfalls that come with an ill-prepared team.
In teaching people to use the walkthrough method, Lewis & Rieman have found that there are two common misunderstandings:2
There are social constraints that inhibit the cognitive walkthrough process. These include time pressure, lengthy design discussions and design defensiveness. Time pressure is caused when design iterations occur late in the development process, when a development team usually feels considerable pressure to actually implement specifications, and may not think they have the time to evaluate them properly. Many developers feel that CW's are not efficient because of the amount of time they take and the time pressures that they are facing. A design team spends their time trying to resolve the problem, during the CW instead of after the results have been formulated. Evaluation time is spent re-designing, this inhibits the effectiveness of the walkthrough and leads to lengthy design discussions. Many times, designers may feel personally offended that their work is even being evaluated. Due to the fact that a walk-through would likely lead to more work on a project that they already are under pressure to complete in the allowed time, designers will over-defend their design during the walkthrough. They are more likely to be argumentative and reject changes that seem obvious.
The method was developed in the early nineties by Wharton, et al., and reached a large usability audience when it was published as a chapter in Jakob Nielsen's seminal book on usability, "Usability Inspection Methods".3 The Wharton, et al. method required asking four questions at each step, along with extensive documentation of the analysis. In 2000 there was a resurgence in interest in the method in response to a CHI paper by Spencer who described modifications to the method to make it effective in a real software development setting. Spencer's streamlined method required asking only two questions at each step, and involved creating less documentation. Spencer's paper followed the example set by Rowley, et al. who described the modifications to the method that they made based on their experience applying the methods in their 1992 CHI paper "The Cognitive Jogthrough".4
Originally designed as a tool to evaluate interactive systems, such as postal kiosks, automated teller machines (ATMs), and interactive museum exhibits, where users would have little to no experience with using this new technology. However, since its creation, the method has been applied with success to complex systems like CAD software and some software development tools to understand the first experience of new users.
Spencer, Rick (2000). "The streamlined cognitive walkthrough method, working around social constraints encountered in a software development company". Proceedings of the SIGCHI conference on Human Factors in Computing Systems. The Hague, The Netherlands: ACM Press. pp. 353–359. doi:10.1145/332040.332456. ISBN 978-1-58113-216-8. S2CID 1157974. 978-1-58113-216-8 ↩
Lewis, Clayton; Rieman, John (1994). "Section 4.1: Cognitive Walkthroughs". Task-Centered User Interface Design: A Practical Introduction. pp. 46–54. Retrieved April 10, 2019. http://hcibib.org/tcuid/chap-4.html#4-1 ↩
Wharton, Cathleen; Riemann, John; Lewis, Clayton; Poison, Peter (June 1994). "The cognitive walkthrough method: a practitioner's guide". In Nielsen, Jakob; Mack, Robert L. (eds.). Usability inspection methods. John Wiley & Sons. pp. 105–140. ISBN 978-0-471-01877-3. Retrieved 2020-02-11. {{cite book}}: |website= ignored (help) 978-0-471-01877-3 ↩
Rowley, David E; Rhoades, David G (1992). "The cognitive jogthrough: A fast-paced user interface evaluation procedure". Proceedings of the SIGCHI conference on Human factors in computing systems - CHI '92. pp. 389–395. doi:10.1145/142750.142869. ISBN 0897915135. S2CID 15888065. 0897915135 ↩