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

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

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.2 Waterfall model of lifecycle Requirements specification Architectural design Detailed design Coding Integration & deployment Maintenance

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

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

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

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

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

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

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

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

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

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

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

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

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