Authors: Preece, Rogers & Sharp
Introduction
Starters
Chapters
Case Studies
Interactivities
Students' corner
Buy the Book [pop-up]
About the Book [pop-up]
2 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Chapter Index
Introducing Evaluation
 

     

Chapter Introduction | Web Resources | Assignment comments | Teaching Materials

 

Recently I met two web designers who, proud of their newest site, looked at me in astonishment when I asked if they had tested it with users. "No,'' they said "but we know it's OK.'' So, I probed further and discovered that they had asked the "web whiz­kids'' in their company to look at it. These guys, I was told, knew all the tricks of web design.

The web's presence has heightened awareness about usability, but unfortunately this reaction is all too common. Designers assume that if they and their colleagues can use the software and find it attractive, others will too. Furthermore, they prefer to avoid doing evaluation because it adds development time and costs money. So why is evaluation important? Because without evaluation, designers cannot be sure that their software is usable and is what users want. But what do we mean by evaluation? There are many definitions and many different evaluation techniques, some of which involve users directly, while others call indirectly on an understanding of users' needs and psychology. In this book we define evaluation as the process of systematically collecting data that informs us about what it is like for a particular user or group of users to use a product for a particular task in a certain type of environment.

As you read in Chapter 9, the basic premise of user­centered design is that users' needs are taken into account throughout design and development. This is achieved by evaluating the design at various stages as it develops and by amending it to suit users' needs (Gould and Lewis, 1985). The design, therefore, progresses in iterative cycles of design­evaluate-redesign. Being an effective interaction designer requires knowing how to evaluate different kinds of systems at different stages of development. Furthermore, developing systems in this way usually turns out to be less expensive than fixing problems that are discovered after the systems have been shipped to customers (Karat, 1993). Studies also suggest that the business case for using systems with good usability is compelling (Dumas and Redish, 1999; Mayhew, 1999): thousands of dollars can be saved.

Many techniques are available for supporting design and evaluation. Chapter 9 discussed techniques for involving users in design and part of this involvement comes through evaluation. In this and the next four chapters you will learn how different techniques are used at different stages of design to examine different aspects of the design. You will also meet some of the same techniques that are used for gathering user requirements, but this time used to collect data to evaluate the design. Another aim is to show you how to do evaluation.

This chapter begins by discussing what evaluation is, why evaluation is important, and when to use different evaluation techniques and approaches. Then a case study is presented about the evaluation techniques used by Microsoft researchers and the Fred Hutchinson Cancer Research Center in developing HutchWorld (Cheng et al., 2000), a virtual world to support cancer patients, their families, and friends. This case study is chosen because it illustrates how a range of techniques is used during the development of a new product. It introduces some of the practical problems that evaluators encounter and shows how iterative product development is informed by a series of evaluation studies. The HutchWorld study also lays the foundation for the evaluation framework that is discussed in Chapter 11.

The main aims of this chapter are to:

  • Explain the key concepts and terms used to discuss evaluation.
  • Discuss and critique the HutchWorld case study.
  • Examine how different techniques are used at different stages in the development of HutchWorld.
  • Show how developers cope with real­world constraints in the development
    of HutchWorld.