ucd-xp03(1).pdf

A DOPTING U SER -C ENTERED D ESIGN WITHIN AN A GILE P ROCESS : A C ONVERSATION

(Cutter IT Journal, October 2003)

William Hudson

Syntagm Ltd

Design for Usability

Abingdon, UK

william.hudson@syntagm.co.uk

eXtreme Programming and other Agile processes provide a middle ground

between chaos and over-elaborate processes sometimes referred to as

“death by documentation”. A particularly attractive aspect of the Agile

approach for many teams is its willingness to accommodate change no

matter how advanced development might be. However, this very flexibility

can cause user interface design issues and ensuing usability problems.

Adopting a user-centered approach to user interface design can address

these issues, as I hope the following simulated conversation between a

user-centered design consultant and an XP team leader will explain.

XP: The team is pretty excited about the improvements we’ve seen in our

development process since moving to XP, but our users are less

enthusiastic. “Easy to use” is not the first phrase to pass their lips and our

support desk is pretty overworked.

UCD: Agile processes focus a lot on making things better for the team,

but they don’t really have much to offer users. Have a look at Figure 1.

User/human-

centered design

User Interface

(extrospective)

Team

Agile

OO design

Archit e cture

(introspective)

Physical world

Figure 1, the relationship between OO, Agile and UI design

OO design concerns itself with the architecture of the underlying system –

primarily in terms of objects and how they communicate with each other

to realize the required functionality. This is a very introspective approach

which use cases 1 were meant to remedy, but unfortunately they mostly

caused confusion. OO design itself has nothing to say about how a project

should be run or how to maximize return on effort.

Agile processes embrace some of the best practices from OO design, but

replace use cases with user stories and address many of the team and

project management issues that have plagued developers for decades.

However, there is still no effort in trying to understand real users’ needs

and no mention of evaluating software through usability testing.

User or human-centered design 2 has virtually no overlap with OO design

and Agile, but provides the missing interaction between those processes

and the physical world. Notice that I am not saying that Agile processes

have no interaction with the physical world, just that those interactions

are not as extensive as many systems require (this is shown by the

dashed arc in the diagram).

XP: But we have a user on the design team. Doesn’t that help?

UCD: A user on the design team is better than no contact with users at

all, but it is not the same as understanding real users’ needs. We do this

primarily by observation and interview, using an approach called

contextual enquiry 3 .

Another issue is that representative users (or user representatives) are

frequently chosen for the wrong reasons. They may be

domain experts;

•

either popular or unpopular with their colleagues (depending on the

method used to select them);

•

either popular or unpopular with management (depending…);

•

1 Use cases describe the interaction between the system and those entities

outside it. In his first paper on the subject, Ivar Jacobson referred to these

external actors as users. Soon after “users” became “actors” and although this

change is not the only cause, use cases have been furrowing brows ever since.

2 ISO standard 13407 refers to “human-centred” design, but really user-centered

and human-centred are the same thing, ignoring also the use of British spelling in

the standard’s title. See [ISO/TC159 1999].

3 A full discussion of contextual enquiry can be found in [Beyer & Holtzblatt

1998].

the most technically competent;

•

geographically well-placed to become part of the development

team.

•

They are almost never typical users. Even if they were, they wouldn’t be

after just a few weeks. By that time they would

be too familiar with the technical aspects of the project;

•

have a vested interest in the solutions chosen;

•

have forgotten what it is like to be sitting alone in a remote location

with no one to help them figure out the latest release of this

mission-critical application.

•

What we try to do in user-centered design is to make sure we understand

the full contexts of use 4 : who the users are, their background, motivation,

responsibilities, roles, the tasks they perform, the frequency and

importance of each plus the physical and social environments in which

they work.

XP: Surely that’s overkill for most projects we’re working on?

UCD: The list of issues is quite lengthy, but of course only a handful are

relevant to most projects. One of the first things we try to do is to

understand which of the contexts of use are important. For example, in

some cases frequency of use is very important either for the system as a

whole or for individual features. In others it may be that users are

working in a stressful environment, such as a call centre, with lots of

background noise and frequent interruptions.

XP: Come on, how would issues like that change what we’re developing?

UCD: Take the example of frequent interruptions. There are several

potential solutions:

•

ensure that users have adequate feedback so they can pick up

where they left off;

allow incomplete information to be saved so they do not have to

abandon an update;

•

design the user interface so that multiple updates can be dealt with

at one time.

•

4 Described in detail in the ISO 13407 standard [ISO/TC159 1999].

XP: But aren’t you talking mostly about interface changes? Why couldn’t

we just sort this out later?

UCD: The difficulty is that most development teams do not realize how

much the user interface can affect the architecture of the system. It varies

from almost negligible impact for simple form-filling applications to

extensive impact for complex and highly-interactive systems. What

typically happens is that well into the development process the team

starts to realize the user interface is becoming very complex or that users

do not understand what they have to do next. (This discovery would be

quite early with regular usability testing but can be as late as product

release when no real users are involved in the development process.) This

can mean major architectural changes to the underlying system as well as

the user interface. Designing the overall structure of the user interface

and the way the application will present itself to users is something that

needs to be done before the system architecture is decided.

Returning to the example we were just discussing, adding adequate

feedback may or may not be an easy user interface change latter on,

depending on the architecture of the system. Allowing incomplete data to

be saved or multiple pending updates is almost certain to require major

architectural changes: the back end system will have to be able to accept

incomplete data; affected records will need to be brought to the user’s

attention; maintaining data integrity in these scenarios can be a

nightmare without a robust architecture to support it. These are not issues

that you want to solve at a late stage of development.

XP: So what is involved? We’re using an Agile process to cut down on up-

front design. Now you’re suggesting we need more.

UCD: Both software and user interfaces suffer from design erosion as they

are modified over time. In software, especially in an Agile process with

only minimal design, there comes a point when the objects making up the

system need to be reorganized so that work can continue on a solid

foundation. This is called refactoring. It works because no one outside the

development team has to live the consequences of what in some cases

are major upheavals. In any event, it is usually possible to draw a line

around a group of objects and refactor just within that group so that there

are no obvious external changes.

Refactoring is possible for user interfaces, certainly in the early stages

before any broad release, but after that it becomes very difficult. Users

need consistency. Changing the name or location of a menu item in a

product that has been released can be very expensive. The primary

tangible side-effects are

documentation or on-line help changes;

•

time users waste trying to find or understand the changed feature;

•

time users waste because of mistakes caused by the change;

•

the consequential cost of errors, especially if external customers

are involved;

•

increased support calls.

•

The intangible consequences include

increased frustration and stress;

•

loss of confidence and fear of change;

•

helplessness, loss of control;

•

resistance to change;

•

confusion and inefficiencies as everyone within the company adapts

to the changes as well.

•

Naturally these side-effects vary according to the type, quantity and

frequency of changes, but generally speaking, alteration of the user

interface needs to be carefully controlled.

XP: But we currently let the team change the user interface on an ad-hoc

basis. I don’t know how we could control this within an Agile process.

UCD: There are several components needed:

contexts of use;

•

personas;

•

user stories;

•

conceptual model;

•

paper prototypes;

•

usability testing.

•

Contexts of use I mentioned before. Once we have these we can identify

some personas and then build a conceptual model from the user stories.

Personas 5 are quite a powerful way of identifying the important types of

5 For a lengthy discussion of personas, see [Cooper 2003].

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: