1

The Process of Usability Engineering

laura leventhal and julie barnes

2

Sources

Protobook, chpt 4.

3

Building a UI - what do we know or can guess? Principles of UI development are neither obvious nor

intuitive Principles of UI development are not applied as often

as they should be Developing a UI is part of the larger problem of

developing software

4

Software Development is Hard

Some authors believe that software development is in a sort of “crisis” that is characterized by projects which miss deadlines and are delivered with errors.

Numerous strategies to improve the process of software development have been offered including alternative development methodologies and computer-aided tools.

Adding a significant user interface makes software development more difficult.

Software engineering and usability engineering are related. It makes sense to understand a little about the process of software engineering as we are discussing the process of usability engineering.

5

Characteristic Software Development Activities There are activities that have to happen in

software or usability engineering. These include• Understanding and documenting the context

of the project.• Understanding and documenting the problem

to be solved• Designing and documenting a solution in the

context.• Implementing the solution.• Testing and evaluating the solution.

Documenting the outcome of the evaluation.

6

The software explosion (sometimes called "crisis") free falling costs increases the potential

market for s/w burgeoning (diversification of) demand for

functionality size and complexity of s/w is always

increasing What are the big trends driving the field today?

• The Software Crisis• Software Chronic Problem

7

Forget “crisis”

Forget "crisis" according to Pressman, this is a chronic affliction. Symptoms:• s/w takes a long time to develop• costs are high• s/w is often delivered with errors• difficult to measure progress as s/w is

developed

8

Special challenges to UI development The communications explosion The media explosion The usability explosion

9

The communications explosion. Essence of UI used to be one-user,

standalone. Now moving more toward connectivity• Internet• WWW• Businesses wanting CSCW (computer supportee

cooperative work)• Communications services• Expanding user populations

10

The media explosion

User interfaces offer a myriad of devices (media)• Mice, pens, touch screens, video, speech,

VR etc. To support these devices, UI code is

half or more of the code• Gets more complicated, the more the

media (e.g., multimedia)

11

The usability explosion

Users want usability. It is not an option. Users want *availability* (open

architectures)

12

Incorporating UI into SE

Benefits of including UE (usability engineering) as part of SE methodology • The problem: Overhead

13

Software Life Cycle plus UE

The Traditional Waterfall Model suggests a reasonable linear progression of the activities that takes place in Software development

Waterfall model - Escher drawing• systematic, sequential approach to

software development• begins at system level and progresses

through a series of phases

14

Waterfall Picturesystemengineering

analysis

design

code

testing

maintenance

Classic (waterfall) lifecycle model

15

Phases

Systems engineering and analysis Software requirements analysis Software design Code Testing Maintenance

• Memorize for tests and interviews!

16

Maintenance

• If development is 1 year, maintenance could go on for 10 years. Maintenance activities

– Correcting errors– Adding features– Updating software to accommodate

environmental changes such as a new operating system

17

Effort Guessing Game

If my development involves 100 units of effort, how much do I spend on• Specification and design?• Coding?• Testing?

18

Issues for the Waterfall Model

The waterfall model is the oldest and most widely-used paradigm for software engineering.

19

Some benefits:

Following any methodology imposes discipline on the software development process.

It appears to be easy to specify a timetable and costing for s/w developed with the waterfall model.

20

Some problems:

Real problems rarely follow the sequential flow that the model suggests. Iteration always occurs and creates problems in the application of the paradigm.

It is difficult for the customer to state all requirements explicitly. The classic life cycle has difficulty accommodating the natural uncertainty that exist at the beginning of many projects.

Customer must have patience. A working version of the software will not be available until late in the time span.

21

Building a Model that includes UE

Problems with waterfall are especially significant when developing a UI

How could we modify the waterfall model to make it more appropriate for a project that includes a significant UI?

22

Getting real...

Even traditional software engineering projects often benefit from iteration and re-evaluation.

How to know whether to go back or forward? • Prototypes provide a basis for evaluation and

control of iteration• Evaluation can also be based on usability, risk

analysis, projected future costs, expected market value or other criteria.

23

Our model

Our model incorporates• Waterfall phases• UI development phases• Iteration

24

SystemEngineering &Context Setting

RequirementsSpecification

Implementation

Testing

Architectural Design

Low-levelDesign

TaskAnalysis

UserTesting

Implementation

Design

Design

InteractionDesign

InterfaceDesign

SEdevelopmentactivities

UIdevelopmentactivities

Figure 1: Parallel SE and UI development activities

