Prototype Testing: User Autonomy vs. Necessary Directions
How might we learn as much as possible from the participants while also giving them the necessary directions to click through the prototype?
In recent iterative testing projects, I have been conducting concept testing with participants to learn about their experience with our mid-fi clickable prototype. In the prototype, there are 20+ screens, and they are of a linear step-by-step fashion. The selection of each step should feed into the following steps—and ultimately the final step.
In the prototyping stage, in order to avoid having to prototype endless combinations for all selections, the designers have decided to integrate the input of only one route. This one route includes selections bearing the character “Jamie June” in mind: she’s a hat seller, she lives in Florida, and she likes colors, this and that. The input, sometimes text inputs but mostly selections are based on how Jamie would proceed with the product.
(I made a prototype of the prototype so that I am not sharing confidential company info 😆. This is an illustration of how the participants are seeing the prototype. In the left image, if they wanted to select the bottom option, the prototype wouldn’t let them; in the image to the right, the prototype doesn’t allow typing, so when they click on the screen, “Jamie June” would pop up.)
In the dry-run session of the concept testing, as the researcher, I introduced the task to the participant that aimed to help them understand that
“The prototype has limited functions, so it might not work as you intended it to”
“There are no right and wrong actions whatsoever in interacting with the prototype, don’t worry about doing the wrong thing.”
“I encourage you to think aloud—putting your thoughts on speakerphone. I understand that it might not be natural for you, so I might follow up with questions when I want to learn more about your thoughts.”
However, as the participant went through the prototype, on the first screen, once they clicked on something, they started to get confused: “umm. WHO IS this Jamie June?” I briefly told them about the character and why we had to include a path there (for prototyping efficiency). As a result, in the following steps, users unsolicitedly started to think in Jamie June’s hat: “Oh for Jamie June, she’d need these functionalities,” or “these might be images she’d upload.” I sometimes wanted to learn more about the participant’s own choice, and that’d break their thinking flow for a bit.
After the dry-run, the designers, the PM, and I met for a meeting. Some of the team proposed that I just ask the participants to think about what Jamie June would do so that it wouldn’t be confusing for them to switch between their own choices on the interface and Jamie June’s. However, I was worried that it would be less authentic for users, especially considering when a prototype testing like this was already limiting enough. I quickly consulted my research leads and they also said that it’d be better to have the participants talk about their own preferences as they go through the prototype.
What I decided to do with the following participants was to give them a better context in the beginning:
“Since it’s a prototype, it’s quite limiting in what it can do and react to. To move along with the prototype, the designers have programmed a path based on a character, Jamie June. However, the goal of this test is for me to learn about what YOU would do. So, every time before and after you act on the screen, I’d like to learn about your preferences, questions, positive or negative, all welcome. However, to make sure that I can have you look at more things in the prototype, I’ll direct you to the next steps with the programmed “Jamie June” selections. Does that sound alright?”
With the new framing, participants became much clearer about what was expected of them to share (it’s not a test about picking for Jamie June!), and they feel less awkward when I asked them to select certain things to move along with the prototype.
Framing helps. Good directions help.
