I've been conducting usability tests for a few years now for a variety of products and interfaces. These have been in-person and remote, high-fidelity and low-fidelity, structured and unstructured. I've been working on a general best practice participant introduction script for personal use and to share with colleagues.

Is anything missing? Is anything wrong or not as good as it could be? Any established best practices that I should reference?

General usability study introduction:

  • Thanks for taking time to help us!
  • Today we’ll be showing you a prototype of a new experience and asking for your feedback

    • We call this a usability study
    • This prototype is a rough mock up that is not yet built
    • The reason we’re showing you this is to get feedback before the team builds the real version
    • It is not actually hooked up to any backend systems, and some parts of it are not fully functional
    • Don’t worry about breaking anything
  • IF GUIDED TEST: We’ll be providing you with a few tasks to role play as your use the prototype
  • Please think out loud as you use the prototype

    • Talk through your thought process
    • Use the prototype as you would at home or another familiar setting
    • Point out anything you like
    • Definitely point out what you don’t like and let us know what's wrong
    • IF EXPERT AUDIENCE: Also, let us know if you think of any improvements or missing functionality
    • There is no correct or incorrect way to do things, just do what you think you should be able to do in the way that you would like to do it
    • If you ever feel stuck, please let me know and we can talk about how you would expect to be able to proceed
    • IF TESTER DIDN'T DESIGN THE PROTOTYPE: I am just the person conducting the test so feel free to speak your mind
  • We are in no way testing you; this is all about the prototype and what works and what doesn't
  • If you ask questions, I might respond with some form of “Well what do you think it should do?”

    • Also, I might ask you what you are thinking at various stages
    • This might get a little annoying so I apologize in advance :)
    • Our goal is to see how you think about things
  • If you would like to stop at any point or take a break, please let us know
  • Is it okay if we begin?
  • edit1: Updated based on Poyi's suggestions
    – Max E
    Nov 20, 2012 at 19:45
  • 1
    Steve Krug runs through a demo usability test in vimeo.com/12053758 which covers a lot of these points and might bring up more
    – Gareth
    Nov 20, 2012 at 23:04
  • edit2: Updated based on mervinj's feedback
    – Max E
    Nov 21, 2012 at 17:14
  • edit3: Updated based on Mark DeHate's feedback
    – Max E
    Nov 21, 2012 at 17:15
  • edit4: Update based on Andrew's feedback
    – Max E
    Nov 21, 2012 at 18:21

5 Answers 5


Your script is off to a great start. I would refer to the Checklist for Prestest Briefing (Figure 5.7) in Moderating Usability Tests by Joe Dumas and Beth Loring.

Additionally, here are some best practices:

  • As Mark suggests, be careful using the word "test". The statement "we are in no way testing you; this is all about the prototype and what works and what doesn't" is fine since you are clarifying that this is not a test of the participant. I would repeat that a couple times for the participant.
  • Demonstrate how to think aloud. In a UXMatters article, Mike Hughes suggests having participants count the windows in their house. Then tell the participant "I’m not really interested in how many windows you have, but I am interested in how you go about doing this task." Similarly, in Moderating Usability Tests, Joe Dumas and Beth Loring suggest having the user describe how to work a stapler.
  • Don't ask for visual design suggestions. You are trying to identify issues, not get visual design recommendations from participants.
  • Tell the participant that you are interested in his or her feedback, not what they think others will say.
  • Clarify how the user will do the tasks. Explain that they should read each one out loud and try to complete them as if they were doing them at home (or in the actual environment). Also, note that the participant should tell you when they think they have completed each task or gone as far as they can.

Note: There is debate in the field about how much time we should spend establishing rapport and providing instructions. Rolf Molich gave a talk at UPA 2011 entitled "The Babble Ratio and Other Observations from Usability Testing Assessment". He found that practitioners spend a shocking amount of time chatting and explaining things.

  • 2
    I disagree somewhat on the "Don't ask for design suggestions" point. Recently, I've been doing a lot of testing with expert audiences that use ours and related systems all day. With that audience I find that they tend to have informed suggestions for how they would like to do things. They aren't all gems but it does make for some good facilitated design sessions. With a novice audience, I agree with you.
    – Max E
    Nov 21, 2012 at 18:18
  • 1
    Here's a direct link to the checklist. This is exactly what I was looking for. Thanks.
    – Max E
    Nov 21, 2012 at 18:29
  • @MaxE thanks for the direct link--I didn't look at the book site long enough to see it :-)
    – Andrew
    Nov 21, 2012 at 18:40
  • @MaxE I agree your feedback regarding "design suggestions". I updated my post to say "visual design suggestions". Workflow or process feedback could certainly be helpful, depending on the audience. I also added the link to the checklist in my post.
    – Andrew
    Nov 21, 2012 at 18:49

Instead of asking them to "let you know what they think" sometimes it will be more helpful to phrased it as "please think out loud as you use the prototype". Another thing I might mention is that "I am just the person conducting the test so feel free to speak your mind". Maybe it's helpful to let them know that you are just observing.

  • It may be worth saying that you're not the designer even if you are. You'll get more honest feedback that way.
    – kastark
    Nov 21, 2012 at 17:16
  • If I can't find someone at least slightly removed from the design process to facilitate, I usually just don'tn mention that I designed it and let the participant assume what he or she will. It's a lie of omission but I'm comfortable with it.
    – Max E
    Nov 21, 2012 at 17:38

Another statement which I always mention is that " Please dont think there is no right approach or right way of achieving the end goal. We want to see all the ways you approach the task and what works best for you as that will provide us inputs into how users might use this application. If you see multiple ways of doing a task, please let us know what you like\dislike about a specific approach"

The advantage of this statement is that people know they have total freedom in doing the task the way they like and asking them about the issues with each approach helps in nailing down details like positioning a call to action button and replication of links (say in the header and footer)


I like what you have here; it's very similar to what I've used before. My only suggestion would be to avoid using the word "test" whenever possible, even in the phrase "usability test". It's a trigger word that (in my experience) immediately causes people to think they are taking the SATs and that they are going to fail and have to work at McDonalds for the rest of their lives if they fail.

Okay, so maybe that's a bit overdramatic, but I've seen a lot of people get super nervous about being a participant in a usability testing. So I try my absolute best to never say the word test (except maybe saying explicitly "this is not a test") and instead say "usability study".

It's a minor point, but nervous participants make for miserable studies!

  • Thanks for the tip. It's a small thing but I think that you are right; it's important to set expectations early on and the word "test" can throw people off. I think that an invitation to participate in a "Usability Study" would elicit more positive reactions than a "Usability Test". Also, "test" is confusing because what we are testing is the prototype which we all know but a fresh participant might not. And aren't we all here to make it better for the user?
    – Max E
    Nov 21, 2012 at 17:24

It turned out to be useful to pay the compensation fee at the beginning of the test so the users do not feel the duty having to work towards something they think you want to hear to get the money.

We always emphasize that the compensation is for showing up only and that it's not them who are tested.

  • A very useful piece of advice. Does this work for online as well as onsite participants?
    – Michael Lai
    Aug 19, 2013 at 23:07
  • You mean for remote tests? I don't know. We use an external service for this. The focus here lies in testing the setup before we invite our own participants so we are not really interested in the results. Aug 21, 2013 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.