© richard f. dillon 2002 1 integrating user-interface design into the software development process...

1© Richard F. Dillon 2002

Integrating User-Interface Design into the Software Development Process

Richard F. Dillon

Human Oriented Technology Lab

Department of Psychology

Carleton University

Ottawa, Canada

K1S 5B6

1- (613) 520-6629

http://www.carleton.ca/cure/

[email protected]


My message today

• Products that don’t meet user needs won’t be competitive

• Traditional engineering training doesn’t prepare you to meet user needs

• User-centred design methods and techniques are available

• Either learn those techniques or get someone on your team who knows them


User Interface Economics

Good user interface will result in:

• Increased productivity

• Reduced training costs

• Preventable user errors

• Reduced employee turnover

• Good system utilization

• User satisfaction

• Return to your web site

• Being able to use your appliance


Computers and Productivity

Use of computers increased exponentially • White collar productivity actually went down (Michael Dertouzos of MIT

for US Government)

•See also Landauer, T. K. The trouble with computers, 1996, MIT Press ISBN: 0262121867

(estimates that by 1996, poor usability had cost the US economy $600 billion in lost productivity)

During the last 20 years


Why Are User Interfaces Poor?

• Inadequate training of developers

• Lack of basic science

• Rapid technological advances

• Inadequate knowledge of task domain

• Reluctance of companies to commit resources

• Poor management


Lack of Real Engineering of The UI

UI specialists not involved

The "bricklayers" (programmers) are left to do the UI architecture by default

"Ignorance by software engineers of usability and how to measure it is roughly equivalent to an electronics engineer not knowing what volts and watts are and how to measure them."

(Tom Gilb, Principles of software engineering management, 1988, Addison-Wesley, ISBN: 0201192462 )


Common Myths About User

Interface Design• The quality of user interface doesn't matter

• Functionality in your software is so good, users will buy it in spite of the poor user interface

• Designers can design good interfaces by relying on interface guidelines and principles

• Programmers and engineers (or graphic artists) without UI training can design good user interfaces


