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 ... |