TWS 2014 – Testing paper prototypes


Published on

Scripted usability test with paper prototypes. Tallinn Winter School, Experimental interaction design workshop.

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

  • Be the first to like this

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

No notes for slide

TWS 2014 – Testing paper prototypes

  1. 1. Testing Paper Prototypes Tallinn Winter School / Experimental Interaction Design 2014
  2. 2. Recap Users + End goals Persona Scenarios Use cases/ User stories Paper prototypes Testing I
  3. 3. Today 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
  4. 4. About Testing Raw Prototypes
  5. 5. 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
  6. 6. Tasks to test 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” “Find the nearest shop” “Rearrange search results based on the location”
  7. 7. Example scenario Maria likes second-hand clothes. She goes on and browses the newest 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.
  8. 8. Task 2: Buy a pair of shoes you like. 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
  9. 9. Open-ended questions Homescreen “What do you think you can do with this application?” Previous action returns an error “What do you think went wrong?” New feature “Do you like it?”
  10. 10. “Er... sure, I like it” “Yeah, I know, it’s awesome.”
  11. 11. E.g. Tasks 1. “You need to make some modifications in your profile.” End-result: user finds how to change settings a) via profile b) via settings icon. 1.1. “First change your password” End-result: user replaces current password.
  12. 12. 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.
  13. 13. Roles Team of 2 or 3 (Silent) Human-Computer reacts to user’s commands Observer takes notes Participant thinks out loud + Facilitator instructs the user and helps the computer
  14. 14. 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…”
  15. 15. Test session 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
  16. 16. 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”?
  17. 17. 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.
  18. 18. Happy testing ...and may the odds be ever in your favor!