User Interface Design and Ergonomics - National Open University of ...

More documents

Recommendations

Info

If you are led to develop more and more elaborate approximations to the real system for testing purposes you need to think about controlling costs. Simple mockups are cheap, but prototypes that really work, or even Wizard of Oz setups, take substantial implementation effort. Some of this effort can be saved if the prototype turns out to be just part of the real system. As we will discuss further when we talk about implementation, this is often possible. A system like Visual Basic or Hypercard allows an interface to be mocked up with minimal functionality but then hooked up to functional modules as they become available. So don't plan for throwaway prototypes: try instead to use an implementation scheme that allows early versions of the real interface to be used in testing. 3.1.4 DECIDING WHAT DATA TO COLLECT Now that we have people, tasks, and a system, we have to figure out what information to gather. It is useful to distinguish PROCESS DATA from BOTTOM-LINE data. Process data are observations of what the test users are doing and thinking as they work through the tasks. These observations tell us what is happening step-by-step, and, we hope, suggests WHY it is happening. Bottom-line data give us a summary of WHAT happened: how long did users take, were they successful, how many errors did they make. It may seem that bottom-line data are what you want. If you think of testing as telling you how good your interface is, it seems that how long users are taking on the tasks, and how successful they are, is just what you want to know. We argue that process data are actually the data to focus on first. There's a role for bottom-line data, as we discuss in connection with Usability Measurement below. But as a designer you will mostly be concerned with process data. To see why, consider the following not-so-hypothetical comparison. Suppose you have designed an interface for a situation in which you figure users should be able to complete a particular test task in about a half-hour. You do a test in which you focus on bottom-line data. You find that none of your test users was able to get the job done in less than an hour. You know you are in trouble, but what are you going to do about it? Now suppose instead you got detailed records of what the users actually did. You see that their whole approach to the task was mistaken, because they didn't use the frammis reduction operations presented on the third screen. Now you know where your redesign effort needs to go. We can extend this example to make a further point about the information you need as a designer. You know people weren't using frammis reduction, but do you know why? It could be that they understood perfectly well the importance of frammis reduction, but they didn't understand the screen on which these operations were presented. Or it could be that the frammis reduction screen was crystal clear but they didn't think frammis reduction was relevant. 180
Depending on what you decide here, you either need to fix up the frammis reduction screen, because it isn't clear, or you have a problem somewhere else. But you can't decide just from knowing that people didn't use frammis reduction. To get the why information you really want, you need to know what users are thinking, not just what they are doing. That's the focus of the thinking-aloud method, the first testing technique we'll discuss. 3.1.5 CHOOSING USERS TO TEST The basic idea of thinking aloud is very simple. You ask your users to perform a test task, but you also ask them to talk to you while they work on it. Ask them to tell you what they are thinking: what they are trying to do, questions that arise as they work, things they read. You can make a recording of their comments or you can just take notes. You'll do this in such a way that you can tell what they were doing and where their comments fit into the sequence. You'll find the comments are a rich lode of information. In the frammis reduction case, with just a little luck, you might get one of two kinds of comments: "I know I want to do frammis reduction now, but I don't see anyway to do it from here. I'll try another approach," or "Why is it telling me about frammis reduction here? That's not what I'm trying to do." So you find out something about WHY frammis reduction wasn't getting done, and whether the frammis reduction screen is the locus of the problem. You can use the thinking-aloud method with a prototype or a rough mock-up, for a single task or a suite of tasks. The method is simple, but there are some points about it that repay some thought. Here are some suggestions on various aspects of the procedure. This material is adapted from Lewis, C. "Using the thinking-aloud method in cognitive interface design," IBM Research Report RC 9265, Yorktown Heights, NY, 1982. a. Instructions The basic instructions can be very simple: "Tell me what you are thinking about as you work." People can respond easily to this, especially if you suggest a few categories of thoughts as examples: things they find confusing, decisions they are making, and the like. There are some other points you should add. Tell the user that you are not interested in their secret thoughts but only in what they are thinking about their task. Make clear that it is the system, not the user, that is being tested, so that if they have trouble it's the system's problem, not theirs. You will also want to explain what kind of recording you will make, and how test users' privacy will be protected. b. The Role of the Observer Even if you do not need to be available to operate a mockup, you should plan to stay with the user during the test. You'll do two things: prompt the user to keep up the flow of comments, and provide help when necessary. But you'll need to work out a policy for prompting and helping that avoids distorting the results you get. 181
Page 1:
] NATIONAL OPEN UNIVERSITY OF NIGER
Page 4 and 5:
National Open University of Nigeria
Page 6 and 7:
Summary ...........................
Page 8 and 9:
UNIT 3 - GRAPHICAL USER INTERFACE (
Page 10 and 11:
Assignments File Tutor-Marked Assig
Page 12 and 13:
2 DESIGN and DESIGNING GOOD USER IN
Page 14 and 15:
need both the study unit you are wo
Page 16 and 17:
CIT 711: USER INTERFACE DESIGN AND
Page 18 and 19:
UNIT 1 FUNDAMENTALS OF USER INTERFA
Page 20 and 21:
3.3 TYPES OF USER INTERFACES Curren
Page 22 and 23:
3.5 USER INTERFACE MODALITIES AND M
Page 24 and 25:
Table of Contents 1.0 Introduction
Page 26 and 27:
3.1.1 DESIGNING A GOOD USER INTERFA
Page 28 and 29:
widgets properly is to read and und
Page 30 and 31:
Figure 1:- Showing that alignment o
Page 32 and 33:
6.0 TUTOR MARKED ASSIGNMENT a. How
Page 34 and 35:
A graphical user interface is a typ
Page 36 and 37:
Operating System. It is easy for a
Page 38 and 39:
A list of items from which to selec
Page 40 and 41:
collaborative work. For example, sc
Page 42 and 43:
MODULE 1 UNIT 4 HUMAN COMPUTER INTE
Page 44 and 45:
3.3 DIFFERNCES WITH RELATED FIELDS
Page 46 and 47:
window blinds to automobile braking
Page 48 and 49:
Wickens, Christopher D., John D. Le
Page 50 and 51:
The International Ergonomics Associ
Page 52 and 53:
approach, the Gilbreths reduced the
Page 54 and 55:
3.6 BENEFITS OF ERGONOMICS The thre
Page 56 and 57:
Another key to reducing lumbar disc
Page 58 and 59:
MODULE 2 - USER INTERFACE DESIGN TE
Page 60 and 61:
methods include inspection methods,
Page 62 and 63:
Determine time of each operation (b
Page 64 and 65:
unable to understand new informatio
Page 66 and 67:
M cones, or, misleadingly, green co
Page 68 and 69:
Motor skill which is a learned seri
Page 70 and 71:
MODULE 2 UNIT 2 UNDERSTANDING USERS
Page 72 and 73:
The users of a system must be ident
Page 74 and 75:
This example brings up an important
Page 76 and 77:
whether you want to have a palette
Page 78 and 79:
Task analysis which includes identi
Page 80 and 81:
MODULE 2 UNIT 3 USER CENTERED DESIG
Page 82 and 83:
or small body text is also hard to
Page 84 and 85:
Introduction to User-centered desig
Page 86 and 87:
organizations themselves. Interacti
Page 88 and 89:
After thorough analysis using vario
Page 90 and 91:
Interaction design which is the dis
Page 92 and 93:
In human-computer interaction and c
Page 94 and 95:
The preferred method for ensuring u
Page 96 and 97:
3.4 ISO STANDARDS FOR USABILITY ISO
Page 98 and 99:
In this unit, you have been introdu
Page 100 and 101:
affect the way the command is execu
Page 102 and 103:
• Guides the user via the predefi
Page 104 and 105:
The term direct manipulation was in
Page 106 and 107:
There are two important reasons for
Page 108 and 109:
108
Page 110 and 111:
UNIT 1 PROTOTYPING Table of Content
Page 112 and 113:
Figure 12: The iterative steps of p
Page 114 and 115:
select print Figure 13: An interfac
Page 116 and 117:
Ambler, S.W. & Constantine, L.L. (2
Page 118 and 119:
3.2 LOW-FIDELITY PROTOTYPES Low-fid
Page 120 and 121:
Figure 14:- Example of Sketching II
Page 122 and 123:
Much more important for features th
Page 124 and 125:
DENIM, an extension of SILK, is a t
Page 126 and 127:
• Encourage menu & forms style, r
Page 128 and 129:
Another problem is that native widg
Page 130 and 131: interfaces, so that a realistic sim
Page 132 and 133: UNIT 3 INPUT AND OUTPUT MODELS Tabl
Page 134 and 135: Recall that perceptual fusion means
Page 136 and 137: 3.2 OUTPUT MODEL There are basicall
Page 138 and 139: directly-mapped pixel image will no
Page 140 and 141: Most stroke models also include som
Page 142 and 143: UNIT 4 MODEL VIEW-CONTROLLER (MVC)
Page 144 and 145: 3.3.2 AS A DESIGN PATTERN MVC enco
Page 146 and 147: The Views are XForms controls for s
Page 148 and 149: UNIT 5 LAYOUTS AND CONSTRAINTS Tabl
Page 150 and 151: 3.5 CONSTRAINTS Constraints are rel
Page 152 and 153: 152
Page 154 and 155: MODULE 4 UNIT 1 TECHNIQUES FOR EVAL
Page 156 and 157: a. Card Sorting Card sorting is a w
Page 158 and 159: Rapid prototyping is a method used
Page 160 and 161: 3.2.1 THE USE OF PROTOTYPES It is o
Page 162 and 163: Dumas, J.S. and Redish, J.C. (1999)
Page 164 and 165: the users' respect for you as a pro
Page 166 and 167: the users will be and what kind of
Page 168 and 169: speed whenever the average load was
Page 170 and 171: Table 4:- Table: Average times for
Page 172 and 173: phases: list the actions, and then
Page 174 and 175: Nielsen and Molich used their own e
Page 176 and 177: 7.0 REFERENCES AND FURTHER READING
Page 178 and 179: users. If you do not, you can be ba
Page 182 and 183: It's very easy to shape the comment
Page 184 and 185: a. Analyzing the Bottom-Line Number
Page 186 and 187: you use. But then you need some way
Page 188 and 189: ecruit test users with more similar
Page 190 and 191: MODULE 4 UNIT 4 OTHER EVALUATION IS
Page 192 and 193: 3.2 CURRENT ISSUES CONCERNING EVALU
Page 194 and 195: 2.0 OBJECTIVES By the end this unit
Page 196 and 197: It provides a real focal point for
Page 198 and 199: 3.3.4 CONDUCTING THE TEST Having co
Page 200: The stages involved in usability te
show all

User Interface Design and Ergonomics - National Open University of ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?