Prototyping in HCI

1. HCI – PROTOTYPING
Eman Abed AlWahhab
1

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
2

3. PROTOTYPING
 you never get it right first time
 if at first you don‟t succeed …
prototype evaluatedesign
re-design
done!
OK?
3

4. PITFALLS OF PROTOTYPING
 moving little by little … but to where
1. need a good start point
2. need to understand what is wrong
4

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
5

6. JOURNEY OF THE PROTOTYPING PROCESS
Goals
Functionality
Evaluate
Develop
6

7. GOALS OF PROTOTYPING
Prototyping 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
7

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
8

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
9

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 errors
 Repeat until you have a clean design
 A major tool for improving usability
 Heavily used in industry
10

11. WHAT IS PROTOTYPED ?
 Technical issues
 Work flow, task design
 Screen layouts and information display
 Difficult, controversial, critical areas
11

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
12

13. PROTOTYPE REPRESENTATION
 How to represent the prototype?
 Mockup
 Storyboard
 Sketches
 Scenarios
 Screenshots
 Functional interface
13

14. USE TAGLINES / CAPTIONS
 Keep it short: show as much as necessary but not more
14

15. MOCKUPS / WIREFRAMES
 Good for brainstorming
 Focuses people on high-level design notions
 Not so good for illustrating flow and the details
15

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
16

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
17

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
18

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
19

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
20

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‟
21

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
22

23. 23

24. 24

25. SKETCHES
 Generally for depicting
physical aspects of
system
25

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
26

27. Scan the
stroller ->
Change the
color ->
Place the
order ->
Initial
screen
27

28. Scan the
shirt ->
Touch
previous
item ->
Delete
that item->
Alternate
path…
28

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
29

30. • Index cards (3 X 5 inches)
• Each card represents one screen
• Often used in website development
USING INDEX CARDS
30

31. 31
ELEMENTS OF A PAPER PROTOTYPE
Menu Bar
Scroll
Bar
Secondary
Menu
Opening
Contents
31

32. THEIR HOME PAGE
32

33. USER “CLICKS ON” (POINTS TO) CLUBS BUTTON
33

34. THE MUSIC PAGE
34

35. THE HOME PAGE
35
Pulldown
menu

36. 36
A SECOND-LEVEL PAGE

37. 37
ANOTHER SECOND-LEVEL PAGE

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

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
39

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
40

41. COMPARISON OF TWO PROTOTYPING EFFORTS
41

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
42

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
43

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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

51. 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

52. 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

53. 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

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
54

55. Different Features
Scenario
VerticalPrototype
Horizontal Prototype
Full System
Functionality
55

56. HORIZONTAL PROTOTYPING
 Broad and shallow
 Overview with limited underlying functionality
 Simulation of entire interface
56

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
57

58. HORIZONTAL PROTOTYPE: BROAD BUT ONLY TOP-
LEVEL
58

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
59

60. VERTICAL PROTOTYPE: DEEP, BUT ONLY SOME
FUNCTIONS
60

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
61

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
62

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
63

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
64

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
65

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
66

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
67

68. POSSIBLE PROBLEMS WITH PROTOTYPING
 Pressure to enhance prototype to become
delivered system
 From client
 From management
 Both see code, see almost-working “system”
 Why not use the prototype?
 Prototype built for quick updates, so...
 No design, so hard to maintain
 Ugly code, no error checking
 Wrong environment
68

69. PROTOTYPING DIMENSIONS
 Representation
 Scope
 Executability
 Maturation
69

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

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
71

72.  Early prototyping
 Used to evaluate function and interface
 Late prototyping
 Used to evaluate performance
72
EARLY PROTOTYPING VS. LATE PROTOTYPING

73. 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

74. 74
Thank You