Thinking-aloud protocols traditionally have been used by academic researchers as a qualitative data collection method. This method is currently gaining acceptance in industry usability testing. The Usability Group at Microsoft has adopted the thinking-aloud protocol as a primary method for obtaining data from users. We have found the method valuable not only because it is valid for gathering qualitative data, but also because it is responsive to the constraints we face and the organizational culture we work within. The issue of validity has been discussed in detail by researchers such as Deffner & Rhenius and Ericcson & Simon. Our case study further pursues the validity of thinking-aloud protocols and also discusses how this method allows the researcher to work within industry constraints and incorporate changes into the product within a small time frame. Finally, our case study demonstrates how thinking-aloud protocols fit in well with Microsoft corporate culture where understandable and persuasive results are needed. This case study will have particular relevance for usability practitioners in industry.
Task analysis, the "systematic analysis of human task requirements and/or task behavior" (Stammers et al., 1990), is a primary research method used in the human factors and ergonomics fields to identify and understand the components of a particular job, set of tasks, or task in a particular context. Researchers and practitioners in other fields, such as technical writing and usability testing, have recognized the importance of task analysis in designing concise, usable docurnentatiou as well as in heIping to create intuitive products. In fac~a technical writer~do some form of task analysis in order to truly create a task-oriented manual.However, the task analysis performed is often implicit in the writing process instead of a formal procedure. A number of articles about task analysis methods have been airned at tectilcal writers in recent years, but my research indicates that formal methods are being used very selectively in many companies in the computer indushy. (See Berghel & Roach [ 1990], Bradford [1988], and Leonard & Wailer [1989], among orhers.) While there could be many reasons for thk lack of use, my work with several different writing teams at Microsoft points to three possibilities(1) an assumption that task analysis is primarily valuable when a completely new product is being created, (2) a feeling that task analysis would take too much time for the information it yields, and (3) confusion about what task analysis techniques would be best to use for a given situation and set of questions.In thk paper I address these three concerns by describing some first steps I took in adapting task analysis for a usability field research project at Microsoft. The context of my discussion is one phase of a usability field study conducted on a programming product. Specifically, I discuss:1) The questions the writing team needed to have answered2) The type of task analysis I chose to use3)The type of information the task analysis generated 4) How the group of writers (and program designers) used the information 5) Ideas for implementing the method Permission to copy without fee all or part of this material is granted provided that tbe copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or tn repubtish, requires a fee and/or specific permission. Field Study QuestionsThe usability field study described in this paper had three major phases and lasted approximately six months. We undertook the study to better understand how programmers were using the latest version of a Microsoft language product. Studies in our usability laboratory had shown us that a "typical programming task" was very hmd to define-users of the product were engaged in a wide variety of projects-and that a lab study did not allow sufficient time with any one programmer to truly understand his/her work patterns.We designed a longitudinal field study...
This organization overview discusses the lessons learned in applying the usability engineering principles of iterative design and problem tracking to the development of Windows 95, a large commercial software project. CONTEXTWindows 95 is an extensive upgrade to the Windows 3.x family of operating systems. The user interface is but one of many areas of the product which featured dramatic changes.based on descriptions of usability engineering in [l] and [3]. We began by creating paper or computer-based prototypes. Each prototype was used to try out design ideas and to gather usability data in the lab. After testing in the usability lab, the prototype was usually improved and retested. Once results were satisfactory, the design was coded then refmed in the usability lab. Following lab testing, we examined the product as a whole over time in the field (during beta testing).
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
customersupport@researchsolutions.com
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.