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
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.
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.
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!