© richard f. dillon 2002 1 integrating user-interface design into the software development process...
Post on 14-Dec-2015
215 Views
Preview:
TRANSCRIPT
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/
ddillon@ccs.carleton.ca
2© Richard F. Dillon 2002
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
3© Richard F. Dillon 2002
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
4© Richard F. Dillon 2002
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
5© Richard F. Dillon 2002
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
6© Richard F. Dillon 2002
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 )
7© Richard F. Dillon 2002
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
8© Richard F. Dillon 2002
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
9© Richard F. Dillon 2002
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.
10© Richard F. Dillon 2002
UI Challenge
• Get what is in the minds of users
into the hands of developers
• Users don’t design. Designers design
11© Richard F. Dillon 2002
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
12© Richard F. Dillon 2002
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.
14© Richard F. Dillon 2002
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
15© Richard F. Dillon 2002
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
16© Richard F. Dillon 2002
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
© Richard F. Dillon 2002 17
Overview of User-Centered Design
1. User/Task Analysis
2. Set usability goals
3. Design parts of UI, build prototype
4. Test prototype with users
5. Evaluate results of test
If goals not met.
If goals met.
18© Richard F. Dillon 2002
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
19© Richard F. Dillon 2002
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,…?
20© Richard F. Dillon 2002
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
21© Richard F. Dillon 2002
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
22© Richard F. Dillon 2002
Who Does User/Task Analysis
• User Needs Assessment Specialists
• Not engineers & programmers – Generally don’t have interview, survey, questionnaire
design, observation, focus group training
© Richard F. Dillon 2002 23
Overview of User-Centered Design
1. User/Task Analysis
2. Set usability goals
3. Design parts of UI, build prototype
4. Test prototype with users
5. Evaluate results of test
If goals not met.
If goals met.
24© Richard F. Dillon 2002
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
© Richard F. Dillon 2002 25
Characteristics of Usability Goals
• Negotiated by users/developers
• Public
• Measurable
© Richard F. Dillon 2002 26
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
27© Richard F. Dillon 2002
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
28© Richard F. Dillon 2002
Who Sets Usability Goals
• Joint agreement among developers and clients
© Richard F. Dillon 2002 29
Overview of User-Centred Design
1. User/Task Analysis
2. Set usability goals
3. Design parts of UI, build prototypes
4. Test prototypes with users
5. Evaluate results of test
If goals not met.
If goals met.
30© Richard F. Dillon 2002
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
31© Richard F. Dillon 2002
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
© Richard F. Dillon 2002 32
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
© Richard F. Dillon 2002 33
Overview of User-Centered Design
1. User/Task Analysis
2. Set usability goals
3. Design parts of UI, build prototype
4. Test prototype with users
5. Evaluate results of test
If goals not met.
If goals met.
© Richard F. Dillon 2002 34
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
35© Richard F. Dillon 2002
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
36© Richard F. Dillon 2002
Overview of User-Centered Design
1. User/Task Analysis
2. Set usability goals
3. Design parts of UI, build prototype
4. Test prototype with users
5. Evaluate results of test
If goals not met.
If goals met.
© Richard F. Dillon 2002 37
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
38© Richard F. Dillon 2002
Who Makes Evaluation
• Developers and clients, jointly
39© Richard F. Dillon 2002
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?
40© Richard F. Dillon 2002
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
41© Richard F. Dillon 2002
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.
42© Richard F. Dillon 2002
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
top related