Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Richard F. Dillon 2002 1 Integrating User-Interface Design into the Software Development Process Richard F. Dillon Human Oriented Technology Lab Department.

Similar presentations


Presentation on theme: "© Richard F. Dillon 2002 1 Integrating User-Interface Design into the Software Development Process Richard F. Dillon Human Oriented Technology Lab Department."— Presentation transcript:

1 © Richard F. Dillon 2002 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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)

13 © 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 14 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 15 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 16 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 success Without evaluation won’t work People try it without evaluation Changes are made by mutual agreement (including users) based on substantive issues

17 © 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 18 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 19 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 20 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 21 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 22 Who Does User/Task Analysis User Needs Assessment Specialists Not engineers & programmers –Generally don’t have interview, survey, questionnaire design, observation, focus group training

23 © 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 24 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

25 © Richard F. Dillon 2002 25 Characteristics of Usability Goals Negotiated by users/developers Public Measurable

26 © 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 27 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 28 Who Sets Usability Goals Joint agreement among developers and clients

29 © 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 30 Rapid UI Prototypes Get 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 31 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

32 © 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

33 © 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.

34 © 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 35 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 36 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.

37 © 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 38 Who Makes Evaluation Developers and clients, jointly

39 © Richard F. Dillon 2002 39 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 40 Our Experience: The Plus Side 1.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 41 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 42 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


Download ppt "© Richard F. Dillon 2002 1 Integrating User-Interface Design into the Software Development Process Richard F. Dillon Human Oriented Technology Lab Department."

Similar presentations


Ads by Google