© Simeon Keates 2008 Usability with Project Lecture 4 –18/09/09 Susanne Frennert

© Simeon Keates 2008 Use of the heuristics Use is two-stage 1 – To indicate the types of areas to consider when looking for problems 2 – To classify the problems when you find them Remember – look for problems, then classify Not the other way around! Page 2

© Simeon Keates 2008 Your presentations  Over to you… Page 3

© Simeon Keates 2008 Approaches to design Page 4

© Simeon Keates 2008 Approaches to design (source: Keates and Clarkson “Countering design exclusion”) Page 5

© Simeon Keates 2008 A stage-based model of the design process (source: BS7000: 1 “Guide to managing innovation”) Page 6 No representation of “iteration”

© Simeon Keates 2008 An alternative stage-based approach  Clarification of the task Take vague idea/market need and identify true requirements and constraints OUTPUT: “Design specification”  Conceptual design Generate concepts with the potential to meet the functional and phsyical requirements in the design specification OUTPUT: “Concept”  Embodiment design Lay foundation of detail design through structured development of concept OUTPUT: e.g. detailed layout drawing  Detail design Specify precise shape, dimensions, tolerances, etc. OUTPUT: e.g. “blueprints” Page 7

© Simeon Keates 2008 Better models of design  Stage-based models typically focus on modelling process of design  More emphasis needed on meeting the product’s acceptability targets  Need to add 2 important questions: Verification: “Are we building the product correctly?” Validation: “Are we building the correct product?” Page 8

© Simeon Keates 2008 The waterfall model Page 9

© Simeon Keates 2008 The waterfall model Assumes that All the requirements are identified by the start All the system is analysed All the system is designed All the system is written All the system is tested All the systems is handed over to the client There is only one run through the life cycle Page 10

© Simeon Keates 2008 Problems with waterfall model  Assumes logical development of ideas. It assumes that one stage finished before the next one starts. What if the stakeholders thinks of important requirements later in the project? What if the stakeholders requirements change during the project?  Users are not involved in the validation until acceptance testing (in the end) What if the system handed over to the client does the wrong thing?  The idea of iteration was not embedded in the original waterfall model Page 11

© Simeon Keates 2008 A “systems” approach to designing  Evaluation of acceptability (verification and validation) is crucial  Provides evidence of “performance” (whether good or not)  Additionally, evaluation of product must be done in context of its use  For genuine usability (and inclusivity): where the product is part of a system, the entire system should be evaluated  Where the product is a service, the entire service delivery chain should be evaluated Page 12

© Simeon Keates 2008 An example of a systems approach: The “V-model” Page 13

© Simeon Keates 2008 Iterative models of design  Most “classical” models still represent design as largely “linear”  In reality, most design is iterative (design, evaluate, design, evaluate…)  Newer models reflect this… Page 14

© Simeon Keates 2008 Shigley and Mischke – Optimisation and iteration Page 15

© Simeon Keates 2008 Other approaches to design  All models so far are “engineering” models of design Focus on “practical acceptability” i.e. utility and usability  Alternative approach from “product” design More focus on “social acceptability” i.e. aesthetics, desirability and branding Page 16

© Simeon Keates 2008 A practitioner’s model of design – The IDEO approach Page 17

© Simeon Keates 2008 Another view of design  A product-centred approach:  A user-centred approach: Page 18 Product

© Simeon Keates 2008 The user-loop: A model of user involvement in design Page 19

© Simeon Keates 2008 The three principles of user centred design are  Early focus on users and tasks Understanding who the users will be, by directly studying their characteristics  Empirical measurement Users’ reactions and performance to scenarios, simulations, and prototype are observed, recorded and analysed  Iterative design When problems are found in user testing, they are fixed and more tests and observations are carried out Page 20

© Simeon Keates 2008 Four basic activities in the design process 1. Identify needs and establish requirements 1. Design potential solutions ((re)-design) 1. Choose between alternatives (evaluate) 1. Build the artefact Page 21

© Simeon Keates 2008 Heuristics as a design approach Page 22

© Simeon Keates 2008 Five attributes of Usability (Nielsen, 1994)  Learnability : system is easy to learn so users can get started quickly  Efficiency: system should be easy to use, resulting in high productivity  Memorability: system should be easy to remember  Errors: system should have low error rate and allow error recovery  Satisfaction: system should be pleasant to use Page 23

© Simeon Keates 2008 Setting the scene  “Rehabilitation Robotics in Europe” c.1997  EU funded many projects under TIDE initiative  LOTS of money!!!  Projects generally major disasters  Let’s see why… Page 24

© Simeon Keates 2008 An example – The EPI-RAID robot Page 25 The RAID workstation allows users to move books from a book shelf to a reader board and back again turn single and multiple pages in books discard documents staple documents insert floppy disks insert CD-ROMs drink with a straw

© Simeon Keates 2008 EPI-RAID failed because…  No in-built market to sell to Had to sell on its own merits  Too expensive (~ DKK)  Overtaken by new technology Internet  Not enough consideration of what it was to be used for Too much focus on the technology Page 26 Needed a user-centred design approach!

© Simeon Keates 2008 Question  Can we use Nielsen’s heuristic in the design process?  i.e. not just for post-hoc testing Page 27

© Simeon Keates 2008 Exercise Page 28

© Simeon Keates 2008 Exercise  Work as a group  Write a script (task analysis) for how you envisage each of your personas would use your site  Try to follow that script using your site  Log any problems you encounter  Then try another group’s site (more if you have time)  Make any changes to your site based on your evaluations Page 29

© Simeon Keates 2008 Task scenarios Purpose To provide examples of usage as an input to design, and to provide a basis for subsequent usability testing. Scenarios specify how users carry out their tasks in a specified context. To maintain design flexibility, they should not specify what product features are used Try to generate scenarios to cover a wide range of situations, not just the most common ones or those of most interest to you Try to include problem situations that will test the system concept, not just straightforward scenarios Work through the scenarios fully and judge the system on that basis rather than trying to change the system half way through Page 30