Skip to content

Posts from the ‘Methods’ Category

Are Consent Forms Always Necessary?

Are consent forms always necessary? We’re told that consent forms are an indispensable part of ethical user research. Consent forms are the vehicle to give and get informed consent – they inform the participants of what the study will entail and they allow the participant to indicate consent – with a signature and date.A consent form

Yet consent forms can conflict with the informal, friendly rapport that we try to establish with participants. Anything you present for people to sign immediately looks like a legal document or liability waiver. It puts them on guard.

That’s ironic because consent forms are the opposite of legal waivers. Legal documents are created to protect the interests of the company that creates them, while consent forms are created to protect the rights of the people signing them. Yet most participants assume they are signing a typical legal waiver.

Consent forms seem acceptable in more formal user research situations, such as usability testing and focus groups, but they seem odd and even off-putting when used in more informal situations. I’ve found them to be especially awkward when doing field studies at people’s offices. You strive to set up an informal situation, such as asking someone to show you how they create reports or asking them to try out a new design for an expense report application. But when you show up with a consent form for them to sign, it shatters the informal, comfortable rapport you tried so hard to establish. I’ve had people react to consent forms in this kind of situation with, “Hey! I thought we were just talking here.” How many times in the course of your work-life have you had someone show up to a meeting with a legal document for you to sign?

So I say use your judgment. When a consent form feels like it would be overly formal, don’t use it (unless your legal department requires it). Instead, get informed consent informally by email. “Inform” with your email describing what will take place, and get “consent” from their reply email agreeing to participate. At the start of the session, you can inform them again with a summary of what you’ll be doing. They will then give consent by continuing to participate in the session.

A good guideline is how comfortable or uncomfortable you feel when giving participants the consent form. If you feel uncomfortable, you’re probably breaking a group norm. So you should find a more acceptable way of getting informed consent.

Two Rarely Used Research Methods

Observing in a public areaMy two most recent articles in UXmatters have been about two research techniques that are very common to anthropology and the social sciences but are rarely used in design research. Covert naturalistic observation and participant observation certainly require more work and time than we usually have in UX projects, but it’s worth taking a look at these two methods to see what we can adapt to design research.

Covert Naturalistic Observation
This type of study is known in psychology, anthropology, and other social sciences as covert naturalistic observation. It is the opposite of the techniques we typically use, which are forms of overt naturalistic observation. Being covert means observing behaviors in their natural contexts without any intervention or influence by the researcher and without participants knowing that they’re being observed.

Participatory Observation
Anthropologists and sociologists often practice participant observation, in which they join a group as a participating member to get a first-hand perspective of the group and their activities. Instead of observing as an outsider, they play two roles at once—objective observer and subjective participant…

UX Testing?!!

Old Man Usability

Old Man Usability

Okay, now wait just a goddamn minute! UX testing? U-X testing?!! Now that’s just going too far!

You think you’re all better than me and don’t need “usability” anymore? “User experience” is a more inclusive and descriptive term about the aspects we’re interested in these days. Yeah yeah, fine. It’s more than just usability. Okay, I get it.

But keep your damn UX hands off my usability testing!!! That’s my signature method. I invented that! Talk about kicking a man when he’s down.

What am I talking about, you say? I’ve begun to notice this disturbing trend of you UX creeps stealing my method and calling it “UX” testing. Just look at this recent article from those fancy-pants, “digital marketers” over at eConsultancy: A Case for UX Testing and Agile. And then I noticed this article from last year: UX Testing and Cultural Preferences. Even User Zoom has gotten into the act with this article: 17 Questions Answered About UX Testing and Agile. And it doesn’t stop there. I just Googled “ux testing” and got 28,300 results!

Usability testing has been providing more than just usability for a long time. So in some ways I see your point that perhaps the word “usability” only describes part of what this method provides insight into.

But usability testing is the one method that’s still primarily about usability. Put participants in a lab (or test them remotely), give them tasks to perform, observe their behavior, and ask them to tell you what they’re thinking – that’s usability testing. In addition to assessing usability, it can provide information about satisfaction, emotions, and opinions, but it doesn’t give you a true depiction of the user experience. Other UX research methods give you a better picture of the user experience by observing people in their natural contexts of use. You can test usability, but you can’t really test the user experience.

And what are these people who are doing “UX testing” really doing? You guessed it! Usability testing. It’s nothing different. Just a name change.

So, I agree that user experience makes sense, but that doesn’t mean you should do a global find and replace, turning every instance of “usability” into “user experience.”

So keep your damn hands off my usability testing! It will always be “usability testing” no matter what you want to call it.

By the way, Googling “usability testing” brings up 2,110,000 results. So there!

- Old Man Usability

How is usability testing like beer?

Glass of beer

Flickr: HeadCRasher

My manager asked me recently, “Do you think usability testing has become a commodity?” He was referring to the fact that in the last year or two we’ve seen clients go with cheaper usability testing companies. He was questioning whether clients have decided that there’s no difference between usability testing companies except price. Quality isn’t a differentiator to them anymore (if it ever was).

It does seem that there are companies out there doing usability testing at increasingly lower prices. How they cut corners to get their costs low enough to still make a profit amazes me, and it makes me wonder what kind of quality the clients receive.

Then an analogy dawned on me – usability testing, as a consulting service, is like beer. There are many people out there who are perfectly happy drinking cheap beer. It’s cheap, it’s bland, but it does the trick in the end – it gives you a buzz. But that doesn’t mean everyone is satisfied with cheap beer. There are still those out there who appreciate and will pay more for craft beer with quality, taste, and a better buzz.

If you want cheap usability testing, you can get it. It won’t taste good or be the best quality, but if all you’re looking for is a cheap buzz, it will do the trick in the end. On the other hand, if you have a sophisticated enough palette, you’ll be able to tell the difference between cheap usability testing and craft usability testing, and you’ll be more satisfied in the end. The bottom line is: you get what you pay for. There’s usability testing out there for all tastes and budgets.

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.

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.

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.

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.

Follow

Get every new post delivered to your Inbox.