Intercepting is an exercise in self-awareness. Who you choose and how you approach them exposes who you are and what you think. What your fears are. The inner voice is loud. As a practice, we worry about bias in user research. Let me tell you, there’s nothing like doing intercepts for recruiting that exposes bias in the researcher.
Why would you do recruiting by intercepting, anyway? Because our participants were hard to find.
Hard-to-find participants walk among us
Typically, we focus recruiting on behaviors. Do these people watch movies? Clip coupons? Ride bicycles? Shop online? Take medicine?
The people we wanted to talk to do not take part in a desired behavior. They don’t vote.
We did intercepts because we couldn’t figure out a way to find the people we wanted through any conventional recruiting method. How do you recruit on a negative behavior? Or rather, how do you find people who aren’t doing something, especially something they are likely to think they should be doing — so they might lie about it?
Continue reading Talking to strangers in the street: Recruiting by intercepting people
Maybe you just read Jared Spool’s article about deconstructing delight. And maybe you want to hear my take, since Jared did such a good job of shilling for my framework.
Here’s a talk I did a couple of years ago, but have been doing for a while. Have a listen. (The post below was originally published in May, 2012.)
Everybody’s talking about designing for delight. Even me! Well, it does get a bit sad when you spend too much time finding bad things in design. So, I went positive. I looked at positive psychology, and behavioral economics, and the science of play, and hedonics, and a whole bunch of other things, and came away from all that with a framework in mind for what I call “happy design.” It comes in three flavors: pleasure, flow, and meaning.
I used to think of the framework as being in layers or levels. But it’s not like that when you start looking at great digital designs and the great experiences they are part of. Pleasure, flow and meaning end up commingled.
So, I think we need to deconstruct what we mean by “delight.” I’ve tried to do that in a talk that I’ve been giving. Here are the slides:
You can listen to audio of the talk from the IA Summit here.
There are also a few articles about the delight framework.
I’ve encountered a lot of user researchers and designers lately who say to me, “I can’t do all the testing there is to do. The developers are going to have to evaluate usability of the design themselves. But they’re not trained! I’m worried about how to give them enough skills to get good data.”
What if you had a tiny guide that would give your team just the tips they need to guide them in creating and performing usability tests? It’s here!
Usability Testing Pocket Guide
This is a 32-page, 3.5 x 5-inch book that includes 11 simple steps along with a quick checklist at the end to help you know whether you’re ready to run your test.
The covers are printed on 100% recycled chipboard. The internal pages are vegetable- based inks on 100% recycled papers. The Pocket Guides are printed by Scout Books and designed by Oxide Design Co.
You can order yours here.
The other evening I was at a party with a whole lot of UX-y people, some of them very accomplished and some of them new to the craft. I grabbed an egg nog (this is why I love this time of the year!) and stepped up to a cluster of people. I knew a couple of them, and as I entered the circle, I overheard one of them saying that he had attended a workshop at his place of work that day on how to talk to developers, and it had really helped.
“Helped what?” I said. But what I’d thought was Good lord, it’s not as if developers are a different species. What’s going on here? As I listened longer, I heard others in the circle sympathize. They were afraid of the developers who they were supposed to be on the same team with.
Researchers are intimidated by developers because developers have two superpowers. They Make and they Ship. Researchers don’t. Researchers and the data they produce actually get in the way of making and shipping.
Developers are not rewarded for listening to researchers. They’re generally not rewarded for implementing findings from research about users. Learning about research results means that it takes more time to do the right thing based on data. (Let’s not even get into getting developers to participate in research.) It makes it harder and more time consuming to ship when you pay attention to research data. Everything about application development methodology is optimized for shipping. Application development processes are not optimized for making something superb that will lead to an excellent user experience.
Continue reading Why are researchers afraid of developers?
While the Web has evolved from flat documents to being fluidly ambient, we’re using user research methods from 1994. In this session, Dana presents 5 major issues confronting UXers working in the social web, challenges you to creative solutions, and shares experiences from pioneering researchers.
Watch the video of this talk from ConveyUX in 2013 in Seattle.
Or, check out the slides, below.
I gave a virtual seminar for UIE in October 2013 about how to look at recruiting participants for studies as bonus user research.
You can get the archived seminar from UIE.
Or, have a look at the slides.
In the fall of 2012, I seized the opportunity to do some research I’ve wanted to do for a long time. Millions of users would be available and motivated to take part. But I needed to figure out how to do a very large study in a short time. By large, I’m talking about reviewing hundreds of websites. How could we make that happen within a couple of months?
Do election officials and voters talk about elections the same way?
I had BIG questions. What were local governments offering on their websites, and how did they talk about it? And, what questions did voters have? Finally, if voters went to local government websites, were they able to find out what they needed to know? Continue reading Crowd-sourced research: trusting a network of co-researchers
She wrote to me to ask if she could give me some feedback about the protocol for a usability test. “Absolutely,” I emailed back, “I’d love that.”
By this point, we’d had 20 sessions with individual users, conducted by 5 different researchers. Contrary to what I’d said, I was not in love with the idea of getting feedback at that moment, but I decided I needed to be a grown-up about it. Maybe there really was something wrong and we’d need to start over.
That would have been pretty disappointing – starting over – because we had piloted the hell out of this protocol. Even my mother could do it and get us the data we needed. I was deeply curious about what the feedback would be, but it would be a couple of days before the concerned researcher and I could talk. Continue reading Just follow the script: Working with pro and proto-pro co-researchers
There’s a usability testing revival going on. I don’t know if you know that.
This new testing is leaner, faster, smarter, more collaborative, and covers more ground in less time. How does that happen? Everyone on the team is empowered to go do usability testing themselves. This isn’t science, it’s sensible design research. At it’s essence, usability testing is a simple thing: something to test, somewhere that makes sense, with someone who would be a real user.
But not everyone has time to get a Ph.D. in Human Computer Interaction or cognitive or behavioral psychology. Most of the teams I work with don’t even have time to attend a 2-day workshop or read a 400-page manual. These people are brave and experimental, anyway. Why not give them a tiny, sweet tool to guide them, and just let them have at it? Let us not hold them back. Continue reading Coming soon…
In 2004, Ginny Redish and I, along with Amy Lee, conducted a review of the relevant literature — research by other people — about designing for older adults (people over age 50). Doing this changed my thinking about universal design.
It wasn’t enough to generate design heuristics. We also came up with ways to operationalize them. That is, you can actually test to see if you have implemented these design practices by answering several questions about each heuristic.
Here’s an article from Technical Communication (which, by the way, was the runner-up for best article of the year for that publication) in which we describe the project, list the heuristics, and talk about some of our results in using them.