I stumbled across a slideshow from David Sherwin of frog design, giving an excellent introduction to user research and how to incorporate it into the design process.  In the presentation, he answers the following questions:

1. What is user research?
2. Why should I include user research on projects?
3. When should user research be part of projects?
4. Who do we include in user research?
5. Where should I conduct user research?
6. How do I get started doing user research?

There’s so much great material in here.  Check it out.

I’m working on user research for vCloud Automation Center¹.  As we’ve been discussing the research, I’ve observed a common misunderstanding of how we talk to our users.

As I’ve been creating the discussion guide, I have been careful in my wording.  The wording that I use in the discussion guide matches, as closely as I can manage, the real-world goal of the user.  The application team has asked me why I’m not using the feature name.  After all, they say, their users already know the feature name, so why not use it?  One member of the team said that if we were studying bank accounts, we would expect that our users understood the basic concepts of bank accounts.

This is a great example of the difference between our feature name and your goal.  If I were conducting research about online banking, I would not ask a user to check their balance. Instead, I would ask them how much money that they have available².  “Balance” is the bank’s term, and comes from accounting; the user might or might not think of the contents of their bank account in that way.

Likewise, I would not ask someone to use online bill pay. Instead, I would hand them an electricity bill and ask them how they would handle it. Framing the task as a real-world scenario allows us to gather much richer data. For example, if the user says that they would write a cheque, then we can learn why they would choose to write a cheque. Thus, we could identify blockers to or concerns about using online bill pay. Once the user tells us that they would write a cheque, I would ask why they would choose that method, and then ask the user if they could accomplish the task in another way, and repeat this until they get to online bill pay (or, if necessary, explicitly point them to online bill pay). We both gather data that is specific to the workflow of paying a bill online as well as data about user thoughts, concerns, and preferences about the concept of online bill pay.

In considering your goals instead of just focusing on our features, we learn more about what you want to accomplish and how you think about it.  If we focus solely on our features, we will probably make improvements to our features.  We won’t get the benefit of the deeper insight that could lead to an even better design.

Edited 7/9 22:11 to correct a typo (thanks, @jackbrewster!).

Stef Miller wrote a great blog post about “Eight Traits of an Incredible User Experience Professional”.  The whole post resonated with me, especially this point:

7) Flexible/adaptable
Things change. In the world of agile process and scrum teams, adaptation is the name of the game. Maintaining a level of flexibility and being prepared to make iterations is a quality that speaks volumes for the nimble work done by UX pros.