Skip to content

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.

Never Enough Time

The Passage of Time

Image by ToniVC via Flickr

Like many things in life, there’s never seems to be enough time for user research. Sessions are too short, and there’s never enough time to analyze the results. What effect does this have on the quality of the research? A lot!  But surprisingly, just adding a little extra time can make all the difference.

Not enough time for sessions

User research sessions are frequently too short, leaving you to decide whether to rush through the session, trying to cover everything at a high level, or you only cover a portion of the questions. Either way, you waste an opportunity.

The time needed for research sessions is unpredictable. The focus of research always seems to expand with additional client requests and topics that you would like to cover. You never know exactly what you’ll encounter during a session. Some participants have more to discuss than others, some encounter more problems than others, and some are just more talkative. So session times can vary greatly between participants.

It’s always better to err on longer sessions. If you plan for more time than you need, no one minds ending early and getting back some extra, unexpected time. For participants, there’s not all that much difference between a one hour session and a 90 minute or two hour session. If they’re coming in to your lab, a focus group facility, or some other location, the biggest obstacle is taking the time out of their day to travel to and from the location. Once they’ve made that effort to get to you, an extra 30 to 60 minutes doesn’t make much of a difference. So plan longer research sessions to ensure you have enough time to cover everything.

Not enough time for analysis

It always amazes me that people will spend so much time and money planning, recruiting participants, and conducting the research and then provide too little time for analysis in a rush to get the findings. Analyzing user research can be extremely time consuming. Unfortunately, you rarely get enough time to analyze the results. Listening to recordings, typing up notes, organizing the notes into themes, analyzing the findings, and then creating deliverables takes time. When this process is rushed, quality is compromised.

Sometimes clients are excited by the idea of conducting research, but are too impatient to wait very long to hear the results. They are usually under the impression that by simply observing the sessions, high-level, overall findings will emerge. They aren’t concerned with taking time to analyze the details. This method often leads to shallow and misguided findings.

Of course there are reasonable limitations in terms of how much a project can wait for analysis and the presentation of the results, but often the time to analyze the results is set arbitrarily. The user researcher then either has to work extremely long hours to fit an enormous amount of work into a small time frame or has to find ways to cut corners.

User research is time consuming and expensive. After putting so much time and money into it, it makes no sense to short change the final step that provides the most value. Providing even a little extra time for analysis can make a big difference in the quality of the findings and in improving the job satisfaction of your user researchers.

The bottom line, provide more time for each user research session and more time for analysis. It won’t add that much more to the cost of your user research, and it will add a lot to the quality of the results.

Stay Involved with a Usability Review

Before software usability testing emerged in the 1980s and became more widespread in the 90s, quality assurance testing was the only way software was tested before release. Quality assurance was focused on ensuring that developed software met the defined requirements and did not contain any defects. However, requirements were rarely generated through user research. Instead they were usually generated by business stakeholders and documented by business analysts. If users were involved at all, they were often represented by a few subject-matter experts gathered in meetings to talk about what they wanted the software to do.

Bug tracking software

Quality Assurance Testing

Quality assurance analysts tested the software to find technical defects. If the software did what it was supposed to do according to the requirements, it passed the test, regardless of how usable it was or how well it fit the needs of the users.

User Acceptance Testing

“Users” and stakeholders were also involved in user acceptance testing, which was really just a sign off that the software did what it was supposed to do. Occurring at the very end of the software development process, it was difficult to make anything but very minor changes at that point. As long as the software did what it was supposed to do, stakeholders were willing to overlook usability issues. It seemed easier to write off any problems as things to address in training, rather than to require additional development work.

The Evolution of Usability

As it became obvious that this method of software development was failing to address usability issues, usability testing was added to projects in a similar manner as quality assurance, evaluating software at the end of a project to find and fix usability problems. As it became apparent that this was too late to make any major changes, usability testing gradually moved further and further forward in the design process, with multiple iterations of design and testing. Eventually people realized that it would be better to avoid problems in the first place by finding out what users really need at the beginning of the project. Proper user research was born.

