Your SlideShare is downloading. ×
0
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Prototyping
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Prototyping

705

Published on

Prototyping in HCI

Prototyping in HCI

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
705
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×