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

More documents

Recommendations

Info

3.3.4 CONDUCTING THE TEST Having completed the basic groundwork and preparation for your usability test, you are almost ready to begin testing. While there exit an almost endless variety of sophisticated esoteric tests one might conduct ( from a test comprising a single participant and lasting several days to a fully automated test with 200 or more participants), in this chapter I will focus on the guidelines and activities for conducting classic “one-on-one” test. This “typical” test consists of four to ten participants, each of whom is observed and questioned individually by a test monitor seating in the same room. This method will work for any of the four types of tests mentioned: exploratory, assessment, validation, or comparison. The main difference is the types of objectives pursued, that is, more conceptual for an exploratory test, more behaviour oriented for assessment and validation tests. The other major difference is the amount of interaction between participant and test monitor. The earlier exploratory test will have much interaction. The later validation test will have much less interaction, since the objective is measurement against standard. For “first time” testers, I recommend beginning with an assessment test; it is probably the most straightforward to conduct. At the end of this chapter, I will review several variations and enhancements to the basic testing technique that you can employ as you gain confidence. In terms of what to test, I would like to raise an issue previously mentioned in chapter 2, because it is crucial. That is, the importance of testing the whole integrated product and not just separate components. Testing a component, such as documentation, separately, without ever testing it with the rest of the product, does nothing to ensure ultimate product usability. Rather it enforces the lack of product integration. In short, you eventually would like to test all components together, with enough lead time to make revisions as required. However, that being said, there is absolutely nothing wrong with testing separate components as that are developed throughout the life cycle, as long as you eventually test them all together. There is one exception to this rule, if you believe that the only way to begin any kind of testing program within an organization is to test a component separately as your only test, then by all means do so. However, you should explain to management the limited nature of those results. 3.3.5 DEBRIEFING THE PARTICIPANT Debriefing refers to the interrogation and review with the participant of his or her own actions during the performance portion of a usability test. When first sitting down to organize this book, I was not sure whether to assign debriefing to its own stage of testing or to combine it with the previous stage of conducting the test. After all, one could argue that debriefing is really an extension of the testing process. Participants perform some tasks, and you interrogate that either in phases or after the entire test. But the more I thought about how much I had learned during the debriefing portions of tests, the more I felt that debriefing warranted its own separate treatment, or stage of testing. More often the not, the debriefing session is the key to understanding how
to fix the problems uncovered during the performance portion of the test. While the performance of the usability test uncovers and exposes the problems, it is often the debriefing session that shed light on why these problems have occurred. Quite often, it is not until the debriefing session that one understands motive, rationale, and very subtle points of confusion. If you think of usability testing as a mystery to be solved, it is not until the debriefing session that all the pieces come together. 3.3.6 TRANSFORMING DATA INTO FINDINGS AND RECOMMENDATIONS Finally, you have completed testing and are now ready to dive in and transform a wealth of data into recommendations for improvement. Typically, the analysis of data falls into two distinct processes with two different deliverables. The first process is a preliminary analysis and is intended to quickly ascertain the hot spots (i.e., word problems), so that the designers can work on these immediately without having to wait for the final test report. This preliminary analysis takes place as soon as it is feasible after testing has been completed. Its deliverable is either a small written report or a verbal presentation of findings and recommendation. The second process is a comprehensive analysis, which takes place during a two-tofour-week period after the test. Its deliverables is a final, more exhaustive report. This final report should include all the findings in the preliminary report, updated if necessary, plus all the other analysis and findings that were not previously covered. A word of caution is in order regarding preliminary findings and recommendations. Developing and reporting preliminary recommendations creates a predicament for the test monitor. Your recommendations must be timely so that members of the development team, such as designers and writers, can begin implementing changes. However, you also need to be thorough, in the sense of not missing anything important. Once preliminary recommendations are circulated for public consumption, they quickly lose their preliminary flavour. Designers will begin to implement changes, and it is difficult to revisit changes at a later time and say, “Oops, I don’t really think we should change that module after all. You could simply avoid producing preliminary recommendations, but if designers viewed the tests they are sure to act on what they saw prior to your final report, therefore not providing preliminary recommendations is not a satisfactory option. The best compromise is to provide preliminary findings and recommendations, but be cautious and err on the conservative side by providing too little rather than too much. Stick to very obvious problems that do not require further analysis on your part. If you are unsure about a finding or a recommended solution without performing further analysis, simply say so. 4.0 CONCLUSION In this unit, you have been introduced to the stages involved in carrying out usability testing. 5.0 SUMMARY
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 180 and 181: If you are led to develop more and
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 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?