Preparation for a User Day

How to Interact with the Customer

The interviewer is faced with the difficulty of wanting to encourage the tester to voice observations and problems out loud, while influencing him or her as little as possible in finding solutions and interaction strategies.

You should encourage the tester to process the tasks cooperatively and to think out loud, but premature assistance indicating how to solve a task or pointing out errors is absolutely taboo!

The following table contains examples of remarks that can create a relaxed, cooperative atmosphere during the test without giving solutions:

Time
Cooperative Remark
After reading the task How can we do that?
Test person is considering the task What should we do now?
While discussing a solution What do you think will happen if you try that?
While discussing a solution Perhaps we should simply try it.
After an interaction What effect did that have?
After an unsuccessful interaction What do you want to do now?
When an error message appears What does this message want to tell us?
Input problems (for example, tester overlooks pushbutton or makes a wrong entry in a field) What did you think the field was for? Can we change it?
Comprehension problems (tester does not understand what is displayed) What did you think it meant? What output did you expect?
Unsuitable workflow Do you think you can do this directly here? How do you do it otherwise?
Missing or overlooked functions Is that an important function? Is the name or location right? Where did you expect this function to be located?
Unknown terms What do you call it?
General rejection Check the reason for the rejection by testing an interpretation: "Do I understand correctly that you would prefer to have only the most important functions here and that everything else should be omitted?"

Avoid the following remarks and only give them if you cannot avoid it. In this case you should protocol your assistance.

Rule
Wrong Remark
Do not explain the interaction principle when introducing the prototype. In our prototype, we wanted to make sure that the user can do this in such a way.
Do not give instructions. First click on ...
Do not point out errors immediately. Be careful, you forgot something.
Do not help with planning actions. Before you do that, you must first ...
Do not give away entries or keys. Just type ... in the field.
Do not cover for poor visualization. That means ...

 

Source:  User Day Toolkit