Table of Contents
Why we have this Process
Usability is a major factor in the success of any product. User testing is a technique for evaluating the usability of a product or prototype and discover design issues. It creates a deep understanding of the user and usually it is experienced as eye-opening to all who observe a user test. At a basic level, a user test usually involves a facilitator asking a user to complete a series of tasks while observing the interaction, noting any problems the user encounters, errors made, and sometimes the amount of time it takes to complete a task.
Context and Scope
User testing can be performed on anything from early stages designs up until production systems. It can be helpful to start by performing user tests with paper prototypes and continuing to test more interactive clickable prototypes as a product iterated upon.
The user test findings are fed back into the design process in order to improve the prototype or product.
User testing is usually combined with some User Interviewing in the form of some questions before the user test. Combining user testing with questions allows us to also answer the question if the user need is big enough to motivate the user to start the task in the first place.
User testing is planned using the User Testing Backlog.
When should the process be performed?
User testing is an ongoing process with test always planned every two weeks. In this way we make user testing a habit. We test the top item from the User testing Backlog, or if there is no we fall back to testing the (core workflow) on the production web app.
As soon the design of an Epic is done and internally reviewed, although multiple epics can be grouped into one user test for efficiency. (Where Epic is defined as: A big version of a user story, that groups a set of user stories, that together achieve a user goal that has actual business value. Good examples:"Manage Todo's", "Create Timesheet for hours worked this Week", "Email Users Updates in the Wiki", "Buy Product", "Browse Articles", "Manage Profile", "Hello World Username". "Browse my music library and lay music" is Spotify and is too big.)
Who performs the process
Who performs the process: UX Designer
Who monitors if the process is done (correctly): Head of Product
Who participates in the process: PM, sample of developer(s)/testers(s)/other colleague(s) (max 3).
- Plan User Test days (recommendation: Fixed day(s) every 1 or 2 sprints)
- Determine Test goals, i.e. what Epics to test and/or what to interview users about. (tip: Start a Topics to test backlog)
- Recruit testers, i.e. mail your Customer Panel or customers (see FAQ below for more tips).
- Schedule tests with the users (90 minutes recommended. Offer them timeslots via www.calendly.com )
- Prepare a User Test (see template below)
- Run a User test (see below)
- Store your detailed findings on the wiki.
- Summarize and share your findings with the team.
Please note the many templates linked in the process above. You can also find them in the menu to the left, as subpages of this page.
- The participants represent real users.
- The participants do real tasks.
- The moderator does not steer the user by giving hints or answering questions.
- You observe and record what participants do and say.
- You analyze the data, diagnose the real problems, and recommend changes to fix those problems.
With every user test you should also be looking for opportunities to remove friction in the process (things that hold the user back from completing the task or make it harder) and for clues on how to encourage the user to use the feature more (i.e. by adding a trigger or explaining the benefits better). This can be achieved by adding interview questions before and during the user test, i.e.: How often do you travel with friends or family by train? Have you ever booked online train tickets? Let's say you want to travel on Friday evening with your family of 4 to city X. How would you proceed? Why do you prefer online booking or phone booking? In what case would you not use online booking?
Isn't User Testing too much work?
Developing features that nobody uses because the user finds them too hard to understand is the real waste of time. User testing is an essential part of the UX designer's role. Designs need to be tested just like software, and finding issues in this stage saves a lot of development work. To convince the PM or CEO that time and money for User testing is needed is relatively easy: Invite them for the first user test.
How to find testers?
Email your customers, your network, your Facebook or use a recruitment service like testingtime.com.
How long does a User test take?
I recommend 90 minutes for concentration reasons, with a coffee break halfway. Also, see the example agenda.
How many people to invite per user test round?
I recommend 4 users per round, and to do them in one day. 2 for very early stage designs and your first round. Start with a dry run using i.e. the secretary/colleague
How to reward testers?
A 20 Euro/Dollar amazon.de voucher is common, up to 50 Euro/Dollar for hard to get audiences.
How do we show the app to the user and record the screen and audio?
For web apps
- Using a clickable prototype, i.e. Using Figma or by publishing your (Sketch) design to Invision.
- Record using a tool like www.lookback.io
For mobile apps
- Option 1: Test on a mobile device connected to a PC or Mac and record from the screen using lookback.io (lookback recognizes the device, no need for extra software)
- Option 2: For Android Lookback.io now also supports guided user tests out of the box. For IOS too, but it requires some lines of code in your IOS app.
- Option 2: Demo via a web testing tool like https://kobiton.com/ and for recording use lookback.io
- Option 3: Use the built-in screen recorder of IOS or Android. (recommended)
Where to do the testing? In office or Remote?
- Recommended option: In the office or a (quiet) coffee shop, for rich dialog.
- Remote is also possible, ie via a trail of www.lookback.io that allows you to join in live and also records the screen.
- Alternative: Use an online user testing service (not ideal, this usually does not allow you to ask live questions to the user)
https://www.confirmkit.com/ - Create Interview scripts and organize findings
- "Don't Make Me Think" by Steve Krug
- "Handbook of Usability Testing" by Rubin J. and Chisnell, D.
- "A Practical Guide to Usability Testing" by Dumas, J., and Redish, J.
- "Usability Engineering" by Jakob Nielsen
Cheatsheet introduction text for before test: PDF Think Aloud pretest - version 09/06/17
Helpful usability.gov instructions to remote usability testing.
How to really observe users behavior instead of relying on their words: NNgroup - First Rule of Usability? Don't Listen to Users
Different techniques of talking in order not to bias a user and to take the most from the observation (not a conversation): NNgroup - Talking with Participants During a Usability Test
User Testing Template
Prepare a User Test
General Preparation tasks before Test Day
- Decide if you’re using the introduction script (click to download) or use the points in the section "General Tester Instruction at Start of the Test". Print it if used. Translate it if needed.
- Prepare the Scenario's you want to test, by adjusting the templates below. A scenario is 1 persona in 1 point in time in 1 system state (i.e. a new user in empty system). (see examples below) (i.e. buying a book)
- Per Scenario define (sub) tasksyou will give the user, i.e. search for the latest harry potter book, add the audiobook version to your shopping basket, buy it with this credit card.
- Determine what Test data you need for each Scenario and write it down below under "Scenario specific Preparation tasks before Test Day" (i.e. your bookshop will need relevant books, another scenario might need an existing user who has bought a book before to test the returns process)
- Setup the system with this test data.
- If you are testing on a Design or Product that's active behind developed you might want to ask for a separate stable version for the test period.
- Select / setup Recording software(i.e. Lookback.io or Quicktime on mac for screen and audio recording)
- Gather Laptop(s) or mobile devices as needed
- Adjust the Agenda paragraph to the test length (i.e. 90 mins, 60 mins, etc)
- Print the "How to run a test"section below. Make sure the tester parts are on separate pages and take some blank sheets of A4.
- Do a dry run with a colleague who ideally doesn't know the app
- Read “Advice for Interviewer” section below.
- Print any tester handouts
- Instruct the other user test observers:
- On how you want them to act (i.e. when they can ask questions, and not to give hints or ask leading questions)
- Where they can find the scenario script
- Where they can fill their observations (when using confluence: I recommend letting them add their observations right into the observation box to, with their initials as prefix to the comments. )
- Optional : Buy Amazon gift card or other gifts if applicable (especially in case you are having trouble recruiting participants)
Advice for Interviewer to keep in mind
- The focus is only on the pure user intentions and thoughts, reduce bias as much as possible:
- Don't explain, only ask questions. However, avoid straightforward questions which can be biased as well.
- Don't answer questions during the test. Apologise and say that this is exactly the question which cannot be answered right now, but we can discuss it at the end of the test.
- Ask a little as "if" questions as possible (for example, "if this won't be here if you were needing this")
- Avoid tech or designer talk (shortcuts like UI, terms, and specifications).
- Don't interrupt the tester if he is reading or thinking, but sometimes do ask questions, especially if you see facial expressions.
- Treat participants with respect and make them feel comfortable.
- Remember that you are testing the app/site not the users. Help them understand that they are helping us test the prototype or Web site.
- Remain neutral – you are there to listen and watch. If the participant asks a question, reply with “What do you think?” or “I am interested in what you would do.”
- Do not jump in and help participants immediately and do not lead the participant. If the participant gives up and asks for help, you must decide whether to end the scenario, give a hint, or give more substantial help.
- The team should decide how much of a hint you will give and how long you will allow the participants to work on a scenario when they are clearly going down an unproductive path.
- Take good notes. Note-takers should capture what the participant did in as much detail as possible as well as what they say (in their words). The better the notes are that are taken during the session, the easier the analysis will be.
- Measure both performance and subjective (preference) metrics. People's performance and preference do not always match. Often users will perform poorly but their subjective ratings are very high. Conversely, they may perform well but subjective ratings are very low. Performance measures include: success, time, errors, etc. Subjective measures include: user's self reported satisfaction and comfort ratings.
Scenario specific Preparation tasks
Scenario 1 prep tasks
- (this is specific to your app. here are 2 example preparation points for a real estate app test)
- Add a User without purchased objects and log in as below. And no profile image. One user for each tester that is coming in and one backup user.
- For each user: 4 objects to explore, 2 outside New York.
Scenario 1 prep tasks Tester Handouts
Using tester handouts is optional, but it often is more convenient to share some details like password than to have to say them out loud.
Background info: The fictional case
You are an Agent who works at a small 3 person company in New York. You signed up for our service because it offers potential clients to you (you are paying a certain service fee). They told you in an email that you can use their service via the app or via an iPhone app and you decided to give the iPhone app a go. The login details that they emailed you are below. For this test please ignore spelling errors and the fact that many words are not translated into German yet. Also, ignore the menu at the bottom of the screen. Remember to think out loud.
Search parameters: 2M-3M , lower Manhattan, 27 bedrooms.
Run a User Test
General Introduction Script
Welcome and Purpose
Thank you for agreeing to participate in this app/site evaluation. Today we are asking you to serve as an evaluator of this app/site and to complete a set of scenarios. Our goal is to see how easy or difficult you find the app/site to use. We will record your reactions and opinions; so, we may ask you to clarify statements that you make from time to time.
Test Facilitator’s Role
I am here to record your reactions and comments of the app/site you will view. Our other colleagues will act as observers helping me take notes and observe your interaction with the site. During this session I will not be able to answer any questions or offer any suggestions or hints. However if a question comes to mind please say it out loud. There may be times, however, when I will ask you to explain why you said or did something.
Test Participant’s Role
I will ask you to search for information in this app/site to learn if it works well for you. We will do this by giving you scenarios or tasks to complete in the app/site. As you will interact with the product I kindly but strongly request you to think aloud while you complete the tasks and scenarios. Basically you should be talking most of the time. You also will be asked a couple general questions before the before the testing session and a series of questions about your experience at the end of this session.
Things to Keep in Mind
Here are some things that you should know about your participation:
- What we are doing today is all about how easy we have made it for people to use the app/site.
- There is no right or wrong answer. If you have any questions, comments or areas of confusion while you are working, please let me know.
- If you ever feel that you are lost or cannot complete a scenario with the information that you have been given, please let me know. I’ll ask you what you might do in a real-world setting and then either put you on the right track or move you on to the next scenario.
- We will be recording this session for reference if needed. Your name will not be associated or reported with data or findings from this evaluation. Do I have your permission to do so? (after that, start recording) Finally, as you use the site, please do so as you would at home or your office. I do ask that when looking for information, you do so as quickly and as accurately as you can.
Do you have any questions before we begin?
An alternative shorter version of intro script:
- Explain they can't do anything wrong
- Explain we want honest opinions, don’t worry about hurting our feelings
- Explain that they are testing a prototype
- Explain to really click on things, but not everything works, but we want to learn so it's good
- Explain to think out loud
- Explain the role of the user - You can also put this on the tester handout.
- Explain the task of the user - You can also put this on the tester handout.
- Handout the Scenario Tester handout.
- Cover up tasks 2 and further (we reveal them 1 by 1).
- Ask the user to read and start with task 1 afterward.
Scenario Specific Script
The process to be used during the actual test when the tester has arrived.
- People Introduction Round (5 mins)
- General Instruction, see above (5 mins)
- User Interview Questions (20 mins)
- Scenario 1 (40 mins)
- User Interview Questions (15 mins)
- Ending (5 mins)
Total: 90 minutes
User Interview questions (Agenda point 3)
Tip: You have to rapid fire the user interview questions (and sometimes cut of the tester) to get through them in time. It's recommended to warn the tester about this beforehand!
- What company do you work for?
- How many employees work there?
- Do you use any similar software?
- (if yes) What device(s) do you use it on?
- How often do you do X?
Scenario 1 - Facilitator part (Agenda point 4)
Scenario 1 Instructions
Introduction of what the user is going to do.
|Pages||Homepage, Page X, Page Y. (all the pages/screens you prepared. Include links to all pages, or alternatively only to the first page if all other pages are clickable from the first page).|
|Story||You just installed the app and want to try it out. Or: You are a recurring user, and you have setup the system to import your google contacts and you flagged certain contacts as high prio.|
|Instruction||Try to login to the system. Please remember to think out loud.|
|After task questions|
|Pages||Login page, forgot password page, change password page, dashboard|
The correct password is the one we gave you plus a 0 at the end. Log in to the system and tell us your first impression. If any questions or any concerns let us know. Do not yet Edit or Add something yet.
|After task questions|
|After task questions|
User Interview questions (Agenda point 5)
It is common to also ask some user interview questions after the test, since A) some questions might be related to what the user just tested, B) You might not want to influence the user with certain questions before the user test.
- (Example) For what type of user do you think the demonstrated functionality is ideal?
- How would you improve this app?
Ending (Agenda point 6)
- Optional, let the user fill in the SUS.
- Thank user, tell him/her how this helps
- Tell him/her what we're going to do with is when it goes live
- Handout the gift voucher or tell him/her when it will be mailed.
After Tester left
- Reinstall app to clear out login data.
- Make sure everything is ready for next test
- If time allows: Evaluate.