User Research – Look and Listen

During the last few months I have been involved number of projects that involved a considerable amount of user research and testing. Through this process, I have interviewed over 50 persons for a number of digital and physical devices. 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.

  • Anonymous

    These are great tips!  As someone with only a few user tests under my belt, I realize that I’ve made several of these mistakes.  Reading a script’ really freaks people out.  It’s unnecessary – you aren’t going to alter the response by phrasing things differently.  I suppose a checklist of stuff to remember to say is good, but reading the script doesn’t help them to get comfortable or help them avoid feeling like a “cog in the research machine”.

    Thanks again – adding you to my reader. 

    Newman
    ~~~~
    Newman S. Lanier
    Builder and Co-host, http://aBetterUserExperience.com

  • Christopher

    Thanks for the feedback ! Glad you found it useful. All of these tips have come making many mistakes, so keep on going. Let me know if you have some more. /C