The importance of rehearsing

Sports teams drill endlessly. They walk through plays, they run plays, they practice plays in scrimmages. They tweak and prompt in between drills and practice. And when the game happens, the ball just knows where to go.

This seems like such an obvious thing, but we researchers often poo-poo dry runs and rehearsals. In big studies, it is common to run large pilot studies to get the kinks out of an experiment design before running the experiment with a large number of participants.

But I've been getting the feeling that we general research practitioners are afraid of rehearsals. One researcher I know told me that he doesn't do dry runs or pilot sessions because he fears that makes it look to his team like he doesn't know what he is doing. Well, guess what. The first "real" session ends up being your rehearsal, whether you like it or not. Because you actually don't know exactly what you're doing -- yet. If it goes well, you were lucky and you have good, valid, reliable data. But if it didn't go well, you just wasted a lot of time and probably some money.

The other thing I hear is that researchers are pressured for time. In an Agile team, for example, everyone feels like they just have to keep moving forward all the time. This is an application development methodology in desperate want of thinking time, of just practicing craft. The person doing the research this week has finite time. The participants are only available at certain times. The window for considering the findings closes soon. So why waste it rehearsing what you want to do in the research session?

Conducting dry runs, practice sessions, pilots, and rehearsals -- call them whatever works in your team -- gives you the superpower of confidence. That confidence gives you focus and relaxation in the session so you can open your mind and perception to what is happening with the user rather than focusing on managing the session. And who doesn't want the super power of control? Or of deep insight? These things don't come without preparation, practice, and poking at improving the protocol.

You can't get that deep insight in situ if you're worried about things like how to transfer the control of the mouse to someone else in a remote session. Or whether the observers are going to say something embarrassing at just the wrong time. Or how you're going to ask that one really important question without leading or priming the participant.

The way to get to be one with the experience of observing the user's experience is to practice the protocol ahead of time.

There are 4 levels of rehearsal that I use. I usually do all of them for every study or usability test.

• Script read-through. You've written the script, probably, but have you actually read it? Read it aloud to yourself. Read it aloud to your team. Get feedback about whether you're describing the session accurately in the introduction for the participant. Tweak interview questions so they feel natural. Make sure that the task scenarios cover all the issues you want to explore. Draft follow-up questions.
   
• Dry run with a confederate. Pretending is not a good thing in a real session. But having someone act as your participant while you go through the script or protocol or checklist can give you initial feedback about whether the things you're saying and asking are understandable. It's the first indication of whether you'll get the data you are looking for.
   
• Rehearsal with a team member. Do a full rehearsal on all the parts. First, do a technical rehearsal. Does the prototype work? Do you know what you're doing in the recording software? Does the camera on the mobile sled hold together? If there will remote observers, make sure whatever feed you want to use will work for them by going through every step. When everything feels comfortable on the technical side, get a team member to be the participant and go through every word of the script. If you run into something that doesn't seem to be working, change it in the script right now.
   
• Pilot session with a real participant. This looks a lot like the rehearsal with the team member except for 3 things. First, the participant is not a team member, but a user or customer who was purposely selected for this session. Second, you will have refined the script after your experience of running a session using it with a team member. Third, you will now have been through the script at least 3 other times before this, so you should be comfortable with what the team is trying to learn and with the best way to ask about it. How many times have you run a usability test only to get to the 5th session and hear in your mind, 'huh, now I know what this test is about'? It happens.

All this rehearsal? As the moderator of a research session, you're not the star -- the participant is. But if you aren't comfortable with what you're doing and how you're doing it, the participant won't be comfortable and relaxed. either. And you won't get the most out of the session. But after you get into the habit of rehearsing, when it comes game time, you can concentrate on what is happening with the participant. Instead, those rehearsal steps become ways to test the test, rather than testing you.  

There's a lot of truth to "practice makes perfect." When it comes to conducting user research sessions, that practice can make all the difference in getting valid data and useful insights. As Yogi Bera said, "In theory, there's no difference between theory and practice. In practice there is."