© simeon keates 2008 usability with project lecture 4 –18/09/09 susanne frennert
Post on 14-Jan-2016
215 Views
Preview:
TRANSCRIPT
© Simeon Keates 2008
Usability with ProjectLecture 4 –18/09/09Susanne 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
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 • (~5000000DKK)
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
PurposeTo 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
top related