In a guided exploration I let a person immerse themselves in a system. I ask them to accomplish tasks that touch on points in the artefact that we want to validate. During the hour-long session I can find a lot of pain points in the artefact I help design.

So far in this series I’ve discussed interviews and quick usability tests. Interviews are long, often a full hour, while the quick tests are over in five minutes. My “guided explorations” are 30-60 minutes long sessions where I guide persons through scenarios in a system.

By having the person interact with the artefact for a quite long time I can validate full use cases and can see things such as when the person gets bored with the system or when they struggle to accomplish a task that require multiple steps or decisions. Questions that can be answered include “Which problems exist that hinder a person who want to find, configure and purchase Widget X?” and “Does our interface seem to feel fluid or is it jagged?”

Preparations and Setup

• I always start by defining what we want to understand and which parts of the artefact will be investigated.
• I then create scenarios that touch on the areas we want to investigate and see to it that we have prototypes or production systems that include those parts. In the scenarios I include an entry point and an exit. Entry might be a Google search, exit is most often shortly after achieving the task that the scenario is based on.
• I find that guided explorations work best when only one researcher sit with the “user”. Having two researchers in the room can make the person too aware of their actions.
• Invitation and location selection is as for Interviews.
• I often ask the invitee to bring their own hardware or the device category we are investigating. Using ones own tablet or phone feels less scary than using a borrowed device.

Procedure

1. I introduce myself, explain the task and discuss documentation as for Interviews.
2. I ask the person to “talk out loud” during the session and explain that this can feel quite weird in the beginning.
3. I then introduce the first scenario/task and get the person to the initial state/screen.
4. I ask questions such as “You clicked on the link and ended up on this page. Was that what you expected?” if the person is not conveying the information I am interested in by “talking out loud”.
5. The person often have question regarding if they have made correct interpretations and acted as we want them to. I try to deflect these questions by either giving an ambiguous answer or writing down the question and telling the person that I will answer it after the session. Deflecting is extra important for questions that involve the parts of the artefact that we are investigating.
6. After each scenario/task I answer any questions that are asked and that are appropriate to answer and then introduce the next part. A break for coffee and a cinnamon bun is also included (obviously!).
7. After all scenarios are done I answer any remaining questions, thank the person for helping and we part ways.
8. I write a short report and adjust my scenarios based on the methodological challenges that arose during the session.
9. When all sessions are done, usually 4 or 5 in total, I report the results and give recommendations.

Building trust

Guided explorations are not as private as Interviews but they can be very intimate. I and the person are in a room for up to an hour and we talk almost the whole time. I also ask the person to act in a system or prototype that we know have flaws and in which the “user” will thus fail from time to time. Therefore all recommendations for building trust during Interviews also hold for Guided explorations. In addition I try to have the person use their own device during the session.

During the session the “user” will get confused and uncertain from time to time. When I notice that this happens I often deliberately blame myself or the system. After all: the system is broken if the person can not accomplish what we want them to accomplish.

Tomorrow: Long-distance relationships.