Chapter 1 Important Things:

Usability “the extent to which a product can be used by specified users to achieve specified goals with

effectiveness, efficiency and satisfaction in a specified context of use.”
Effectiveness is the accuracy and completeness with which specified users can achieve specified

goals 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 affected

by its use.

User-centered design (UCD) is an approach to user interface design and development

that 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 you

started. 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 with

them.

Chapter 2 Important Things:

Direct Observation

Direct observation is a straightforward activity and will rapidly provide you with an

insight into the users, their tasks, and the environment for a computer system. Direct

observation can be undertaken in many ways, but generally direct observation

studies are classified as either field studies or controlled studies. Field studies directly

observe users in their usual work or home environment, doing their normal work or

home tasks, with the observer making notes about interesting behaviors. Controlled

studies directly observe users in a place other than their normal environment (for

example, in a usability laboratory), performing specially devised tasks, with the

observer recording their performance in some way, such as by timing tasks or particular

sequences of actions.

Indirect Observation: Video Recording

Video recording on its own is an alternative to direct observation as it provides a permanent

record of the observation session. Sometimes video recording may be used

with software that automatically logs users’ keystrokes or interactions. Although collecting

several kinds of information can be beneficial, it means that there is more

data to analyze, which can be time consuming. Because indirect observation creates

more distance between observers and users, it is considered to be more objective

than 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 consumer

video equipment, especially now that small digital video recorders are available at a

reasonable price. However, there are some important issues to consider. You need to

plan the observation, which means thinking about what you want to find out and

what kind of data you need. For example, in a study of the way that people use a UI

in the context of their own workplace, it may be useful to record samples of them

using the UI every day over a period of several days or weeks. These interaction

samples could then be analyzed; categorizing the activities, for example, will tell you

what the UI is used for, what work it helps the users to do, or how often a particular

task is done. A study with quite a different and much finer focus might involve an indepth

examination of two users interacting with the UI over a period of just five

minutes.

Interviewing Your Users

Interviewing 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 Surveys

Questionnaires 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 they

are used where there are no predetermined answers. Open questions typically start

with phrases such as “What do you . . . ,” “How do you . . . ,” or “What ways . . . .” Limiting

the amount of space on the form for the answer can encourage respondents to

prioritize their points (Rubin, 1994). Open questions provide richer data than do

closed questions, although the responses will be more time consuming to analyze as

you you need to read each one and decide on some way of grouping and classifying

them. If you have a fairly small sample, say up to 100 respondents, it may be quicker

and 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, and

questionnaires/surveys. Any or all of these techniques can be used in the

requirements-gathering phase of UI design. Complementary investigative techniques

are often used in combination; for example, you might use a questionnaire

and also undertake some interviews, or you might use a questionnaire and also

undertake some observation studies. This enables the strengths and weaknesses of

the various techniques to be balanced.

Chapter 3 Important Things:

Traditionally, the classic software design life cycle focuses on the system’s requirements

rather than the users’ requirements. As we emphasized in Chapter 1, a usercentered

design approach focuses instead on the importance of the user. In Chapter

2 we discussed some suitable techniques for gathering requirements. Keeping the

user uppermost in your mind, you should undertake the following activities in gathering

the 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 will

have something to say about the system. But you must also remember to

observe 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, it

is important to be consistent throughout the UI. For example, you should use

colors in a consistent manner. If you use red to indicate danger, then always use

red, rather than red sometimes and green at other times. The same applies to

screen 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 using

their prior knowledge, this provides the opportunity to draw on their

experience. A screen metaphor, such as the calculator that comes with the

Microsoft Windows operating system, does this by presenting users with a

familiar image that allows them to apply their prior knowledge and experience

of 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. For

example, the screens in Figure 5.3 both represent the same information.

However, part (a) has been grouped into categories and part (b) has not. The

lack of structure in part (b) makes it difficult to find information.

The principle of importance: If something is important for the user, it should be

placed in a prominent position. For example, alarm and warning messages are

often placed in the center of the screen, blocking the work that the user is

carrying 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 player

on/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 property

of affordance, the design of the control should suggest (that is, afford) how it is to be

operated. For example, buttons afford pressing. Norman defines affordance as

“strong clues to the operations of things. . . . When affordances are taken advantage

of, the user knows what to do just by looking: no picture, label, or instruction is

required” (Norman, 1988, p. 9). When the affordances of an object or device are

obvious, it is easy for us to know how to interact with it. Affordances play a large part

in the design of objects, but what is important is perceived affordance—what a

person thinks can be done with the object. Using the example of a cassette player

again, what kind of controls are used? If buttons are used, do they afford pushing? If

sliders are used, do they afford sliding? If knobs or dials are used, do they afford

turning? Unfortunately, practicality sometimes conflicts with good affordance and

the 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 Requirements

Usability 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 use

performance (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-Offs

As 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 requirements

Low-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 of

helping 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.

Summary

We 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.

	Erstellt von Lokman Musliu vor fast 10 Jahre

Notiz am Human Computer Interaction, erstellt von Lokman Musliu am 04/02/2015.

Human Computer Interaction