Skip to content

Too Cool for Your Usability Test

CoolNo matter how well you recruit representative participants for a usability test and no matter how well you plan the testing, there are times when you’ll ask participants to perform a task that they might not normally perform themselves. It’s rare that every task you ask people to perform matches exactly what they would do. When this happens, most participants are agreeable enough to just “play along” for the purposes of the test.

Sure, it’s good to know what a participant would normally do instead of your planned task, but that’s more useful to learn during field studies. During a usability test, you usually just want to observe how well people can perform tasks.

During a recent usability test of an intranet design, I asked participants to browse the Blogs section to test out the usability of the filtering and searching functions common across the various sections of the intranet. I used the Blogs section as an example because that was the section we had built out in our prototype. Unfortunately, I came across two participants who were “too cool” to read blogs. In fact, they were too cool to even play along with my ridiculous and demeaning scenario.

It went something like this:

Me: Show me where you’d go if you wanted to see all the blogs in the company.

Joe Cool: Oh, I wouldn’t do that.

Me: Why?

Joe Cool: I don’t read the blogs.

Me: Why is that?

Joe Cool: Who cares about blogs? I don’t have time to read blogs.

Me: Okay, but if you did want to see all the blogs, where would you find them?

Joe Cool: I really wouldn’t do that. People here don’t really pay attention to the blogs. Who has time for that? We have enough to do with…

[Two minutes later]

Me: Okay, well that’s good to know, but just for the sake of this session, let’s say that you did want to read the blogs, where would you go to do that?

Joe Cool: [Sigh] Well, I guess I’d go here, and – here it is. But you see the problem with blogs is that…

[One minute rant later]

Me: Okay, what would you do if you wanted this to show you the most popular blog posts in the company?

Joe Cool: I don’t really care about what other people think is popular, especially from people who read blogs.

Me: Okay, but if someone else wanted to see the most popular blog posts in the company, what should they do here?

Joe Cool: Maybe they should ask someone else who reads blogs a lot? Or they should get a life and do something more productive.

Me: Okay, let’s move on to the next part…

Luckily, the next task was cool enough for him. Sometimes that’s all you can hope for.

How Many Brains is Your User Research In?

Brain

(Photo credit: Wikipedia)

Sure, it saves time to skip official research deliverables and just apply the research knowledge you’ve learned directly to the design, but it’s shortsighted. Unlike design, which leaves behind a tangible artifact that you can see, feel, and use; user research consists of abstract knowledge locked in the brain of the researcher until it’s presented effectively in a deliverable. If that knowledge isn’t officially captured and presented understandably to others, it tends to get lost over time.

That became clear to me recently when I was asked to take over a project for a Researcher who was leaving our company. Because of a very short timeframe, there was no official deliverable from her contextual inquiries, only informal notes. She was asked to give me a “knowledge transfer,” and provide me with her high-level notes. Needless to say, the knowledge transfer didn’t go very well, and she left the company taking her brain with her, including all the research it contained.

A similar mistake occurs when multiple researchers work on a project, dividing up the sessions between themselves. To project managers and clients, that can sound like a great idea. Two researchers can either get the research done in half the time, or they can double the number of participants in the same time frame. The problem is that instead of building up knowledge through repetition, each researcher only has the knowledge of half of the sessions. To analyze the results, they have to then somehow combine what they observed.

So until they invent a direct brain-to-brain transfer device: attend every session, don’t split up sessions between multiple researchers, and produce effective and comprehensive deliverables to document your findings for future generations.

What’s Wrong With Usability Anyway?

old man

Old Man Usability

 

Okay, fine. I get it. You don’t think that I, usability, am cool anymore, and you don’t want to be seen with me now. I’m the dorky, embarassing parent, and you want to hang out with your cool, “user experience” friends. That’s okay. It’s only a natural part of growing up, I guess.

 

Although I brought you into this field, gave you your first job, supported you, and brought you respect and recognition, I guess you’re ready to go out on your own now, and you need to establish your own identity. That’s understandable, but I must admit I was a little hurt when even my most loyal child, the Usability Professionals Association changed its name to the User Experience Professionals Association. Okay, actually that one hurt a lot.

Don’t get me wrong, I do admit that “user experience” makes sense. There’s more to what people experience than just usability. I realize that. But don’t ever forget that usability is still very important. In fact, I’m probably the most important of the elements that make up user experience. If something isn’t usable, then it can’t really be useful, desirable, or valuable can it?

In fact, most of what you and your friends do under the name “user experience” today is what we did back in my day, under the name “usability.” So I don’t really see the big difference.

I think I deserve a little respect, though. I spent many years making a name for myself and getting people to think about the needs of the user. The current popularity of user experience wouldn’t be possible without the trail I blazed first. At least people know my name, usability, and what it means. Try finding a consistent definition of user experience, ha!

So after all I’ve done for you, this is the thanks I get? People declare that usability is old, tired, boring, uncool, not innovative, and even claim that I’m dead? Just wait until you have offspring of your own. See how you feel when they move on from user experience to the next buzz word.

