1. User-centred system design process
Chapter 4
User-centred system design process

2. By the end of this chapter you should be able to...
Identify weaknesses in traditional methods of software development
Describe individual methods that make up a UCD process
Apply UCD methods in the development of interactive computer systems

3. Traditional software development process
Traditional methods have “system” or “technology” focus
User interface often designed around a technical view of how system works
Problem partly lies with process by which systems are developed

4. 4.2 Waterfall model of lifecycle
Requirements specification
Architectural design
Detailed design
Coding
Integration & deployment
Maintenance

5. 4.2 Weaknesses of Waterfall model
User often ignored
User’s preferences and abilities are overlooked
Reflect views of designer only (familiarity paradox?)
Designer may overlook an omission because they have that information in their mind – may not even be aware that they do it
Designer will not have difficulty to find information in hidden places, because they placed it there
Process that is easy for designer might prove difficult for user
UI designed around technical view of how system works, e.g. adding new functions at expense of user needs
Processes by which system is developed is problematic
Sequential
Get it right first time
Poor model of reality: does not indicate that designers switch back and forth and apply new insights and ideas
Design should be done iteratively with high level of evaluation

6. 4.3 Stages of the Waterfall model
Requirements specification
Functional requirements. Example?
Data requirements (Inputs and outputs). Example?
Environmental requirements (context). Example?
User requirements. Example?
Usability requirements. Example?
Architectural design
Focus on how requirements can be achieved
E.g. OO, UML, ERD
Detailed design
E.g. specification of classes, objects, methods and properties
Coding and testing
Produce software of components & test thoroughly
Integration and deployment
Integrate individual components – note relationships
Testing / evaluation by users (e.g. heuristics / external standards)
Maintenance
Usage may identify further errors

7. Communicating a mental model via Waterfall model
What marketing
suggested
What management
approved
As designed by
engineering
What the customer
wanted
What was manufactured
What was installed

8. Ordering of activities
4.4 UCSD
Problem
statement
Observation of
existing systems
Outputs/Artefacts
Task analysis (Ch 5)
HTA
Requirements statements
Functional
Non-functional
Requirements
Gathering (Ch 6)
Usability guidelines
and heuristics
Technical, legal and
other constraints
Design and
Storyboarding (Ch 6)
Storyboard
Prototype
Implementation (Ch 6)
Prototype
Key
Activity
Transcript and
evaluation report
Evaluation (Ch 9)
Flow of information
Installation
Final implementation
Ordering of activities

9. UCSD Key aspects The basic idea
Analyse users and their world
Evaluate ideas, ideally with potential users
Test to be sure design works well with users
and iterate!
Users and consideration of user needs and capabilities at the centre of the design process
Users involved at every stage
Designers encouraged to revisit earlier stages if improvements can be made

10. 4.5.1 Task analysis... Inputs Output Why?
Problem statement
Observation of existing systems
Analysis of user population
Output
A ‘hierarchical task analysis’
Why?
A clear understanding of what clients want
A clearer understanding of what users want
Very rare that something completely new is designed
Usually something old/existing is redesigned
Task analysis encourages:
Understanding of the old system
Understanding what’s good/bad about it
Initial ideas about how to redesign

11. Task analysis: Example of ATM - Expand
0. Withdraw cash
Check machine will work
1.1 Look at status indicator
1.2 Look for card logo
Insert card
Enter PIN
Initiate withdrawal transaction
4.1 Select “Withdraw cash”
4.2 Enter amount
Complete transaction
5.1 Take card
5.2 Take cash

12. 4.5.2 Requirements gathering
Inputs
Hierarchical task analysis
Design heuristics
Relevant user models
Usability principles
Other constraints (e.g. external standards, hardware platform)
Output
Requirements statement
Functional (task-related)
Non-functional (Usability)
Why?
Testable, explicit description of what is wanted of the system
Describes what the system should do without worrying too much about how it does it

13. 4.5.3 Design and storyboarding
Inputs
Requirements statement
Usability principles, heuristics, etc.
Other constraints (e.g. standards)
Evaluation of previous iterations
Outputs
Storyboard design (pen and paper sketch)
Justification: Why the system is going to be the way it is
First draft design: How the system works and what it looks like
Stakeholder needs analysis
Why?
Provides designers with opportunity to visualise their design and to review it with potential users and members of the design team
Quick and cost-effective

14. 4.5.4 Prototype implementation
Inputs
Storyboard design
Evaluation from previous iterations (tweaks)
Outputs
Working, testable prototype
Why?
Get something that real users can usefully test at low cost
Types
Wizard of Oz: Controlled by designer behind the scenes
Horizontal: Simulates UI with no functionality
Vertical: Full functionality but for limited vertical slice of system
Full: Complete functionality but low performance

15. 4.5.5 Evaluation Inputs Output Why? How? Working prototype
Requirements statement
Output
Transcripts: What was said or done during evaluation
Evaluation report: Are requirements met? If not, why not?
Why?
Tangible evidence of how the system is actually used
How?
Heuristic evaluation
Most common approach
Relatively quick and cost-effective
Teams of around five evaluators
Inspect system/prototype based on set of heuristics (checklist of usability characteristics)
Discuss findings
Scenarios: understanding how users will generally use system

16. 4.5.6 Installation Inputs Outputs Why? Fully featured ‘prototype’
Acceptable evaluation
‘Finished’ system
Why?
UCSD recognises that systems continue to evolve
Post-installation experience provides valuable feedback for further iterations

17. Summary
User centred design places the users, their goals, needs & activities at the centre of the design process
Involves a re-think of traditional development processes
Key aspects are evaluation and iteration