Related posts:

There are already a large number of posts discussing user research planning and structure so I didnt really see the need for one more. What I did want to document, is the ‘people’ aspect of the research and summarize which techniques that worked well for me.

1. Listen – If I say listen, this is a bit obvious, but I am surprised at how many people that don’t really listen during user tests. Whether this is to get through the test as fast possible or an over concentration on the task at hand, people sometime fail to listen. To assist the dialog I often try to use the same terminilogy as the participants. An exmple of this is when I interviewed bus drivers as part of a new instrument panel study I asked them which term they used to describe the panel anc continued to use the same term. (Interestingly, this was not the same term the manufacturer (client) chose to call it.)

2. Use two people to conduct a user test if possible. This will depend on the client, scope of the project and overall goals but overall results improved. This will allow one person to facilitate the interview itself and fully concentrate on the test person. I find that test persons are quite sensitive to distracted facilitators and the overall quality of the results are better. The second person can then concentrate on documenting the research and making sure the technology is working (which is often a challenge).

3. People don’t open up until they are comfortable. For some test persons this never happens, but for most some simple techniques can insure this happens fairly quickly. If the test scenarios don’t require it, try to keep the lighting as low as possible. I try to have ample space to conduct the interview. No one likes to feel cramped. Water, coffee, fruit and candy all help to get test persons to exchange freely. In general, I often start the interview with a few non-intrusive background questions. It is important to view the interview person as an individual and not just a ‘cog in the research machine’.

4. Don’t help too much. I am quite guilty of this. Very often we designers, after spending countless hours thinking about a solution, have a difficult time just letting people be in their attempts to understanding the interface. The goal of the research to to get feedback of the process and the outcome and things take time.  Be patient – just give it five minutes, before jumping in.

5. Don’t use a script. When testing people try to be as authentic as possible. The same rules apply to presentations as well as interviews. When someone sits and reads a script, test people sense this and I believe react accordingly. Very often the script is pre approved by the client to insure that everything is included in the test. In this case, I usually take the script and distill it down to a few keywords and then ‘talk’ around each these trying to weave the questions in tot the discussion. Improvisation is key here.

These are what I have come up with so far.

If you have any more good tips let me know.

Christopher McCann

Christopher has been developing user friendly information systems, websites and applications since 1996. Presently, he works as an Interaction Designer and Strategist located in Stockholm, Sweden. You can follow him on his blog and Twitter at @letterpress_se.

2 comments on this article

  1. Rowan Zajkowski on

    Great and very helpful post! I’ll be adding it to my ‘guerilla testing’ class next week. Thanks! As an addition to number 4, I found out that having someone else test my designs is the best way to avoid the ‘too much helping’. But of course this is not always possible. :)

  2. Elley Jones on

    Great post Christopher, especially the final point about not using a script. I personally believe this ability to throw away the script yet still cover off all the key research questions is what makes the difference between a good researcher and a great one.

    By throwing away ‘the script’ you’re turning the session from a test into a conversation between two people. This essentially forces you to improve your listening skills and naturally makes it much easier to quickly develop a good rapport with participants.

    Whilst it is more challenging to throw away the script and think on your feet, the quality of insights that you can gain from the session more than make up for it.
    Another perk is that its often much easier to gain constructive feedback and sign off from clients on a discussion guide when questions in it are phrased as a combination of research questions and business objectives rather than simply a linear script of pre-prescribed tasks and questions to ask participants.