TSS 2013 – Lo-fi prototype testing


Published on

Scripted usability tests for paper prototypes. This slides are part of the summer school new media course, more information http://ifi6079.wordpress.com/

Published in: Education, Technology, Design
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

TSS 2013 – Lo-fi prototype testing

  1. 1. Testing Paper Prototypes TLU-HCI Summer School 2013 Valeria Gasik, Zahhar Kirillov, Daria Tokranova
  2. 2. 1. Plan Select what user stories/use cases you would like to test 2. Prepare Write a simple script, distribute test session roles, specify questions and determine tasks and their end-results 3. Conduct Organize and record usability test (notes/video) 4. Reflect Analyze results and make according changes Today
  3. 3. About Testing Raw Prototypes
  4. 4. Most people are happy to dedicate time to help you out with your project, even if it’s just on paper! Although it’s just on paper, plan and be prepared! Usability Wizard
  5. 5. Tasks to test “Find the nearest shop” Any type of doable tasks with clear goals but without specific clues of the solution. “Change your password” “Go to menu and edit settings of your profile” “Rearrange search results based on the location”
  6. 6. Maria likes second-hand clothes. She goes on 2ndHand.com and browses the newst offers. She searches for shoes and quickly finds the ones she like. Maria adds them to her shopping card. Possible questions and tasks “What can you do with this app?” Task 1: Search for women’s shoes with the color of your choice. Task 2: Buy your favorite pair. Example
  7. 7. Task 2: Buy your favorite pair of shoes. End result User has completed, verified and paid for her order. Steps 1.Add the product to the cart 2. Proceed to the checkout 3. Fill in needed information (x, y, z, ...) 4. Verify your order 5. Pay a) with online bank b) with credit card 6. Receive a receipt ALT Deal with errors, e.g. missing information
  8. 8. Open-ended questions “What do you think you can do with this application?” Homescreen Previous action returns an error “What do you think went wrong?” “Do you like it?”New feature
  9. 9. “Er... sure, I like it” “Yeah, I know, it’s awesome.”
  10. 10. Tasks E.g. 1.1.“First change your password” 1.“You need to make some modifications in your profile.” End-result: user replaces current password. End-result: user finds how to change settings a) via profile b) via settings icon.
  11. 11. Prepare • Write a simple script for yourself, if you have a lot of testing to do. Number/name questions and tasks to help documentation. • Write down tasks on a separate paper so you can show them to your test participants • Specify, for yourself, end-results for the task. Think about what “task not completed”could stand for.
  12. 12. Roles http://austintoombs.com/wp-content/uploads/2011/02/DSC_7808-Copy.jpg Participant thinks out loud Observer takes notes (Silent) Human-Computer reacts to user’s commands + Facilitator instructs the user and helps the computer Team of 2 or 3
  13. 13. Test structure example 1. Greetings Introduce team members and explaining the test method Give instructions, e.g.“Point with your finger/pen to simulate a tap” Mention that it is not a user who is tested but the system 2. Start with light background questions E.g.“How often do you use travel planners?” Explain briefly what is the starting point,“This is the landing page of...” 3. Remind the participant to think aloud E.g.“I think this link would lead me to…”
  14. 14. 4.Introduce the first task Make sure that it’s clear for the user 5.Move to the next task Continue when the goal is achieved or user expresses that he/she does not know the answer. 6. Conclude the test session Ask if user has anything to add Thank the participant and discuss the results with your team Test session
  15. 15. During the test pay attention to... E.g. • Are participants doing what was expected? • Did anything cause frustration or confuse? • Anything new or surprising? • Any paths that you haven’t thought of before? • Was there a clearly preferred solution or path? • Are some paths unused or “misused”?
  16. 16. Reflection and Design Changes E.g. Bottlenecks in the process? What paths were ignored or barely used? What was clearly missing? etc. Tip: Update before the next test user and see if it worked.