Prototyping

74
HCI – PROTOTYPING Eman Abed AlWahhab 1

description

Prototyping in HCI

Transcript of Prototyping

Page 1: Prototyping

1

HCI – PROTOTYPING

Eman Abed AlWahhab

Page 2: Prototyping

2

PROTOTYPING

A limited representation of a design that allows users to interact with it and to explore its suitability

Allows stakeholders to interact with the envisioned product, gain some experience of using and explore imagined uses

Production of an intermediary product to be used as a basis for testing

Aim is to save on time and money Aim is to have something that can be tested with real

users

Page 3: Prototyping

3

PROTOTYPING

you never get it right first time if at first you don’t succeed …

prototype evaluatedesign

re-design

done!OK?

Page 4: Prototyping

4

PITFALLS OF PROTOTYPING

moving little by little … but to where

1. need a good start point 2. need to understand what is wrong

Page 5: Prototyping

5

ADVANTAGES & DISADVANTAGES OF PROTOTYPING

Advantages Disadvantages

Users can try the system and provide constructive feedback during development

Each iteration builds on the previous iteration and further refines the solution. This makes it difficult to reject the initial solution as inappropriate and start over.

An operational prototype can be produced in weeks

Formal end-of-phase reviews do not occur. Thus, its is very difficult to contain the scope of the prototype.

Users become more positive about implementing the system as they see a solution emerging that will meet their needs

System documentation is often absent or incomplete, since the primary focus is on development of the prototype.

Prototyping enables early detection of errors System backup and recovery, performance, and security issues can be overlooked.

Reference: http://facpub.stjohns.edu/~wolfem

Page 6: Prototyping

6

JOURNEY OF THE PROTOTYPING PROCESS

Goals

Functionality Evaluate

Develop

Page 7: Prototyping

7

GOALS OF PROTOTYPINGPrototyping enables evaluation, happens

throughout Exploring requirements

Market analysis, participatory design, envisionment Choosing among alternatives

Risky or critical features, go/no-go decisions Empirical usability testing

As early as possible, try out ideas with target users Evolutionary development

May deliberately choose a malleable software platform, building software in incremental, iterative fashion

Page 8: Prototyping

8

WHY PROTOTYPE

Evaluation and feedback are central to interaction design

Stakeholders can see, hold, interact with a prototype more easily than a

document or a drawing

Team members can communicate effectively

You can test out ideas for yourself

It encourages reflection: very important aspect of design

Prototypes answer questions, and support designers in choosing between

alternatives

Page 9: Prototyping

9

WHY PROTOTYPE

Traditional software development: you can’t test until you implement

Implementation is expensive, and there is nothing to test until you have made that expenditure of effort and schedule time

Result: any design errors are built in to the first thing you can test, and it is very expensive to make changes

Result: design errors, unless they are really bad, are left in the product

Page 10: Prototyping

10

BREAKING THIS IMPLEMENTATION PARADOX

Build a prototype of the basic functionality, especially the interface

Test the prototype, which will uncover design errors

Correct the errorsRepeat until you have a clean designA major tool for improving usabilityHeavily used in industry

Page 11: Prototyping

11

WHAT IS PROTOTYPED ?

Technical issues

Work flow, task design

Screen layouts and information display

Difficult, controversial, critical areas

Page 12: Prototyping

12

WHAT IS A PROTOTYPE

In interaction design it can be any of the following (and more): A series of screen sketches A storyboard, i.e. a cartoon-like series of scenes A PowerPoint slide show A video simulating the use of a system A lump of wood or a cardboard mock up A piece of software with limited functionality written

in the target language or in another language

Page 13: Prototyping

13

PROTOTYPE REPRESENTATION

How to represent the prototype? Mockup Storyboard Sketches Scenarios Screenshots Functional interface

Page 14: Prototyping

14

USE TAGLINES / CAPTIONS

Keep it short: show as much as necessary but not more

Page 15: Prototyping

15

MOCKUPS / WIREFRAMES

Good for brainstorming Focuses people on high-level design notions Not so good for illustrating flow and the details

Page 16: Prototyping

16

FIDELITY

Degree to which prototype accurately represents the appearance and interaction of the product

