© simeon keates 2008 usability with project lecture 4 –18/09/09 susanne frennert

© Simeon Keates 2008

Usability with ProjectLecture 4 –18/09/09Susanne Frennert


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!


Your presentations

Over to you…


Approaches to design


Approaches to design (source: Keates and Clarkson “Countering design exclusion”)


A stage-based model of the design process (source: BS7000: 1 “Guide to managing innovation”)

No representation of “iteration”


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”


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?”


The waterfall model


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


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


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


An example of a systems approach: The “V-model”


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…


Shigley and Mischke – Optimisation and iteration


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


A practitioner’s model of design – The IDEO approach


Another view of design

A product-centred approach:

A user-centred approach:

Product

Product


The user-loop: A model of user involvement in design


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


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


Heuristics as a design approach


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


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…


An example – The EPI-RAID robot

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


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

Needed a user-centred design approach!


Question

Can we use Nielsen’s heuristic in the design process?

i.e. not just for post-hoc testing


Exercise


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


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

© simeon keates 2008 usability with project lecture 4 –18/09/09 susanne frennert

Documents