User Experience Re-Mastered Your Guide to Getting the Right Design- P9

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:46

lượt xem

User Experience Re-Mastered Your Guide to Getting the Right Design- P9

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

User Experience Re-Mastered Your Guide to Getting the Right Design- P9: Good user interface design isn't just about aesthetics or using the latest technology. Designers also need to ensure their product is offering an optimal user experience. This requires user needs analysis, usability testing, persona creation, prototyping, design sketching, and evaluation through-out the design and development process.

Chủ đề:

Nội dung Text: User Experience Re-Mastered Your Guide to Getting the Right Design- P9

  1. Analysis and Interpretation of User Observation CHAPTER 11 337 INTERPRETATION OF USER-OBSERVATION DATA Once you have analyzed your data – for example, by grouping them according to a coding scheme – your final step is interpretation: deciding what caused the defects that you have identified and recommending what to do about them. In Table 11.4, we suggest a template for gathering defects and interpretations. Again, some sample data have been entered into the table for the purposes of illustra- tion. For the example task, because the defect is related to the first action of the task and the task cannot be accomplished until the user chooses the right menu item, we have assigned a severity rating of “High.” Notice that this form carefully preserves the distinction between our observations and our comments on them. Some practitioners prefer to gather the defects and the good points about the interface on a single form, whereas others prefer to deal with all the defects and all the good points in two separate passes. Choose whichever method you prefer. Assigning Severities The process of summarizing the data usually makes it obvious which problems require the most urgent attention. In our form in Table 11.3, we have included a column for assigning a severity to each defect. Bearing in mind our comments about statistics, one important point to remem- ber is that the weighting given to each participant’s results depends very much on comparison with your overall user profile. Recommending Changes Some authorities stop here, taking the view that it is the responsibility of the development team to decide what to change in the interface. For example, the Common Industry Format for summative evaluation does not include a section for recommendations, taking the view that deciding what to do is a separate process when undertaking a summative evaluation: Table 11.3 Data Interpretation Form for User Observations Session Date: February 11 Task Scenario No. 1 Session Start Time: 9:30 a.m. Evaluator’s Name: John Session End Time: 10:20 a.m. Usability Evaluator’s Comments Cause of the Severity Rating Observation Usability Defect, if There Is One The user did The user was not sure The menu name is High not select the which menu item inappropriate, as right menu item Options was in. it does not relate (Options) to to the required initiate the task. action. – – – –
  2. 338 User Experience Re-Mastered: Your Guide to Getting the Right Design Stakeholders can use the usability data to help make informed decisions concerning the release of software products or the procurement of such products. ( If your task is to improve the interface as well as to establish whether it meets the requirements, then you are likely to need to work out what to do next: recom- mending the changes. So we suggest a template in Table 11.4 to record the recommendations. In the table, the “Status” column indicates what is being planned for the recommended change – when the usability defect will be rectified, if it has been deferred, or if it is being ignored for the time being. It is hard to be specific about interpretation of results. Fortunately, you will find that many problems have obvious solutions, particularly if this is an exploratory evaluation of an early prototype. Evaluations are full of surprises. You will find defects in parts of the interface that you thought would work well, and conversely you may find that users are completely comfortable with something that you personally find irritating or never expected to work. Equally frequently, you will find that during the analysis of the results you simply do not have the data to provide an answer. Questions get overlooked, or users have conflicting opinions. Finally, the experience of working with real users can entirely change your perception of their tasks and environment, and the domain of the user interface. Your recommendations, therefore, are likely to contain a mixture of several points: ■ Successes to build on ■ Defects to fix ■ Possible defects or successes that are not proven – not enough evidence to decide either way (these require further evaluation) ■ Areas of the user interface that were not tested (no evidence) (these also require further evaluation) ■ Changes to usability and other requirements Table 11.4 Recommendations Form Cause of the Severity Recommended Status Participant Usability defect usability defect rating solution description Beth The user did not The menu name The menu High Make select the right is inappropri- name should change in menu item ate, as it does be changed next (Options) to not relate to the to “Group.” revision. initiate the task. required action. Mary – – – – –
  3. Analysis and Interpretation of User Observation CHAPTER 11 339 WRITING THE EVALUATION REPORT Generally, you need to write up what you have done in an evaluation: ■ To act as a record of what you did ■ To communicate the findings to other stakeholders The style and contents of the report depend very much on who you are writing for and why. EDITOR’S NOTE: TIMELINESS CAN CAUSE TROUBLE: WHEN OBSERVATIONS BECOME “THE REPORT” Be cautious about releasing preliminary results, including e-mails about the evaluation, that observers send to their teams after seeing a few sessions. By chance, observers might see sessions that are not representative of the overall results. Development schedules have been shrinking over the last decade and there is often pressure to “get the data out quickly.” In some cases, developers watch think-aloud sessions, discuss major problems at the end of the day and makes changes to the product (in the absence of any formal report) that sometimes appear in code even before the evaluation is complete. While fixing an obvious bug (e.g., a misspelled label) may be acceptable, changing key features without discussing the impact of the changes across the product may yield fixes that create new usability problems. If you plan to release daily or preliminary results, err on the conservative side and release only the most certain findings with a caveat about the dangers of making changes before all the data are in. Caution observers that acting too hastily might result in fixes that have to be “unfixed” or political problems that have to be undone. Here is an example of a typical report created for an academic journal. EXTRACT FROM AN ACADEMIC PAPER ON THE GLOBAL WARMING EVALUATIONS Abstract The Open University [OU] has undertaken the production of a suite of multimedia teaching materials for inclusion in its forthcoming science foundation course. Two of these packages (Global Warming and Cooling and An Element on the Move) have recently been tested and some interesting general issues have emerged from these empirical studies. The formative testing of each piece of software was individually tailored to the respective designers’ requirements. Since these packages were not at the same stage of development, the evaluations were constructed to answer very different questions and to satisfy different production needs. The question the designers of the Global Warming software wanted answered was: “Is the generic shell usable/easy to navigate through?”
  4. 340 User Experience Re-Mastered: Your Guide to Getting the Right Design This needed an answer because the mathematical model of Global Warming had not been completed on time but the software production schedule still had to proceed. Hence the designers needed to know that when the model was slotted in the students would be able to work with the current structure of the program. 2.0 Background The multimedia materials for this Science Foundation course consisted of 26 programs. This first year course introduces students to the academic disciplines of biology, chemistry, earth sciences and physics and so programs were developed for each of these subject domains. The software was designed not to stand alone but to complement written course notes, videotapes, home experiments, and face to face tutorials. The aims of the program production teams were to: ■ Exploit the media to produce pedagogical materials that could not be made in any other way ■ Produce a program with easy communication channels to i. the software itself via the interface ii. the domain knowledge via the structure and presentation of the program ■ Provide students with high levels of interactivity ■ Sustain students with a motivating learning experience In order to test whether the programs would meet the above aims a framework for the developmental testing of the software was devised. A three-phased approach was recom- mended and accepted by the Science Team. This meant that prototypes which contained generic features could be tested at a very early stage and that the developers would aim, with these early programs, to actually make prototypes to be tested quickly at the begin- ning of the software’s life cycle. This was known as the Primary Formative Testing Phase. The subjects for this phase would not need to be Open University students but people who were more “competent” computer users. We wanted to see if average computer users could navigate through a section and understand a particular teaching strategy without then having to investigate all the details of the subject matter. This would mean the testing could take place more quickly and easily with subjects who could be found on campus. The Secondary Formative Testing Phase was aimed to test the usability and learning potential of the software. It would take place later in the developmental cycle and would use typical Open University students with some science background. Pre- to post-test learning measures would indicate the degree of learning that took place with the software. Testing the time taken to work through the programs was an important objective for this phase. It was agreed that the Open University students would be paid a small fee when they came to the university to test the software. The Tertiary Testing Phase would include the final testing with pairs of Open University students working together with the software. In this way, the talk generated around the tasks would indicate how clearly the tasks were constructed and how well the students understood the teaching objectives of the program. (The framework is summarized in the table presented here.)
  5. Analysis and Interpretation of User Observation CHAPTER 11 341 3.0 Framework for Formative Developmental Testing 3.1 The Testing Cycle …The aim of the testing here was to evaluate some generic features, therefore all the pieces of the program did not have to be in place. In fact the aim of this evaluation study was to provide the developers with feedback about general usability issues, the interface and subjects’ ease of navigation around the system… 3.2 Subjects …Generic features were tested with “experienced users” who did not have scientific background knowledge and could easily be found to fill the tight testing schedule…. In order to understand if certain generic structures worked, “experienced users” were found (mean age 32.6 years 5). These consisted of 10 subjects who worked alone with the software and had already used computers for at least five years and had some experience of multimedia software. The reason these types of subjects were selected was that if these experts could not understand the pedagogical approach and use the interface satisfactorily, then the novice learners would have extreme difficulty too. Also these subjects were confident users and could criticize the software using a “cognitive walk through” methodology. Evaluation type Aims Subjects Primary Phase Test design and generic fea- Competent computer users tures Secondary Phase Test usability and learning OU students with science back- potential of product ground Tertiary Phase Test usability and whole learn- Pairs of OU students with ing experience science background Framework for the Developmental Testing of the Multimedia Materials Produced for the Science Foundation Course 3.3 Data Collection Instruments …In order to understand the students’ background knowledge, they were given two questionnaires to complete which were about their computer experience and also a pre- test about the subject area which was going to be investigated. The pre-test was made up of eight to 10 questions which addressed the main teaching objectives of the software… 4.0 Evaluation Findings …The Global Warming program introduced the students to a climatic model of the factors that change the earth’s temperature. These variables, which include the solar constant, levels of carbon dioxide and water vapor, aerosol content, cloud cover, ice and snow cover, and albedo could all be changed by the student who could then explore these factors’ sensi- tivities, understand the effects of coupling between factors by again manipulating them, and finally, to gain an appreciation of the variation of global warming with latitude and season.
  6. 342 User Experience Re-Mastered: Your Guide to Getting the Right Design There is a large cognitive overhead for the students using this software and they have to be guided through a number of tasks. It was, therefore, important to test the screen layout, interface and pedagogical approach very early in the developmental cycle and this was achieved by testing a prototype without the mathematical model being in place. The “cognitive walk through” technique worked well here. Subjects said when they arrived at a stumbling block, “I don’t know what to do here.” The main difficulty experienced was when tabs instead of buttons suddenly appeared on the interface. The functionality of the tabs was lost on the subjects. A general finding here is not to mix these two different interface elements. Subjects liked the audio linkage between sections and the use of audio to convey task instructions. One subject enthusiasti- cally mentioned that, “This feels like I have a tutor in the room with me—helping me.” Other findings suggest that any graphical output of data should sit close to the data table. The simulation run button did not need an icon of an athlete literally running; however, the strategy of predict, look, and explain was a good one when using the simulation… Conclusions The two formative testing approaches proved to be effective evaluation techniques for two separate pieces of software. This was because the multimedia programs were in different phases of their developmental cycle. On the one hand, usability of a generic shell was the primary aim of the testing and experienced users, who could be found at short notice, were an important factor to the success of this evaluation. The ability of the subjects to confidently describe their experience became critical data in this instance. Extracted from Whitelock (1998) Should You Describe Your Method? If you are writing a report for an academic audience, it is essential to include a full description of the method you used. An academic reader is likely to want to decide whether your findings are supported by the method and may want to replicate your work. If you are writing for a business audience, then you will need to weigh up their desire for a complete record of your activities and the time that they have to read the report. Some organizations like to see full descriptions, similar to those expected by an academic audience. Others prefer to concentrate on the results, with the detailed method relegated to an appendix or even a line such as, “Details of the method are available on request.”
  7. Analysis and Interpretation of User Observation CHAPTER 11 343 EDITOR’S NOTE: SHOULD YOU DESCRIBE YOUR SAMPLING METHOD IN A REPORT? There are a variety of ways to create a sample of users. Consider describing your sam- pling method (e.g., snowball sampling, convenience sampling, or dimensional sampling) briefly since different sampling methods may affect how the data are interpreted. Describing Your Results “Description” does not need to be confined to words. Your report will be more interesting to read if you include screenshots, pictures, or other illustrations of the interface with which the user was working. Jarrett (2004) gives two alternative views of the same piece of an evaluation report: The black line is dominant on the page. It seems off- putting to be "welcomed" with the phrase, "Your location is not Text requires set" This seems horizontal scrolling somewhat at 800x600. accusing rather than giving me encouragement to delve further. The primary functionality for search is "below the The long list of fold" at 800x600. partner names is offputting. It's important to see what the site is The three prompts The prompts and The three prompts are covering but this have equal visual headings are hard to the same color as presentation weight and it is not read (orange on the headings so give makes it a blur. clear whether you white). an impression of being This information have to enter one or headings rather than would be better all of them. guiding data entry. presented in a bulleted list. FIGURE 11.6 Findings presented with a screenshot. From Jarrett (2004).
  8. 344 User Experience Re-Mastered: Your Guide to Getting the Right Design We know that long chunks of writing can look boring, and we joke about “ordeal by bullet points” when we’re in a presentation. But how often have we been guilty of the same sins in our reports? Here are two ways to present the same information. First, as a block of text: It seems off-putting to be “welcomed” with the phrase, “Your location is not set.” This seems somewhat accusing rather than giving me encouragement to delve further. The long list of partner names is off-putting. It’s important to see what the site is covering but this presentation makes it a blur. This information would be better presented in a bulleted list. The three prompts have equal visual weight and it is not clear whether you have to enter one or all of them. The prompts and headings are hard to read (orange on white). The three prompts are the same color as the headings so give an impression of being headings rather than guiding data entry. The primary functionality for search is “below the fold” at 800 ´ 600. Text requires horizontal scrolling at 800 ´ 600. The black line is dominant on the page. (p. 3) Indigestible, right? Now look at the screenshot [in Fig. 11.6]. I preferred it, and I hope that you do too. SUMMARY In this chapter, we discussed how to collate evaluation data, analyze it, interpret it, and record recommendations. We introduced the concept of a severity rating for a usability defect: assigning severity ratings to usability defects helps in mak- ing decisions about the optimal allocation of resources to resolve them. Severity ratings, therefore, help to prioritize the recommended changes in tackling the usability defects. Finally, we started to think about how to present your findings. We will return to this topic in more detail, but first we will look at some other types of evaluation.
  9. CHAPTER 12 Inspections of the User Interface 345 Debbie Stone, Caroline Jarrett, Mark Woodroffe, and Shailey Minocha EDITOR’S COMMENTS User interface inspections are the most commonly used tools in our efforts to improve usability. Inspections generally involve examining a user interface against a set of user interface standards, guidelines, or principles. This chapter describes heuristic evaluation, a method invented by Jakob Nielsen and Rolf Molich that was meant to be simple enough for developers and other members of a product team to use with limited training. The primary goal of a heuristic evaluation is to reveal as many usability or design problems as possible at relatively low cost. A secondary goal of the heuristic evaluation is to train members of the product team to recognize potential usability problems so they can be eliminated earlier in the design process. You can use heuristic evaluation when: ■ You have limited (or no) access to users. ■ You need to produce an extremely fast review and do not have time to recruit participants and set up a full-fledged lab study. ■ Your evaluators are dispersed around the world. ■ You are looking for breadth in your review. ■ Your clients have come to trust your judgment and for many issues do not require you to provide the results of user testing or other more expensive evaluation methods. This chapter describes the procedure for heuristic evaluation and also provides several other inspection methods that practitioners can use, either individually or with groups, to eliminate usability defects from their products. Copyright © 2010 Elsevier, Inc. All rights Reserved.
  10. 346 User Experience Re-Mastered: Your Guide to Getting the Right Design INTRODUCTION Although user observation gives you a huge amount of insight into how users think about the user interface, it can be time consuming to recruit participants and observe them only to find that a large number of basic problems in the user interface could have been avoided if the designers had followed good practice in design. Undertaking an inspection of the user interface before (but not instead of) user observation can be beneficial to your evaluation. NOTE The contents of this section have been particularly influenced by the following sources: Virzi (1997), Nielsen (1994), and Nielsen (1993). “Inspection of the user interface” is a generic name for a set of techniques that involve inspectors examining the user interface to check whether it complies with a set of design principles known as heuristics. In this chapter, we describe the heu- ristic inspection technique (also known as heuristic evaluation). Heuristic inspec- tion was chosen as it is one of the most popular and well-researched inspection techniques for evaluation (Molich & Nielsen, 1990). CREATING THE EVALUATION PLAN FOR HEURISTIC INSPECTION Choosing the Heuristics Your first task in planning a heuristic inspection is to decide which set of guide- lines or heuristics you will use. If your organization has established a specific style guide, then that is one obvious choice. The advantage of using heuristics that you have used for design is that you can establish whether they have been applied consistently. Otherwise, the advantage of using a different set is that you get a fresh eye on the interface and may spot problems that would otherwise be overlooked. One set of heuristics often used in inspections is the set proposed by Nielsen (1993), which we have included as Table 12.1. We found that the humorous article on the usability of infants in the box below helped us to understand how these heuristics might be applied. The Inspectors Instead of recruiting a real or representative user to be your participant, you need to find one or more inspectors. Ideally, an inspector is an expert in human– computer interaction (HCI) and the domain of the system. These skills are rarely available in one person. It is also difficult for anyone, no matter how expert, to give equal attention to a variety of heuristics and domain knowledge. It is, there- fore, more usual to find two or more inspectors with different backgrounds. The box below presents some ideas.
  11. Inspections of the User Interface CHAPTER 12 347 Table 12.1 Nielsen’s Heuristics (1993) Heuristic Description Visibility of system The system should always keep users informed about status what is going on, through appropriate feedback within reasonable time. Match between sys- The system should speak the users’ language, with tem and the real world words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and Users often choose system functions by mistake and freedom will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialog. Supports undo and redo. Consistency and Users should not have to wonder whether different standards words, situations, or actions mean the same thing. Follow platform conventions. Error prevention Even better than a good error message is a careful design that prevents a problem from occurring in the first place. Recognition rather Make objects, actions, and options visible. The user than recall should not have to remember information from one part of the dialog to another. Instructions or use of the system should be visible or easily retrievable when- ever appropriate. Flexibility and Accelerators – unseen by the novice user – may often efficiency of use speed up the interaction for the expert user such that the system can cater to both the inexperienced and experienced users. Allow the users to tailor frequent actions. Aesthetic and mini- Dialogues should not contain information that is irrel- malist design evant or rarely needed. Every extra unit of informa- tion in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, Error messages should be expressed in plain lan- diagnose, and recover guage (no codes), precisely indicating the problem, from errors and constructively suggesting a solution. Help and Even though it is better if the system can be used documentation without documentation, it may be necessary to pro- vide help and documentation. Any such information should be easy to search, focus on the user’s task, list concrete steps to be carried out, and not be too large.
  12. 348 User Experience Re-Mastered: Your Guide to Getting the Right Design A HEURISTIC EVALUATION OF THE USABILITY OF INFANTS For your consideration… Results from a heuristic evaluation of infants and their user interface, based on direct observational evidence and Jakob Nielsen’s list of 10 heuristics from . All ratings are from 1 to 10, with 1 being the worst and 10 being the best. Visibility of System Status – 6: Although it is easy enough to determine when the infant is sleeping and eating, rude noises do not consistently accompany the other pri- mary occupation of infants. Further, infants can multitask, occasionally performing all three major activities at the same time. Match between System and the Real World – 3: The infant does not conform to normal industry standards of night and day, and its natural language interface is woefully underdeveloped, leading to the error message problems cited below. User Control and Freedom – 2: The infant’s users have only marginal control over its state. Although they can ensure the availability of food, diapers, and warmth, it is not often clear how to move the infant from an unfavorable state back to one in which it is content. When the default choice (data input) doesn’t work, user frustra- tion grows quickly. Consistency and Standards – 7: Most infants have similar requirements and error messages, and the same troubleshooting procedures work for a variety of infants. Cuteness is also an infant standard, ensuring that users continue to put up with the many user interface difficulties. Error Prevention – 5: Keeping the infant fed, dry, and warm prevents a number of errors. Homeostasis is, however, a fleeting goal, and the infant requires almost constant attention if the user is to detect errors quickly and reliably. All bets are off if the infant suffers from the colic bug or a virus. Recognition Rather Than Recall – 7: The various parts of the infant generally match those of the user, though at a prototype level. The users, therefore, already have in place a mental model of the infant’s objects. The data input and output ports are easily identifiable with a minimum of observation. Flexibility and Efficacy of Use – 2: Use of the infant causes the user to conform to a fairly rigid schedule, and there are no known shortcuts for feeding, sleeping, and diaper buffer changing. Avoid buffer overflows at all costs, and beware of core dumps! Although macros would be incredibly useful, infants do not come equipped with them. Macro programming can usually begin once the infant attains toddler status. Aesthetic and Minimalist Design – 5: As mentioned earlier, infants have a great deal of cuteness, and so they score well on aesthetic ratings. Balancing this, however, is the fact that the information they provide is rather too minimal. Infants interact with the user by eating, generating an error message, or struggling during buffer updates.
  13. Inspections of the User Interface CHAPTER 12 349 Help Users Recognize, Diagnose, and Recover from Errors – 1: Infants have only a single error message, which they use for every error. The user, therefore, is left to diagnose each error with relatively little information. The user must remem- ber previous infant states to see if input is required, and the user must also independently check other routine parameters. Note the error message is not the same as a general protection fault. That is what resulted in the infant in the first place. Help and Documentation – 1: Although some user training is available from experts, infants come with effectively no documentation. If users seek out documentation, they must sift through a great deal of conflicting literature to discover that there are very few universal conventions with regard to infant use. Mean Score 3.9 This user has been up since 3:30 this morning (perhaps you can tell), and still has three to five months to go (he hopes) before stringing together eight hours of uninterrupted sleep. McDaniel (1999, p. 44): This article was originally published in STC Intercom. EDITOR’S NOTE: WHAT DO YOU CONSIDER WHEN CHOOSING HEURISTICS? When you are choosing or developing heuristics, some of the issues to consider include the following: ■ Relevance: Are the heuristics relevant to the domain and product? If you are evalu- ating a call center application where efficiency is a key attribute, you may need to include some domain-specific heuristics that are relevant to the call center environ- ment and focus on high efficiency. ■ Understandability: Will the heuristics be understood and be used consistently by all members of the analysis team? ■ Their use as memory aids: Are the heuristics good mnemonics for the many detailed guidelines they are meant to represent? For example, does the heuristic “error prevention,” prompt the novice or expert to consider the hundreds of guide- lines regarding good labeling, input format hints, the use of abbreviations, explicit constraints on the allowable range of values, and other techniques or principles for actually preventing errors. ■ Validity: Is there proof that a particular set of heuristics is based on good research? For example, the site,, lists guidelines for Web design and usability and includes ratings that indicate the guidelines are based on research.
  14. 350 User Experience Re-Mastered: Your Guide to Getting the Right Design CHOOSING INSPECTORS FOR HEURISTIC EVALUATIONS ■ Usability experts – people experienced in conducting evaluations ■ Domain experts – people with knowledge of the domain (This may include users or user representatives.) ■ Designers – people with extensive design experience ■ Developers – people without any formal usability training, but who are keen to explore the usability defects that users might experience ■ Nonexperts – people who are neither system domain experts nor usability experts, although they may be experts in their own particular domains (Nonexperts could be friends, colleagues, or family members who understand what you are doing and are willing to inspect the user interface to provide feedback.) CONDUCTING A HEURISTIC INSPECTION Because you know who the inspectors are, you usually do not need to ask them any questions about their background. Because the inspectors fill in the defect reports immediately, there is usually no need to record the session – there is lit- tle insight to be gained from watching a video of someone alternating between looking at a screen and filling in a form! However, you may want to record it if the inspector is verbalizing his or her thoughts while undertaking the inspection. If you want to record the inspection for later review, you will need to obtain per- mission from your inspector(s). If your inspectors are domain or HCI experts, then they are unlikely to need any training before the session. If you have less experienced inspectors, it may be worthwhile to run through the heuristics with them and perhaps start with a practice screen so that everyone is clear about how you want the heuristics to be interpreted for your system. Task Descriptions You can prepare task descriptions just as you would for a user observation. The inspector then steps through the interface, reviewing both the task descrip- tion and the list of heuristics, such as those shown in Table 12.1, at each step. This may make it easier to predict what users might do, but it has the disadvan- tage of missing out on those parts of the interface that are not involved in the particular task. Alternatively, you might try to check each screen or sequence in the interface against the whole list of heuristics. It helps if you plan the sequence in advance, so that each inspector is looking at the same screen at the same time while undertaking the inspection. The Location of the Evaluation Session Generally, heuristic inspections are undertaken as controlled studies in infor- mal settings that need have no resemblance to the users’ environments. For example, Fig. 12.1 shows a usability expert, Paul Buckley, from a big UK
  15. Inspections of the User Interface CHAPTER 12 351 Table 12.2 Data Collection and Analysis Form for Heuristic Inspection Task Scenario No.: 1 Session Date: February 25 Evaluator’s Name: John Session Start Time: 9:30 a.m. Inspector’s Name: George Session End Time: 10:20 a.m. Location in the Heuristic Violated Usability Defect Inspector’s Com- Task Description Description ments regarding the Usability Defect New e-mail Visibility of system The user is not The user would like message arrives status informed about to be alerted when in the mailbox. the arrival of a a new message new e-mail. arrives. – – – – telecommunications company, British Telecom (BT), doing a heuristic inspection in the BT usability laboratory. Collecting Evaluation Data In Table 12.2, we have suggested a template for the collection of data during a heuristic inspec- tion. You can see a similar form on the clipboard on the expert’s lap in Fig. 12.1. Note that there is a column for recording the usability defects. This is because the inspectors will identify most of the usability defects as they walk through the interface during the evaluation session. This is different from the data collection FIGURE 12.1 form for user observation, where the usability defects are identified during the Heuristic inspection of analysis of the data. a British Telecom (BT) user interface. If more than one inspector is involved in the inspection, then each inspector should be encouraged to complete an individual data-collection form. Com- pleting individual forms is useful at the time of specifying the severity ratings, because each individual inspector may want to specify his or her own severity ratings for the usability defects based on his or her own experience and opinions. Encourage the inspectors to be as specific as possible in linking the usability defects to the heuristics. This helps the inspectors concentrate on the heuristics to be checked. ANALYSIS OF HEURISTIC INSPECTION DATA The analysis of your data follows the same process as for the user observation. In theory, collating and summarizing data from a heuristic inspection is a relatively simple matter of gathering together the forms that the inspectors have used.
  16. 352 User Experience Re-Mastered: Your Guide to Getting the Right Design However, because inspectors do not always have the same opinion, you may want to get the inspectors to review each other’s forms and discuss any differ- ences between them, perhaps going back over the interface collectively to resolve any disagreements. EDITOR’S NOTE: SHOULD HEURISTIC EVALUATIONS HIGHLIGHT POSITIVE ASPECTS OF A PRODUCT’S USER INTERFACE? Heuristic evaluations are heavily focused on problems and seldom highlight positive aspects of a product’s user interface. A guideline for usability test reports is that they highlight positive aspects of the product as well as negative aspects; heuristic evaluation reports could also highlight the major positive aspects of a product. Listing the positive aspects of a product has several advantages: ■ Evaluation reports that highlight positive and negative issues will be perceived as more balanced by the product team. ■ You might reduce the likelihood of something that works well being changed for the worse. ■ You may want to propagate some of the positive design features throughout the product. ■ Sometimes the positive features being mentioned actually bring focus to some of the very negative features being highlighted. INTERPRETATION OF HEURISTIC INSPECTION DATA The interpretation of your data follows the same process as for user observation. In Table 12.3, we have suggested a template for the interpretation of data dur- ing a heuristic inspection. When you produce your recommendations, you may want to invite the inspectors back to review your recommendations or the whole of your report to check that they agree with your interpretation. BENEFITS AND LIMITATIONS OF HEURISTIC EVALUATIONS In general, there are several benefits to conducting heuristic evaluations and inspections: ■ Inspections can sometimes be less expensive than the user observation, especially if you have to recruit and pay participants for the latter. ■ During an inspection, inspectors more often than not suggest solutions to the usability defects that they identify. ■ It can be annoying to discover a large number of obvious errors during a usability test session. Inspecting the user interface (UI) first can help to reveal these defects.
  17. Inspections of the User Interface CHAPTER 12 353 Table 12.3 Interpretation Form for Heuristic Evaluation Task Scenario No.: 1 Evaluator: John Inspector’s Name: George Review Meeting Date: Inspector’s Comments regarding the Usability Defect Usability Defect Severity Rating Recommendations The user is not The user would High Add sound or a informed about like to be alerted visual indicator the arrival of when a new that alerts the user a new e-mail message arrives. when a new e-mail message. message arrives. There are, however, some limitations to conducting heuristic evaluations and inspections: ■ As usability inspections often do not involve real or representative users, it is easy to make mistakes in the prediction of what actual users will do with the UI. However, real users can find the heuristics difficult to under- stand and the atmosphere of an inspection session to be unrealistic, thus limiting the data obtained. ■ Inspectors often differ from real users in the importance they attach to a defect. For example, they may miss something they think is unimportant that will trip up real users, or they may be overly concerned about some- thing that in fact only slightly affects the real users. ■ Inspectors may have their own preferences, biases, and views toward the design of user interfaces or interaction design, which in turn may bias the evaluation data. ■ The evaluation data from inspection is highly dependent on the skills and experiences of the inspectors. Sometimes, the inspectors may have insufficient task and domain knowledge. This can affect the validity of the evaluation data as some domain- or task-specific usability defects might be missed during an inspection. ■ Heuristic reviews may not scale well for complex interfaces (Slavkovic & Cross, 1999). ■ Evaluators may report problems at different levels of granularity. For example, one evaluator may list a global problem of “bad error messages” while another evaluator lists separate problems for each error message encountered. ■ Lack of clear rules for assigning severity judgments may yield major differences; one evaluator says “minor” problem, whereas others say “moderate” or “serious” problem.
  18. 354 User Experience Re-Mastered: Your Guide to Getting the Right Design EDITOR’S NOTE: HOW DO YOU MEASURE THE SUCCESS OF A HEURISTIC EVALUATION? In the usability literature, the focus is on how many problems of various severities are found. That is a start, but a more important measure might be how many problems are fixed. Sawyer, Flanders, & Wixon (1996) suggest that the results of heuristic evaluations and other types of inspections look at the impact ratio, which is the ratio of the number of problems that the product team commits to fix to the total number of problems found mul- tiplied by 100 (p. 377). While the impact ratio provides a measure of how many problems are fixed, this measure still does not indicate how much more usable the product is as a result of the fixed problems. VARIATIONS OF USABILITY INSPECTION Participatory Heuristic Evaluations If instead of HCI or domain experts you recruit users as your inspectors, then the technique becomes a participatory heuristic evaluation (Muller, Matheson, Page & Gallup, 1998). Muller and his colleagues created an adaptation of Nielsen’s list of heuristics to make them accessible to users who are not HCI experts (see Table 12.4). Table 12.4 Heuristics in Participatory Heuristic Evaluation (from Muller, et al., 1998, pp. 16–17) System status 1. System status. The system keeps the users informed about what is going on through appropriate feedback within a reasonable time. User control and freedom 2. Task sequencing. Users can select and sequence tasks (when appropriate), rather than the system taking control of the users’ actions. Wizards are available but are optional and under user control. 3. Emergency exits. Users can ■ easily find emergency exits if they choose system functions by mistake (emergency exits allow the user to leave the unwanted state without having to go through an extended dialogue) ■ make their own decisions (with clear information and feedback) regarding the costs of exiting current work ■ access undo and redo operations 4. Flexibility and efficiency of use. Accelerators are available to experts but are unseen by the novice. Users are able to tailor frequent actions. Alternative means of access and operation are available for users who differ from the average user (e.g., in physical or cognitive ability, culture, language, etc.).
  19. Inspections of the User Interface CHAPTER 12 355 Table 12.4 Heuristics in Participatory Heuristic Evaluation (from Muller, et al., 1998, pp. 16–17) (Continued) Consistency and relevancy 5. Match between system and the real world. The system speaks the users’ language, with words, phrases, and concepts familiar to the user rather than system-oriented terms. Messages are based on the users’ real world, making information appear in a natural and logical order. 6. Consistency and standards. Each word, phrase, or image in the design is used consistently, with a single meaning. Each interface object or computer operation is always referred to using the same consistent word, phrase, or image. Follow the conventions of the delivery system or platform. 7. Recognition rather than recall. Objects, actions, and options are visible. The user does not have to remember information from one part of the dialog to another. Instructions for use of the system are visible or easily retrievable whenever appropriate. 8. Aesthetic and minimalist design. Dialogues do not contain information that is irrelevant or rarely needed (extra information in a dialogue competes with the relevant units of information and diminishes their relative visibility). 9. Help and documentation. The system is intuitive and can be used for the most common tasks without documentation. Where needed, documentation is easy to search, supports a user task, lists concrete steps to be carried out, and is sized appropriately to the users’ task. Large documents are supplemented with multiple means of finding their contents (tables of contents, indexes, searches, and so on). Error recognition and recovery 10. Help users recognize, diagnose, and recover from errors. Error messages precisely indicate the problem and constructively suggest a solution. They are expressed in plain (users’) language (no codes). Users are not blamed for the error. 11. Error prevention. Even better than good error messages is a careful design that prevents a problem from occurring in the first place. Users’ “errors” are anticipated, and the system treats the “error” as either a valid input or an ambiguous input to be clarified. Task and work support 12. Skills. The system supports, extends, supplements, or enhances the user’s skills, background knowledge, and expertise. The system does not replace them. Wizards support, extend, or execute decisions made by the users. 13. Pleasurable and respectful interaction with the user. The user’s interactions with the system enhance the quality of his or her experience. The user is treated with respect. The design reflects the user’s professional role, personal identity, or intention. The design is aesthetically pleasing – with an appropriate balance of artistic as well as functional value. 14. Quality work. The system supports the user in delivering quality work to his or her clients (if appropriate). Attributes of quality work include timeliness, accuracy, aesthetic appeal, and appropriate levels of completeness. 15. Privacy. The system helps the user to protect personal or private information – that belonging to the user or to the user’s clients.
  20. 356 User Experience Re-Mastered: Your Guide to Getting the Right Design Guideline Reviews Guideline reviews are inspections that use a set of design guidelines, such as a cor- porate style guide, instead of one of the sets of heuristics we have included here. Standards Inspections A standards inspection uses a standard such as ISO 9241 as the reference rather than a set of heuristics. Table 12.5 presents part of a sample data collection form (an applicability and adherence checklist) for evaluating a design with respect to part 12 of the ISO 9241 standard, which relates to the presentation of information. Standards are written in a formal manner for practitioners, rather than being accessible for users. If you need to do a standards inspection, then you really should consider bringing in an expert who is familiar with the standard and its language as one of your inspectors. If that is impractical, then allow extra time during your preparation for becoming thoroughly familiar with it yourself. A usability standard such as ISO 9241 is generalized to cater to a wide variety of user interfaces, so there may be some guidelines in the standard that are not applicable for the prototype you are evaluating (hence, the second column in Table 12.5 to record the applicability). The next column is for recording the adherence/nonadherence of the interface feature to the particular guideline of the standard. The inspector records his or her comments in the last column. Cognitive Walkthrough Cognitive walkthrough (CW) is a technique for exploring a user’s mental pro- cesses while performing particular task(s) with a UI. The CW can be used for gathering requirements or evaluation. For evaluation, a CW may be used to Table 12.5 Applicability and Adherence Checklist Used in Standards Inspection Recommendations (An Applicability Adherence Example from ISO 9241, Evaluator’s Part 12) Yes No Pass Fail Comments Labels ✓ ✓ The label names are meaningful. Labeling fields, items, icons, and graphs Fields, items, icons, and graphs are labeled unless their meaning is obvious and can be understood clearly by the intended users.


Đồng bộ tài khoản