0

I am going to be running small on-site user observations for UX research for a mobile application that uses voice.

I have never conducted a user observation session, I've read a lot of articles on NNGroup and other UX and usability sites. I've read how to run a User Observation session like this article and a course on UX research and data on Lynda.com but nothing has given me a conclusive or comfortable answer to: How to / should I prompt and guide the user to use the product during a on-site visit?

If I want to see how they use the product after a sales call, should I prompt the user to use specific features of the app or should I just watch what they do with the app without saying a word?

If they ask me how to use a feature should I tell them? Of course this is based on what the observation is trying to achieve. I want to see how a sales person would use the app without prompting them. But let's say they've never used the app and have no context - do I provide this?

I can imagine a user would get frustrated if they had no idea what I expect of them. If I tell them "I want you to add details on your client to the app" is that interfering with the study? I want to see if they add details to their client and what troubles they get when they try to do so.

I know some of these questions are a bit subjective, but keeping data honest is important and I am looking for the best way to do so.

1

You should provide context by giving the user a task that involves them using the features you want to observe. E.g. Imagine this is your first time using the app, what would you do? A task that's framed in the user's context and not too specific.

If a participant asks how to use a certain feature (which they tend to do), you can tell them to imagine they are trying to do this on their own and get them to show you. It can be difficult to watch someone struggle with UI but that's the point of user observations. I try to let participants go as far as they can and if they still fail or get really frustrated and give up, I'll mark that as a failure. I would then give them some hints on what to do and get their feedback on that.

0

This is a difficult question to go into details, but there are some general principles that I have found more practical then others when you want to end up with data that is going to be useful and usable from research to the design phase of your project. This is assuming that you are going in with a specific question you are looking for answers to, or a particular hypothesis you are trying test.

  • Separate fact from opinion so that you don't mix your assumptions with the observations
  • Understand the effect of your actions on the response of the user
  • Try to find supporting evidence or additional context for your observations
  • Be prepared to adjust or adapt your approach to find the insight you are looking for

I think the first three points are important because we don't design enough based on facts and even though we are doing our best not to influence the results, it is often unavoidable. The best way to minimize the impact of this is to anchor the findings around facts and the context that determine how the user responds to the environment in which they have to carry out their work. It will also help you trace your findings back to their original source if you need to come back and dig a bit further.

I think the last point is often controversial because most people want to have a nice and consistent methodology so that they can repeat the research and be confident that they haven't introduced other variables in the results. However, if you are unable to get the information you need from the user based on your approach, the focus should be on what is the best way to get the information that you need so you can help solve their problem rather than sticking to a script or process for the sake of it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.