Judged by how it appears to the person viewing it Not similarity to actual application Not the degree to which the code and other

attributes invisible to the user are accurate

Page 17: Prototyping

17

FIDELITY SPECTRUM

High Fidelity Close to final product Electronically faithful Uses similar media

Low Fidelity Basis for final product Proof of concept Use of low cost, non-electronic media

Page 18: Prototyping

18

HIGH FIDELITY PROTOTYPING

Represent core functionality of product’s user interface

Can be so realistic that user can’t tell them from product.

Fully interactive possible to enter data use widgets

Simulate functionality of final product Can be horizontal or vertical or both

Page 19: Prototyping

19

Uses materials that you would expect to be in the final product.

Prototype looks more like the final system than a low-fidelity version.

For a high-fidelity software prototype common environments include Macromedia

Director, Visual Basic, and Smalltalk. Danger that users think they have a full

Page 20: Prototyping

20

LOW FIDELITY PROTOTYPING

prototyping fast process no reuse of code (often there is no code) produces prototype early during requirements

specifications phase Types of Lo-Fi Prototyping

Scenarios Paper Prototyping Storyboards Screen Shots

Page 21: Prototyping

21

Uses a medium which is unlike the final medium, e.g. paper, cardboard

Is quick, cheap and easily changed Examples:

sketches of screens, task sequences, etc ‘Post-it’ notes storyboards ‘Wizard-of-Oz’

Page 22: Prototyping

22

SKETCHES Drawing of the outward appearance of the

intended system Crudity means people concentrate on high level

concepts But hard to envision a dialog’s progression

Computer Telephone

Last Name:

First Name:

Phone:

Place Call Help

Page 23: Prototyping

23

Page 24: Prototyping

24

Page 25: Prototyping

25

SKETCHES

Generally for depicting physical aspects of system

Page 26: Prototyping

26

STORYBOARDING A series of key frames as sketches

Originally from film; used to get the idea of a scene Snapshots of the interface at particular points in the

interaction Users can evaluate quickly the direction the interface

is heading

Page 27: Prototyping

27

Scan the stroller ->

Change the color ->

Place the order ->

Initial screen

Page 28: Prototyping

28

Scan the shirt ->

Touch previous item ->

Delete that item->

Alternatepath…

Page 29: Prototyping

29

STORYBOARDS

Often used with scenarios, bringing more detail, and a chance to role play

It is a series of sketches showing how a user might progress through a task using the device

Used early in design

From Design for the Wild, Bill Buxton (in press) with permission

Page 30: Prototyping

30

• Index cards (3 X 5 inches) • Each card represents one screen• Often used in website development

USING INDEX CARDS

Page 31: Prototyping

31

ELEMENTS OF A PAPER PROTOTYPEMenu Bar

ScrollBar

Secondary Menu

Opening Contents

31

Page 32: Prototyping

32

THEIR HOME PAGE

Page 33: Prototyping

USER “CLICKS ON” (POINTS TO) CLUBS BUTTON

33

Page 34: Prototyping

THE MUSIC PAGE

34

Page 35: Prototyping

THE HOME PAGE

35

Pulldown menu

Page 36: Prototyping

36

A SECOND-LEVEL PAGE

Page 37: Prototyping

37

ANOTHER SECOND-LEVEL PAGE

Page 38: Prototyping

38

AFTER PROTOTYPING AND USER TESTING, THIS IS WHAT THEIR HOME PAGE LOOKED LIKE

Page 39: Prototyping

39

PROTOTYPE SCOPE How much to represent?

Vertical - “Deep” prototyping Show much of the interface, but in a shallow manner

Horizontal - “Broad” prototyping Show only portion of interface, but large amount of those

portions

Page 40: Prototyping

40

‘WIZARD-OF-OZ’ PROTOTYPING• The user thinks they are interacting with a

computer, but a developer is responding to output rather than the system.

• Usually done early in design to understand users’ expectations

>Blurb blurb>Do this>Why?

User

Page 41: Prototyping

41

COMPARISON OF TWO PROTOTYPING EFFORTS

Page 42: Prototyping

42