Already I can see it beginning. Everyone’s jumping on the bandwagon and calling themselves a user experience professional these days. The term user experience is getting too broadly defined and overexposed. I can feel the pendulum starting to swing back. At this point, I’m so uncool that I’m actually becoming cool again. Soon I’ll be able to say, “I’m back!” Just you wait and see!

Tattle Tale Participants

Have you ever come across a tattle-tale participant? See if this sounds familiar.

You conduct a user research session (interview, contextual inquiry, focus group, etc.), asking simple questions to get the participants to speak about the subject at a basic level of understanding. Although you may know some of the answers to the questions you’re asking, you ask the questions anyway to hear the answers from the participants’ perspective. Misunderstanding your intent, the participant is alarmed that you don’t know what you’re doing and tattles on you to the client, “It was clear from his questions that he didn’t know anything about our process/system/technology.”

For example, a few years ago I was doing research on a company’s use of SAP. We had a group of interns show us the HR tasks that they do in SAP. Our questions led them to conclude that we didn’t know anything about SAP (which was mostly correct). They tattled to their manager who contacted our main client, alarmed that we weren’t SAP experts. Fortunately, he reassured her that we were user experience experts, and we weren’t supposed to be SAP experts.

What turns a participant into a tattle tale? Usually, it comes from a misunderstanding of our role. As user experience consultants working on many different projects, we constantly have to learn about new organizations, new systems, new processes, new technologies, and new types of people. We interview business stakeholders and conduct user research to learn about these things, but our goal isn’t to become experts. In fact, it’s often better to not be an expert. We have the advantage of seeing a group, system, process, or set of tasks from an outside perspective. Because we don’t already have the same insider knowledge as the business stakeholders and participants,  we can get them to explain things to us as outsiders. To do this, we often need to ask basic questions and sometimes even act “dumb” to get participants to fully explain things that they would otherwise forget to explain or gloss over at a high level.

The worst thing about tattling is that it can make us afraid to ask questions for fear that they might expose our “ignorance.” So make it clear who the experts are – the users and the business stakeholders, and where your expertise lies – user experience. Combining the expertise of business stakeholders, users, and user experience professionals is the key to a successful project.

Caring for Your User Researcher

Affectionate dog

Affectionate dog (Photo credit: Wikipedia)

Congratulations! You are now the proud owner of a user researcher. Treat him or her well and you’ll have years of effectively designed products. This guide will help you in the care and nurturing of your user researcher.

Feed your researcher well

  • Research days are often very busy and unpredictable. The most important person to consider on these days is not the clients or other observers; it’s the person who has to remain sharpest – the researcher.
  • Make sure your researcher is well fed and has enough time to eat meals. This will provide the energy needed to concentrate on the research session.
  • You may remember the meals, but don’t forget the snacks. If everyone else gets cookies, make sure you save some for the researcher.

Avoid burnout

  • Research is often very mentally challenging. It’s easy for your researcher to get burned out, and when that happens, he or she can’t operate at top form, which could mean missing things or not asking the right questions.
  • Don’t schedule too many sessions in a single day. Four to five usability testing sessions and three or four field studies are about the maximum before burnout sets in.
  • Provide enough breaks between sessions, and allow your researcher to relax during those times.
  • Don’t fill the break times with meetings or discussions with clients. Provide time to rest the mind. Your researcher may need to step away and have some alone time.

Provide variety

  • Most researchers don’t want to do the same things all the time. If you don’t provide enough variety, eventually he or she will seek variety by going to another company.
  • Provide variety in the following aspects: clients, platforms to work on (websites, intranets, mobile devices, software, products, service design, etc.), research activities (usability testing, unmoderated studies, field studies, etc.), and types of people to work with.

Let your researcher run free

  • Don’t micromanage your user researcher. Trust his or her judgment.
  • Provide input on what you want to learn from the research, review the research plan, but give your researcher the independence to make the final decisions on how to accomplish the research goals. Remember you selected your researcher for his or her expertise. Listen to it.

Provide enough time to do quality work

  • Ensure that your researcher has enough time to plan the research and analyze the results.
  • Understand that your researcher will often get very interested and involved in the results and will want to produce a thorough deliverable. If there is time, allow for this.

Give praise and recognition

  • Like most people, your researcher will appreciate praise, recognition, and rewards for a job well done.
  • Your researcher will appreciate it when people take the user research seriously and appreciate the findings.

Let your researcher out to play with others

  • Your researcher will often interact with users, but otherwise, research is often a solitary activity that can get somewhat lonely.
  • Encourage your researcher work with others on the project team, such as designers and developers, to provide a more well-rounded perspective of their work and to give them a first-hand insight into the research.
  • Don’t exclude your researcher as soon as the research part of the project is completed. Keep your researcher around to use his or her valuable knowledge in the design and development phases.

Encourage your researcher’s development

  • Encourage your researcher to keep up with developments in the field by reading books, reading blogs and other Web resources, and attending events.
  • Encourage him or her to publish, present, and attend conferences and other industry events.

By following these guidelines, you should have a long and healthy working relationship with your user researcher. Good luck and have fun!

 

