Human Computer Interaction

Chapter 1 Important Things: Usability “the extent to which a product can be used by specified users to achieve specified goals witheffectiveness, efficiency and satisfaction in a specified context of use.” Effectiveness is the accuracy and completeness with which specified users can achieve specifiedgoals in particular environments. Efficiency is defined as the resources expended in relation to the accuracy and completeness of the goals achieved. Satisfaction is the comfort and acceptability of the work system to its users and other people affectedby its use.User-centered design (UCD) is an approach to user interface design and developmentthat involves users throughout the design and development process. Usercentered design not only focuses on understanding the users of a computer system under development but also requires an understanding of the tasks that users will perform with the system and of the environment (organizational, social, and physical) in which they will use the system. Taking a user-centered design approach should optimize a computer system’s usability.Users should be involved in every part of the user interface design and development life cycle. • Early in the design process when the requirements are being specified. Users could help in defining the requirements for the system by contributing a specification or by testing early mockups. Users can get involved by allowing themselves to be observed and giving feedback about the problems of the current system. • During prototyping, to test designs and options. Users could test versions of the interface to provide feedback and make suggestions to the designers. • Just before delivery of the product. Users again could test the product by using it or completing surveys about the various features. At this point, however, only minimal changes would be allowable. • During training/after delivery of the system. Again, users would use the product and give their opinions and detail any problems. Revisions at this stage would be included in the next version. There are many different techniques for evaluation. Here are just a few to get youstarted. The first two will be discussed further in Chapter 2, while the process of evaluation will be covered in depth in Part 4. • Observing the organization and how people work. Several kinds of evaluation depend on some form of observation or monitoring of the way in which users interact with a product or prototype. The observation may take place informally in the field or in a laboratory as part of more formal usability testing. • Interviewing, talking, and asking questions. As well as examining users’ performance, it is important to find out what they think about using the technology. No matter how good users’ performance scores are when using technology, if for some reason they do not like using it, then it will not be used. Surveys using questionnaires and interviews provide ways of collecting users’ attitudes to the system. • Making predictions. The aim of this kind of evaluation is to predict the types of problems that users will encounter without actually testing the system withthem.Chapter 2 Important Things:Direct ObservationDirect observation is a straightforward activity and will rapidly provide you with aninsight into the users, their tasks, and the environment for a computer system. Directobservation can be undertaken in many ways, but generally direct observationstudies are classified as either field studies or controlled studies. Field studies directlyobserve users in their usual work or home environment, doing their normal work orhome tasks, with the observer making notes about interesting behaviors. Controlledstudies directly observe users in a place other than their normal environment (forexample, in a usability laboratory), performing specially devised tasks, with theobserver recording their performance in some way, such as by timing tasks or particularsequences of actions.Indirect Observation: Video Recording Video recording on its own is an alternative to direct observation as it provides a permanentrecord of the observation session. Sometimes video recording may be usedwith software that automatically logs users’ keystrokes or interactions. Although collectingseveral kinds of information can be beneficial, it means that there is moredata to analyze, which can be time consuming. Because indirect observation createsmore distance between observers and users, it is considered to be more objectivethan direct observation. Although specially mounted recording equipment (the facil-ities typically found in a usability lab, for example) is extremely useful, you may be surprised by just how much valuable data you can collect using ordinary consumervideo equipment, especially now that small digital video recorders are available at areasonable price. However, there are some important issues to consider. You need toplan the observation, which means thinking about what you want to find out andwhat kind of data you need. For example, in a study of the way that people use a UIin the context of their own workplace, it may be useful to record samples of themusing the UI every day over a period of several days or weeks. These interactionsamples could then be analyzed; categorizing the activities, for example, will tell youwhat the UI is used for, what work it helps the users to do, or how often a particulartask is done. A study with quite a different and much finer focus might involve an indepthexamination of two users interacting with the UI over a period of just fiveminutes.Interviewing Your UsersInterviewing involves talking to or questioning users. It enables the gathering of information in a fast and friendly way. You will need to plan interviews carefully, deciding in advance who to interview, what questions to ask to gather the relevant information, and how long the interviews should be. There are two main kinds of interview: structured and unstructured (flexible). A structured interview has predetermined questions that are asked in a set way; there is little, if any, scope for exploring additional topics that might arise during the interview. In contrast, a flexible interview generally has some set topics for discussion and exploration, but no set sequence: the interviewer is free to follow up the interviewees’ replies, and to find out more about anything that is said.Questionnaires and SurveysQuestionnaires and surveys take a different approach to interviews for the purpose of gathering information. The focus shifts from the flexible and friendly approach provided by interviewing to the preparation of unambiguous questions and statements for the gathering of more precise information.Closed Questions A closed question asks the respondent to select an answer from a choice of alternative replies. Closed questions may require just “yes” or “no” responses, or they may have some form of rating scale associated with them. Which type you use will depend on whether you need simple or detailed information, as you will see from the examples below. The simplest rating scales are just checklists consisting of basic alternative responses to a very specific question. For example, a three-point scale that allows respondents to choose “yes,” “no,” or “don’t know” is often used (see Figure 2.2). These questions are easy to analyze because all you need to do is to count the number of responses in each category.A Likert scale is a selection of statements, each similar to a semantic differential, that when analyzed together portray a user’s attitude. The construction of Likert scales requires statistical analysis that is outside the scope of this book. Open Questions An open question allows respondents to say whatever they like in response, and theyare used where there are no predetermined answers. Open questions typically startwith phrases such as “What do you . . . ,” “How do you . . . ,” or “What ways . . . .” Limitingthe amount of space on the form for the answer can encourage respondents toprioritize their points (Rubin, 1994). Open questions provide richer data than doclosed questions, although the responses will be more time consuming to analyze asyou you need to read each one and decide on some way of grouping and classifyingthem. If you have a fairly small sample, say up to 100 respondents, it may be quickerand just as effective to create a simple list of all the responses to each open question.Summary This chapter explored several investigative techniques: observation, interviews, andquestionnaires/surveys. Any or all of these techniques can be used in therequirements-gathering phase of UI design. Complementary investigative techniquesare often used in combination; for example, you might use a questionnaireand also undertake some interviews, or you might use a questionnaire and alsoundertake some observation studies. This enables the strengths and weaknesses ofthe various techniques to be balanced.Chapter 3 Important Things:Traditionally, the classic software design life cycle focuses on the system’s requirementsrather than the users’ requirements. As we emphasized in Chapter 1, a usercentereddesign approach focuses instead on the importance of the user. In Chapter2 we discussed some suitable techniques for gathering requirements. Keeping theuser uppermost in your mind, you should undertake the following activities in gatheringthe requirements: • Observe users— real users—doing real work, where the application is to be used. • Observe and talk to real users. Many people will have information to offer or willhave something to say about the system. But you must also remember toobserve and talk to real users—the people who will actually use the system.Chapter 5 Important Things:The principle of consistency: As users find it difficult to handle the unexpected, itis important to be consistent throughout the UI. For example, you should usecolors in a consistent manner. If you use red to indicate danger, then always usered, rather than red sometimes and green at other times. The same applies toscreen layout, such as the positioning of buttons, and to all aspects of UI design. The principle of exploiting prior knowledge: As users perceive the screen usingtheir prior knowledge, this provides the opportunity to draw on theirexperience. A screen metaphor, such as the calculator that comes with theMicrosoft Windows operating system, does this by presenting users with afamiliar image that allows them to apply their prior knowledge and experienceof a physical calculator to the Windows version.The principle of perceptual organization: If you group things together that go together, it is easier for the user to pay attention to the appropriate group. Forexample, the screens in Figure 5.3 both represent the same information.However, part (a) has been grouped into categories and part (b) has not. Thelack of structure in part (b) makes it difficult to find information. The principle of importance: If something is important for the user, it should beplaced in a prominent position. For example, alarm and warning messages areoften placed in the center of the screen, blocking the work that the user iscarrying out.The law of proximity: Elements that are close together appear as groups rather than as random elements.The law of similarity: Elements of the same shape or color appear to belong together. The law of closure: Where possible, we see an incomplete element as complete—we fill in the gap.The law of continuity: We see this figure as two lines of dots crossing each other, rather than as a random set of dots.The law of symmetry: We tend to perceive regions bounded by symmetrical borders as coherent figures.The Principle of Visibility: It Should Be Obvious, What a Control Is Used For: In considering visibility, it is often useful to start from the goal you wish to achieve.For example, if you want to play a tape in a cassette player, can you see how to do it?Are the controls for playing the tape obvious? Are the controls for turning the playeron/off or for adjusting the volume obvious?The Principle of Affordance: It Should Be Obvious How a Control Is Used: Linked to the visibility of controls is the affordance of controls. To have the propertyof affordance, the design of the control should suggest (that is, afford) how it is to beoperated. For example, buttons afford pressing. Norman defines affordance as“strong clues to the operations of things. . . . When affordances are taken advantageof, the user knows what to do just by looking: no picture, label, or instruction isrequired” (Norman, 1988, p. 9). When the affordances of an object or device areobvious, it is easy for us to know how to interact with it. Affordances play a large partin the design of objects, but what is important is perceived affordance—what aperson thinks can be done with the object. Using the example of a cassette playeragain, what kind of controls are used? If buttons are used, do they afford pushing? Ifsliders are used, do they afford sliding? If knobs or dials are used, do they affordturning? Unfortunately, practicality sometimes conflicts with good affordance andthe appearance of the object takes precedence over its use. The Principle of Feedback: It Should Be Obvious When a Control Has Been Used:Feedback is information that is sent back to the user about what action has been accomplished upon the use of a control. Again, this principle is linked to visibility and affordance. Taking our example of a cassette player, if the controls are visible, then pressing, say, the play button would play the cassette; the feedback would be seeing the tape turning in the machine and hearing what was recorded on the tape. These were four psychological principles:• Users see what they expect to see.• Users have difficulty focusing on more than one activity at a time.• It is easier to perceive a structured layout. • It is easier to recognize something than to recall it. And there were three principles from experience: • The principle of visibility: It should be obvious what a control is used for.• The principle of affordance: It should be obvious how a control is used. • The principle of feedback: It should be obvious when a control has been used.Chapter 6 Important Things:Usability RequirementsUsability requirements are gathered using techniques such as interviewing, surveying, and observation. They are of two types: qualitative usability requirements and quantitative usability requirements. Qualitative usability requirements are concerned with the desired usability goals for a computer system; for example, “the system should be easy to use” or “there should be user satisfaction.” Qualitative usability requirements can be subjective and are not always easy to measure or quantify.• Learnability: The time and effort required to reach a specified level of useperformance (also described as ease of learning). • Throughput: The tasks accomplished by experienced users, the speed of task execution and the errors made (also described as ease of use). • Flexibility: The extent to which the system can accommodate changes to the tasks and environments beyond those first specified. • Attitude: The positive attitude engendered in users by the application.• Effective. The completeness and accuracy with which users achieve their goals. • Efficient. The speed (and accuracy) with which users can complete their tasks. • Engaging. The degree to which the tone and style of the interface makes the product pleasant or satisfying to use. • Error tolerant. How well the design prevents errors or helps with recovery from those that do occur. • Easy to learn. How well the product supports both initial orientation and deepening understanding of its capabilities. Costs/Budgets/Timescales Most projects will have a fixed budget with which to develop a system. This will certainly constrain what you do during the life cycle and could have an impact on the final design.Technical Constraints In the design of a computer system, the available technology is also a consideration. For example, an existing application may be running on a particular system configuration using a particular platform. The decision may have been taken to keep the existing hardware systems in use, or management may have budgeted to upgrade the hardware in line with what is required for the new system. Either way, this decision will affect your system development. For instance, you may be constrained if the existing technology is not upgraded. Or you may be in the position to develop something more creative or novel if the technology can be upgraded and recommendations for other newer devices that are appropriate to the work can then be included in your requirements specification.Trade-OffsAs you consider how the information you gather will inform your design, you will inevitably be faced with numerous conflicts and you will have to make trade-offs. An example of a trade-off would be to decide not to include a particular feature in a UI that would be useful for only a limited number of users. Trade-offs should not be undertaken randomly; rather, each trade-off must be evaluated in terms of its impact on the users’ ability to use the system effectively. As noted previously, sometimes what is seen as a benefit by one stakeholder may be seen as a cost by another (Wilson et al., 1996). As far as possible, trade-offs should be negotiated and agreed on with the users and other stakeholders. This may not be easy: outspoken people on will make their opinions (right or wrong) heard, therefore individual stakeholder personalities can often overly influence the design decisions. Any constraints and trade-offs identified should be recorded and entered into the requirements specification document, as should any negotiations or decisions made for dealing with them. • Not enough user/stakeholder involvement in the requirements-elicitation process may cause the requirements to be incomplete. • Lack of requirements management —that is, changes to requirements as a result of feedback and negotiation are not tracked properly or not properly recorded. As a result, the requirements are inaccurate. • Related to the above, if the requirements-gathering efforts are not properly coordinated, some activities may not be carried out. Once again, the requirements will be incomplete or inaccurate. • Communication problems related to different stakeholders with different levels of understanding can be problematic for sharing understanding of the requirements between all groups. • Capturing the relevant application domain-related information can be difficult, as the knowledge exists in a variety of places: textbooks, operating manuals, and in the heads of the people working in the area. • People who do understand the problem may be heavily constrained by their workload and time, or they may be convinced that a new system is not necessary and be reluctant to participate or cooperate with those gathering the requirements. • Organizational and political factors may influence the specification of the requirements, and these views may not tally with the end users. Related to this problem are the agendas of different stakeholders, which may make eliciting and negotiating requirements difficult. • Some stakeholders will not know what they want from the computer system except in the most general terms, while others will be verbally forceful and detailed about what they want. Getting a balanced view can be problematic, as noted previously under constraints. • Economic and business environments within organizations are ever-changing, as are employee roles within organizations. This, inevitably, changes the elicitation process, because stakeholders will change over the duration of the design and development of the application. The purposes of prototyping are as follows:• To check the feasibility of ideas with users • To check the usefulness of the application • To allow users to contribute to the design of the application • To allow users to test ideas • To validate the requirements (i.e., to reveal inconsistent or incomplete requirements) • To negotiate requirementsLow-Fidelity Prototypes Low-fidelity prototypes are generally paper based and include sketches, screen mockups, and storyboards. They can be created by hand, but they can also be created using a drawing package like Paint or PowerPoint and then printed out for testing with users. Low-fidelity prototypes are useful in the requirements-gathering phase of UI design. They can be used as a communication medium between you and the users and stakeholders. Low-fidelity prototypes also help users and stakeholders to articulate what they want and need from a system, as they will find it easier to talk about something visual and concrete as opposed to conceptual (or abstract mental) ideas, which can be harder to share.Sketching has many uses in the UI design process. Initially it can be used as a way ofhelping you, the designer, determine what is wanted and needed in a system. Look at Figure 6.2. The designer who made this sketch, Andy, was trying to make sense of a UI design specification for controlling the production of steel tubes. After reading the specification, he sketched his interpretation of what he thought the specification called for, in the presence of the client commissioning the new computer system. Initially Andy used this sketch to communicate with the client and to check that they were both thinking about the system in the same way.Screen mockups can be easily produced using flipcharts, whiteboards, or overhead transparencies and an assortment of different colored pens. You can do this alone, or you can produce your mockups collaboratively with users. Another useful approach to screen mockups is to use not only different colored pens on a flipchart or whiteboard but sticky notes in different colors and differing shapes to represent widgets like buttons and menus. The advantage of using sticky notes as widgets is that you can easily move and change them in response to feedback from the users who are testing your ideas. Storyboards are sequences of sketches or screen layouts that focus on the main actions and interactions in a possible situation. Storyboards take textual descriptions of task flows (such as scenarios) and turn them into visual illustrations of interactions. For example, a workflow analysis storyboard to describe the process of mail merging for a bulk mailing to advertise a product may look something like Figure 6.3. The level of detail contained in a storyboard is related to when in the life cycle it is used. If it is used to model tasks and task flows during requirements gathering, then it will contain more detail than if it is used at the conceptual design stage, where the concern will be with what the system needs to do but not how the system will do it.Paper-based prototypes are quick and inexpensive, and they can provide valuable insights. But they do not demonstrate functionality. For this, we need to turn to highfidelity prototyping. High-fidelity prototypes, which are based on software, provide a functional version of the system that users can interact with. As such, they show the UI layout and its navigation. If the user selects a menu command, such as opening a window or calling a dialog box, he or she will see the command executed; messages, such as error messages, will be displayed as appropriate. The user can experience the look and feel of the final system. Usability testing can be undertaken. In essence, a high-fidelity prototype looks and behaves as if it is the final product and can be used as a tool for marketing the final product. SummaryWe once again emphasize that design should involve the users and be iterative. Typically, requirements gathering collects some information, which is analyzed, and negotiated with the users and other stakeholders. Then another round of requirements gathering takes place. This cycle of requirements-gathering–prototyping– negotiation continues until schedule pressures force the development of the application to begin (this is the normal terminating condition) or until all the stakeholders are satisfied with the requirements (Kotonya and Sommerville, 1998). Designing for usability, therefore, places a strong emphasis on iteration, starting with the testing of early design representations (paper-based and simple software proto- types) with users, undertaking further design or redesign and then testing with users again until the requirements have been agreed. This test with users, redesign, and test again cycle should carry on through to the testing of a full prototype or early version of the system (Wilson and Clarke, 1993). A user-centered, iterative approach attempts to ensure a continuity of testing with users, undertaking further design or redesign and then testing with users again until the requirements are agreed upon.