GENERAL FEATURES OF PROTOTYPING Enables the designer to quickly build or create

examples of :- The data entry form The menu structure and order The dialogue styles Error messages

Should be inexpensive to develop – intention is to discard/modify it

Should not require programming skills

Page 43: Prototyping

43

PROTOTYPING TECHNIQUES

The three major kinds of prototyping are “Throw away” prototyping ( “rapid prototyping”)

used exclusively in requirements gathering Incremental prototyping

not actually prototyping at all, but the delivery of prioritised functions incrementally to a single, overall design

Evolutionary prototyping (“Rapid Application Development, RAD) as for incremental prototyping but with evolving design

Page 44: Prototyping

RAPID PROTOTYPING

Aims to collect information on requirements and the adequacy of possible designs

Recognises that requirements are likely to be inaccurate when first specified

The emphasis is on evaluating the design before discarding it

44

Page 45: Prototyping

RAPID PROTOTYPING -ADVANTAGES

Helps the designer to evaluate the design very early in the design cycle

It is good for addressing the problem of users not knowing or being unable to state their requirements

Provides the opportunity for continued evaluation and refinement of the design

Increases the chance of getting a well designed system acceptable to the users with the required functionality and ease of use

45

Page 46: Prototyping

RAPID PROTOTYPING – DISADVANTAGES

Can consume a lot of resources – users analysts programmers. Therefore can be costly as well as time consuming

The continued process of design evaluate redesign may mean that the design phase of the cycle is considerably increased

May be a long time before get a working system Reluctance to ‘throw away’ or discard the prototype Users expectations/wishes may be unrealistic

May not be technically or economically feasible

46

Page 47: Prototyping

INCREMENTAL PROTOTYPING

Final product is built as separate components one at a time

There is one overall design for the system It is partitioned into independent and smaller

components Final product is released as a series of products

Eg General student details data module – the students assessment profile module

47

Page 48: Prototyping

INCREMENTAL PROTOTYPING - ADVANTAGES

Allows large systems to be installed in phases Helps to avoid the delays between specification

and implementation Core system features are provided early Users are not overwhelmed with a complex level

of functionality in one go Suitability and appropriateness of key

requirements can be checked Less essential features can be added later

48

Page 49: Prototyping

INCREMENTAL PROTOTYPING – DISADVANTAGES

Need to have an overall view of requirements Suitable development software must be used –

not just high level prototyping software Long development timescale before full

functionality is obtained This may be incompatible with management

business goals Eg Need to get to market before a competitor Urgent requirements for a complete solution

49

Page 50: Prototyping

EVOLUTIONARY PROTOTYPING – RAD

As for incremental prototyping Additions and amendments are made following

evaluation and the system is regenerated in its amended form

In this case the prototype evolves into the final system

50

Page 51: Prototyping

EVOLUTIONARY PROTOTYPING – ADVANTAGES

The system can cope with change during and after implementation

Again helps to overcome the gap between specification and implementation

Users get some functionality quickly

51

Page 52: Prototyping

EVOLUTIONARY PROTOTYPING -DISADVANTAGES

Can lead to a long development timescale May have limited functionality which may not be

apparent to the user May believe that they have the final complete

system and may therefore be unimpressed!

52

Page 53: Prototyping

OTHER PROTOTYPING TECHNIQUES

Full prototype full functionality, lower performance than production

software Horizontal prototype

displays “breadth” of functionality, no lower level detail “back end” support Eg. Database link

Vertical prototype full functionality and performance of a “slice” or small

part of the system

53

Page 54: Prototyping

54

PROTOTYPES INVOLVE COMPROMISE For software-based prototyping maybe there is a slow

response? sketchy icons? limited functionality? Two common types of compromise ‘horizontal’: provide a wide range of functions, but

with little detail ‘vertical’: provide a lot of detail for only a few

functions Compromises in prototypes mustn’t be ignored.

Product needs engineering

Page 55: Prototyping

55

Different Features

Scenario

Vertical P

roto

type

Horizontal Prototype

Full System

Fu

nctio

nality

Page 56: Prototyping

56

HORIZONTAL PROTOTYPING

Broad and shallow

Overview with limited underlying functionality

