When someone walks into your usability lab they are expecting a test. You may tell them again and again that the session is about feedback and definitely not a test of them and their abilities. They’ll agree with you out loud but in reality, their initial feelings are very similar to when they walked into their final exams. No one likes tests.
Your job as the facilitator, is to make the session less about a test, and more about a story. You need to help your participants understand that they are there to imagine the narrative of what might happen if they used this product on this day. What worked and what didn’t? What was a good experience and what could be improved? Your goal is to tease out that story, in their words.
But sometimes the story just doesn’t emerge – and this is often because participants snap back into test mode. You see, you are paying them to look at your product, and the most natural thing for them to do is to look for what’s wrong.
Which means that they are absolutely stellar at highlighting incorrect copy, dummy data, or Latin text. I bet you can think of better uses of their time in your lab.
So, here’s my one crazy trick: make sure that the content of your testing prototypes follows a narrative. Use realistic names, dates, events, and wording. It doesn’t have to be perfect, just good enough so that it’s not jarring. No Mickey Mouse or Donald Ducks, no endless varieties of ‘foo’ (why do developers love ‘foo’ so much?) Just solid useful content that tells a story.
When you’re building your testing script and reviewing what you are going to show your participants, run a content audit in the back of your head. Work with your designers and developers to get it right.
Do this one thing, and you’ll spend less of your precious lab sessions explaining inconsequential details to your participants: instead setting the stage for them to get into their flow state and give you meaningful feedback.