25

Parallel SE and UEActivity Sample SE Activities Sample UE ActivitiesContext Setting Systems Engineering Establishing need for interface.

Req.ts Analysis Understand problem Identify user tasks

Identify interface feature

Identify user characteristics.

Design - High level Architectural Design Design of interaction Architectural design to support interact

Design - Detailed Algorithms, d. structures Design individual interaction Algorithms, d. structures

Implementation Implementation Implementation

Evaluation Testing flow and function Evaluation by experts or user testing Software testing

26

Savings from good UE

Nielsen (1993) describes a number of examples of projects that benefited from good UE

27

Nielsen example (p.3)

• “A major computer company saved $41,700 the first day the system was in use by making sign-on attempts faster for a security application. This increased usability was achieved through iterative design at a cost of only $20,700. 9Darat, 1990)

28

Other SE issues

The Design Team Participatory Design

29

The Design Team

Activities of interface design throughout the software design and life cycle, the interface can't be produced or analyzed at one point by a group of interface specialists.

The job of building a good interface has to be taken on by the team that designs the product as a whole.

30

Design Team Composition

The design team needs to be composed of persons with a variety of skills share several common characteristics. • They need to care about users• They need to have experience with both

bad and good interfaces• They need to be committed to and

optimistic about creating an effective system.

31

Design Team Composition - 2

The team should include representatives from the entire range of interface-related areas: • Software engineers• User interface and human factors specialists• Technical writers• Training package developers• Marketing specialists

32

Responsibility

Designers who create the software shouldn't sign off on their product and hand it off to an entirely separate group that creates the manuals, who then hand off to another group that handles training.

All of these activities need to be coordinated

33

Command/Team Structure

Distribution of activities and communications

– Chief programmer team– Egoless programming

Choice depends on group dynamic and type of problem

– Exploratory problems may work better with egoless programming where familiar well-structured problems may be better with a chief programmer structure.

34

Participatory Design

We have been assuming a split between the roles of designers and customers/users that has been traditional in U.S. system design. Designers generally are not customers or users; they gather information from users and reflect it in systems they build; they give these systems to users who use them or not.

There is an alternative approach, pioneered by workers in Scandinavia, that rejects this structure.

35

Specifics/Participatory Design

In participatory design, systems are designed by designers and customers/users working together: a slogan is DESIGNING WITH rather than DESIGNING FOR.

36

Defining Characteristics

Blomberg and Henderson stress three defining attributes of participatory design (Blomberg, A.L. and Henderson, A. "Reflections on participatory design." In Proc. CHI'90 Conference on Human Factors in Computer Systems. New York: ACM, 1990, pp. 353-359). : •  The goal of the activity is to improve the work life of users • The activity is collaborative, with all goals and decisions

actively negotiated and not imposed • The activity is iterative, in that ideas are tested and adjusted

by seeing how they play out in practice.

37

Why Try Participatory Design Customer Satisfaction

• Having the customer on your development team should help you to define the “right” problem and to hit on the “right” design.

• The customer has a major stake in the project, not only as the customer but as a developer.

38

A Final Participatory Design Thought For commercial projects there are

further challenges. At bottom, your objective as a commercial developer may really not be to improve the quality of somebody else's work life, but rather to make money for yourself. So you don't have the right goal to begin with.

39

Review - The Process of Usability Engineering

Major Topics

• Software Development is Hard

– Are we in a “crisis”

• Adding a significant user interface makes software development more difficult.

• There are activities that have to happen in software development.

– The Traditional Waterfall Model suggests a reasonable linear progression of these phases.

– For some types of projects, including those with a significant user interface, the Waterfall model may not make sense in its traditional linear form.

40

Review - The Process of Usability Engineering (2)

Iteration is the key change to the traditional Waterfall model.• The phases (activities) of the model are the same. The

flow is more fluid.• Evaluation of prototypes is the mechanism that drives

the decision to move backward or forward through the activities.

• Evaluation may be based on usability concerns, risk assessment and so on.

41

Review - The Process of Usability Engineering (3)

There is a lifecycle model for software engineering with usability engineering.

• The model supports iteration• The activities (phases) of the Waterfall model have parallel activities

for software and user interface development. Development of large software and user interface projects typically

happens in teams.• There are different models for team structure.

There are different philosophies for development.• We discuss development assuming that the development team and the

customer are separate entities.• In Participatory Design, customers are part of the Development team.

– This model has the advantage that the customer’s satisfaction should be high.

42

43