New Article: Capturing User Research

My latest article for UXmatters is about Capturing User Research. It discusses the pros and cons of various methods of capturing user research from handwritten notes, typing up notes on a laptop or tablet, having someone else take notes, recording the audio, recording with video, taking photos, logging, and simply relying on your memory. 

Read the entire article at UXmatters: Capturing User Research.

IA Summit 2012 presentation: User Research is Unnatural (But That’s Okay)

I just got back from the IA Summit 2012 in New Orleans, where I presented User Research is Unnatural (But That’s Okay). Yes, that may seem like a strange topic for a user researcher to present, but I think it’s very important to remember how strange and unnatural user research can seem for participants. The point of my presentation is that by remaining aware of the awkward and uncomfortable aspects of user research, we can take steps to minimize or eliminate those problems to get better research results.

See my slides on Slideshare:  User Research is Unnatural (But That’s Okay)

This was my first time attending the IA Summit, and it was a great conference with some excellent speakers and intriguing topics. As a user researcher who more often attends UPA and CHI conferences, it was interesting to attend a more design-oriented conference. I’m already looking forward to next year’s IA Summit, which will be in Baltimore.

New article: Communicating User Research Findings

My latest article for UXmatters is about Communicating User Research Findings.

I’ve created a variety of different types of deliverables over the years, to communicate my findings and recommendations from user research. It can be difficult because you often have a variety of different people in the audience, from management, product owners, designers, and developers. Each brings a different level of interest in the findings.

This article discusses the considerations of choosing a deliverable format, types of deliverables, and elements of effective deliverables.

Read the entire article at UXmatters: Communicating User Research Findings.

The Seven Stages of Conference Acceptance

My UPA 2011 presentationDecember was that time of year again – conference proposal notification season.

If you’re slightly neurotic like me, you submit proposals to conferences thinking, “What the heck? It’s worth a shot. It probably won’t get accepted, but at least I’ll feel good that I tried.”  Then you forget about it for a few months until you get an email notifying you of the status of your proposal. You open the email a little apprehensively, and perhaps you go through the same stages I go through…

1. Skepticism

Okay, brace yourself. You probably got rejected. Well, whatever happens, at least I tried.

 2. Surprise

What?! Accepted?! Is that right? Wait, let me read this again.

 3. Elation

I can’t believe it! They accepted it! Awesome! I feel really honored.

 4. Terror

Oh my God! They accepted it. I have to actually come up with a presentation now. When’s the conference? March?! What if I can’t come up with anything by then?

5. Self-Doubt

Why did I submit this proposal? Who do I think I am? I have to go up in front of all those people who really know what they’re doing. This is when they’ll finally find out that I’m a fraud. Well maybe there won’t be that many people attending anyway, because who would want to go to this topic over all the other choices? Wait, what if no one attends my session?!

6. Rationalization

Okay, calm down. Don’t panic. This is probably a normal reaction. A lot of people probably feel the same way when they get accepted. I have about as much experience as these other people. And they wouldn’t have accepted this proposal if they didn’t think it was a good topic. It beat out a lot of other proposals. I can do this. I give presentations all the time at work. And I’ve seen a lot of bad presentations at conferences. Surely I can do better than those.

7. Acceptance

Okay, I can do this. It may be difficult, but I’ll make it through. It may be scary, but it will be a good experience, and I’ll be a better person for it. Let me just send in my official acceptance before I lose my confidence and back out.

What comes next? – The stages of preparing a presentation for a conference, which include multiple iterations of fear, self-doubt, rationalization, determination, and satisfaction. Ultimately, the conference comes, you give a successful presentation, it’s a rewarding experience, and you realize that none of your fears actually came true.

By the time Fall rolls around again, you’ve forgotten all about the fear and doubt, and you submit more conference proposals, thinking, “What the heck? It’s worth a shot. It probably won’t get accepted, but at least I’ll feel good that I tried.”

New article: Career Advice for User Researchers

I just published a new article in my Practical Usability column in UXmatters: Career Advice for User Researchers.

As I approached the ten year anniversary of my first job in usability, I started to reflect on all the things I’ve learned over the years. Originally, I was going to distill the main lessons I’d learned over those years into an article tentatively titled, “Ten things in Ten Years.” Well, I never got around to completing that article, and the ten year anniversary passed. Eventually, the idea evolved into career advice for people new to user research, and I finally got around to publishing it around my 11th anniversary in user research.

The article covers a lot of practical advice for people considering a career in user research, including the following topics:

  • Do you want to be a User Researcher, a Designer, or both?
  • Who do you want to work for?
  • What type of employee do you want to be?
  • Why type of projects do you want to work on?
  • What value does the company you’re considering place on user research?
  • Where does the company you’re considering draw the line between research and design?
  • What is the prestige and reputation of the company you’re considering?
  • Does the job title matter?
  • Where do you want to work?
  • How do you break into the field?
  • Do you need a portfolio?
  • How to cultivate your online presence.
  • What to do once you have a job.

Read the entire article at UXmatters: Career Advice for User Researchers.