Myths (cont'd)• All you need to design good UI is a good UI

toolkit (or GUI HTML editor)

• You can design good interfaces without contact with users

• Web navigation -- just provide links

• User interface design can be added on after the rest of the product is designed

• Usability is subjective and cannot be measured or "engineered"

• User interface design can be done right the first time


Why User-Centered Design

Task Skills

Computer skills

Novice

Expert

Novice Expert

Designers

Users

1. There is a mismatch of skills between designers and skilled users.

2. Design must not force skilled users to change.

• By becoming computer experts.

• By using tools designed for novices in their field.


UI Challenge

• Get what is in the minds of users

into the hands of developers

• Users don’t design. Designers design


User-Centred Project Life Cycle

Project Definition

Organization and Information Gathering

Functional Design

System Architecture Design

Module Design

Coding

Module Testing

System Testing

Implementation

User Definition

Goal and Priority Setting

Write the Style Guide

Design Walkthroughs

UI Prototyping

Usability Testing

Implement Style Guide

Acceptance Test


Users and tasks

• Impossible to meet users needs without knowing– What they want to do

– How they think

– How they work

– Constraints they work under

– Expectations and habits (including mental models)

© Richard F. Dillon 2002 13

Overview of User-Centred Design

1. User/Task Analysis

2. Set usability goals

3. Design parts of UI, build prototypes

4. Test prototype with users

5. Evaluate results of test

If goals not met.

If goals met.


The "Big Bang" Approach

The entire dream system … After five years of effort

... or nothing at all (Tom Gilb)

also see Scientific American, September 1994, Gibbs, Trends in Computing: Software's Chronic Crisis

Available for $5.00 at http://www.sciamarchive.com/welcome2.asp?Sid2=PjEoFaFbJbGDhjMfsk


Shortcomings

• What you deliver isn't what people need.

• Over budget, overdue, underutilized

- Cost estimates are notoriously inaccurate

- Schedules are notoriously inaccurate

• Emphasizes the delivery itself rather than the quality of the deliverable


A Mechanism for Changing UI Requirements

Everyone expects changes

Budget is designed for changes

Prototype provides a good idea whether change will work or not before you implement it

Evaluate for successWithout evaluation won’t work

People try it without evaluation

Changes are made by mutual agreement (including users) based on substantive issues


Overview of User-Centered Design



3. Design parts of UI, build prototype



If goals not met.

If goals met.


User and Task Analyses

• Determine functionality required

• Understand relevant user constraints and opportunities

• Identify opportunities for organizing functionality

• Based on, but not limited to, what is done currently and how it is done

• Result of user/task analyses is what is required, not how to do it


User analysis

• Information about users that will have an impact on the design.

• If it won’t have an impact on the design, don’t bother with it

– Sex, age, education,…?


User Analysis

• Common assumptions that are wrong– All users are alike

– All users are like me

– A person is either a novice or an expert

– User characteristics don’t matter for this product

– I (designer) know what is best for user (Fascist UI design)

– I can design a good UI without having to understand the user


Task Analysis

• High-level conceptual understanding of – what users will do with the product

– Users objectives

– Domain conventions including terminology and working procedures

• Appropriate task descriptions will help you think about better ways than currently used


Who Does User/Task Analysis

• User Needs Assessment Specialists

• Not engineers & programmers – Generally don’t have interview, survey, questionnaire

design, observation, focus group training








If goals not met.

If goals met.


Typical Classes of Goals

(Sometimes called usability metrics)

• Ease of learning– Time to learn

– Discoverability (can they learn without documentation?)

• Efficiency of use after learned– Throughput

– Power use

• Satisfaction– What if they can learn it and use it effectively, but they don’t

like it

• Error rates


Characteristics of Usability Goals

• Negotiated by users/developers

• Public

• Measurable


Reasons for Usability Goals

1. Structured communication between designers and users throughout the design effort.

2. Expectations for system are objective, not subjective.

3. Usability is measurable and made part of the engineering effort along with deadlines, budget, machine performance.

UI gets program, personnel and budget.

Usability goals considered in trade-off meetings


Reasons for Usability Goals (cont’d)

4. Usability goals provide stopping rules for iterative design

5. Flexible, use good judgment

6. Especially important when disputes arise

7. Essential for targeted usability testing


Who Sets Usability Goals

• Joint agreement among developers and clients


Overview of User-Centred Design



3. Design parts of UI, build prototypes

4. Test prototypes with users


If goals not met.

If goals met.


Rapid UI PrototypesGet user feedback

• Users experience part of UI rather than speculate about it. Prototypes are tools for structured communication with users

Find UI errors and weaknesses

Evaluate specific UI areas of concern

Enable comparison among alternatives

Generate new ideas

Serve as UI specification

Essential for evolutionary design


Characteristics of Prototypes

Must be easy to make prototypes

Must be easy to modify prototypes

Paper prototypes early in project

Use a good prototyping language


Prototypes in Requirement Definition

Myth: User can tell developer what they need and how they need it with no experience using the system.

• An interactive system requires interactive specification

• People can't tell what their house will be like from blueprints

• Prototype = working model as a means for developers and users to communicate and iterate the specification.

Myth: Developers can tell what a UI will be like without using it








If goals not met.

If goals met.


1. Requires only a few users

2. Must be structured.

Don't just ask users to try system

3. Structure must reflect real user tasks

4. Must be "problem oriented "

Base user test on what designers need to know

5. Must be timely

6. Must involve members of the user group

7. Must involve quantitative measurement

8. Takes careful planning and work to do it right

Key Points about Usability Testing


When to Usability Test

Everybody does usability testing.

Trick is to do it before delivering

• Never too early to usability test.

• As soon as first paper prototype is available

• After working version is available is too late.

• Continuous process throughout the project

• Expect a number of iterations

• Means to reduce risks








If goals not met.

If goals met.


Evaluation of Results

Evaluate against usability goals

If usability goals are not met:

Change design

• If usability goals are met

– Freeze design

• The process without evaluation won’t work


Who Makes Evaluation

• Developers and clients, jointly


Do development teams use this approach?

• Don't know of any projects that use the whole user-centred design package

• Don't know any good development teams that don't use some of the tools

– Identify weaknesses & missing information

– Choose appropriate techniques to fill in

• People without training trying to do it– Not likely to succeed

– Can you take the risk?


Our Experience: The Plus Side1. When user-centred design methodology has been

applied• High user acceptance in the user tests

• Users positive about role as co-designers

2. We are always amazed at how much we learn from • User/task analysis

• Setting usability goals

• Building prototypes

• a well-designed usability test

3. Every part of the process we have ever been involved in has resulted in improvements


Our Experience: The Minus Side

1. Underestimate resources for process, especially usability testing.

2. Communication problems frequently occur.

3. Testing is always later in design than desirable.

4. Clients have tended to want a usability test without the whole user-centred design approach.

5. A poorly conceived usability test is worse than no usability test.


My message today

• Products that don’t meet user needs won’t be competitive

• Traditional engineering training doesn’t prepare you to meet user needs

• User-centred design methods and techniques are available

• Either learn techniques or get a specialist on your team who knows them

© richard f. dillon 2002 1 integrating user-interface design into the software development process...

Documents

userinterface design

good user interfaces

links user interface

user interfaces poor

poor user interface

user needs wont

good interfaces

ui training