Simulation of entire interface

Page 57: Prototyping

57

HORIZONTAL PROTOTYPING

Disadvantages Not possible to perform real work Users cannot interact with real data Often possible to create a wish list interface

Advantages Can be created quickly Gives an idea of how the whole interface will hang

together Identifies top level functionality

Page 58: Prototyping

58

HORIZONTAL PROTOTYPE: BROAD BUT ONLY TOP-LEVEL

Page 59: Prototyping

59

VERTICAL PROTOTYPING

Reduction of number of features In-depth functionality for a few selected features Tests part of system Tests in depth under realistic circumstances with

real user tasks Main limitation: usesr cannot move freely

through the system

Page 60: Prototyping

VERTICAL PROTOTYPE: DEEP, BUT ONLY SOME FUNCTIONS

60

Page 61: Prototyping

61

PROTOTYPING FOR USABILITY

Usability = ease of use of an application Design typical user task scenarios Identify tasks based on the scenarios Use “Real Users” to test Watch user performing task Iterate design based on test

Page 62: Prototyping

62

COST OF PROTOTYPING

Cheaper than not doing it...... Sommerville: cost of repairing an error made in analysis

and design phase can cost up to 100 times the orginal cost Usability work (including prototyping) should amount

for 5-10% of a project’s budget Testing early, iterating often makes the product

cheaper. Prototyping offers a cheap means of testing usability

early in the lifecycle

Page 63: Prototyping

63

BOTTLENECKS

Aim of using prototype is to avoid bottlenecks Potential bottlenecks in prototyping:

unnecessary neatness getting started not working in parallel

write the tasks make a “manifest” of all the pieces needed for the tasks people put initials by what they’re working on do periodic run-throughs to determine what’s missing

Page 64: Prototyping

64

REALISING PROTOTYPES

Taking the prototypes (or learning from them) and creating a whole

Quality must be attended to: usability (of course), reliability, robustness, maintainability, integrity, portability, efficiency, etc.

Product must be engineered Evolutionary prototyping ‘Throw-away’ prototyping

Page 65: Prototyping

65

USERS & PROTOTYPES

The only way to really test the interface of a prototype is with real users

The lifecycles give us a way to feed what we discover back into the development process

The question remains of the best way of involving the users

Page 66: Prototyping

66

WHY INVOLVE USERS?

Expectation management Realistic expectations No surprises, no disappointments Timely training Communication, but no hype

Ownership Make the users active stakeholders More likely to forgive or accept problems Can make a big difference to acceptance and success of

product

Page 67: Prototyping

67

MICROSOFT MODEL

Users are involved throughout development ‘activity-based planning’: studying what users do to achieve a certain activity (task) usability tests e.g. Office 4.0 over 8000 hours of

usability testing. internal use by Microsoft staff customer support lines

Page 68: Prototyping

68

POSSIBLE PROBLEMS WITH PROTOTYPING Pressure to enhance prototype to become

delivered systemFrom clientFrom management

Both see code, see almost-working “system” Why not use the prototype? Prototype built for quick updates, so...

No design, so hard to maintainUgly code, no error checkingWrong environment

Page 69: Prototyping

69

PROTOTYPING DIMENSIONS

Representation Scope Executability  Maturation

Page 70: Prototyping

70

PROTOTYPING DIMENSIONS

 1. Representation How is the design depicted or represented? Can be just textual description or can be visuals

and diagrams 2. Scope Is it just the interface (mock-up) or does it

include some computational component?

Page 71: Prototyping

71

PROTOTYPING DIMENSIONS

3. Executability  Can the prototype be “run”? If coding, there will be periods when it can’t 4. Maturation What are the stages of the product as it comes

along? Revolutionary - Throw out old one Evolutionary - Keep changing previous design

Page 72: Prototyping

72

Early prototyping Used to evaluate function and interface

Late prototyping Used to evaluate performance

EARLY PROTOTYPING VS. LATE PROTOTYPING

Page 73: Prototyping

EVALUATION

It is no good building a prototype if you do not evaluate it!!

Evaluation is another key feature of user centred design

Evaluation will be covered later in the module

73

Page 74: Prototyping

74Thank You