We Forgot the End of Projects

Unfortunately, as we’ve moved user research and usability testing earlier in the process, we’ve tended to overlook the end of projects. We do the upfront user research through iterative design and usability testing, but once development begins, we often drop out and move on to the next project. Then when the final product is released, we often find ourselves scratching our heads, thinking, “what happened?” as we see it varies greatly from what we intended.

All kinds of things can happen between the final design iteration we test and the final coded interface. Without being involved in checking the final design and development, problems tend to slip through.

Usability Review

To solve this problem in a previous job, I created a process I called a Usability Review. During functional QA testing, a usability analyst would review the developed application looking for usability and design problems. Any issues found were entered in the QA bug tracking software (Test Director in this case) as usability or design issues and assigned to a developer to review and fix. After fixing or rejecting the problem, the developer assigned the issue back to the usability analyst to either accept or reject the solution. This worked very well and caught a lot of issues.

Advantages of a Formal Usability Review

You may think that staying involved throughout the project would be enough to find and prevent any usability and design problems, but there are several advantages to having an official, detailed usability review process.

  1. As an official step in the project, the usability review gets added to the project plan, ensuring that it will actually take place and that someone will let you know when the application is ready for review. Without that official task in the project plan, it’s easy for others to forget to notify you, and when you’re busy on other projects, it’s easy for you to forget also.
  2. A usability review requires you to examine the application in detail, rather than giving it an overview. A detailed examination tends to find more problems and gives you a more realistic sense of how well it will work for the users.
  3. Entering the issues in the QA bug tracking software gives usability and design problems the same importance and status as QA defects, makes someone responsible for fixing them, and gives you the power to approve or reject the solution.

Can’t QA People Perform the Usability Review?

Can’t Quality Assurance people find usability and design issues themselves, or can’t they be trained to do that? Yes, it’s possible, but usually they don’t have as much knowledge and experience in user experience issues, and they are not usually involved in the user research and usability testing that takes place earlier in the project. Usability and design professionals are the best judges of whether the final application matches the intended design and user experience.

When you do a usability review, you’ll often find issues that are QA defects, and the QA analysts will often find things that appear to be usability or design issues. A good way to coordinate efforts is to enter technical defects and assign them to the QA analyst to assess. The QA analyst can assign any usability or design issues that he/she finds to you to assess.

So add a usability review to your projects and you’ll find that it pays to keep usability and design formally involved all the way to the end of a project. You’ll end up with final products that more closely match the original vision.

New article: Learning the Subject Matter

As a consultant, I work with many different clients from a variety of industries. My company, Electronic Ink, focuses on designing business systems, which means our projects are usually much more complex than the typical website.

My job as a design researcher is to uncover and understand the business needs and user needs. But even before beginning stakeholder interviews and user research sessions, I have to know something about the subject matter to ask the right questions and to understand what I’m hearing and observing. There is usually very little time at the beginning of a project to get up to speed on the subject matter. When the subject matter is very complex, I find that to be the most difficult part of the project.

I recently wrote an article for Johnny Holland (the interaction design blog) about this issue. Read the entire article: Learning the Subject Matter.

New article: The Ghost Hunter’s Guide to User Research

Image by Sam Breach via Flickr

What do ghost hunting and user research have in common? That’s the question I try to answer in my latest article on UXmatters: The Ghost Hunter’s Guide to User Research.

As a fan of the SyFy Network series, Ghost Hunters, I began to see parallels between the work the TAPS team did and user research. It sounds like a stretch, but there are some interesting similarities.

At first, I was a little hesitant about publishing this story and sat on it for over a year. I worried that it might be too frivolous. But as I explored the topic further, I realized this was a humorous and interesting way to look at user research, and it seemed a perfect article to publish around Halloween.
The reaction has been very positive. I expected my article to be read by the user experience community, but I was surprised to see the attention it has received from the paranormal/ghost hunting world as well.

Read the entire article at UXmatters: The Ghost Hunter’s Guide to User Research.