UsabilityWorks is Dana Chisnell

User experience research, workshops, and recruiting.

Dana Chisnell

We all pretend that these bios are written by someone else. We write them in the third person, and everything. But we all know that the person who the bio is about writes the bio.So, here I am.

What’s important about user research is understanding how best to answer the question you have. Getting the question right is tricky. I’m not an academic purist – I like to play with methods and techniques. I’ve come up with some weird approaches to answering research questions. Sometimes they even work.

Factoids:

  • I co-authored one of the seminal books about usability testing with Jeff Rubin, Handbook of Usability Testing Second Edition. It came out in 2008, and it’s still pretty relevant.
  • I like teaching non-practitioners like designers, developers, and product managers how to do user research and usability testing because I believe that you can’t make a great design without experiencing what your user is experiencing.
  • My first usability test was in 1983 (for IBM on the Professional Office System).

A new year, new stuff

It’s 2017!

In January, I’ll be teaching user research techniques in a 2-day workshop for the first  cohort at Center Centre. I’m excited to meet the students and to deliver this material in a span of time that will give everyone a chance to practice.

In February, I’ll be giving a workshop on designing for delight at Webstock with Jared Spool. This will be in delightful New Zealand.

In March, it looks like I’ll start teaching a course on designing government at the Harvard Kennedy School.


What to do with the data: Moving from observations to design direction

 

This article was originally published on December 7, 2009. 

 

What is data but observation? Observations are what was seen and what was heard. As teams work on early designs, the data is often about obvious design flaws and higher order behaviors, and not necessarily tallying details. In this article, let’s talk about tools for working with observations made in exploratory or formative user research.

Many teams have a sort of intuitive approach to analyzing observations that relies on anecdote and aggression. Whoever is the loudest gets their version accepted by the group. Over the years, I’ve learned a few techniques for getting past that dynamic and on to informed inferences that lead to smart design direction and creating solution theories that can then be tested.

 

Collaborative techniques give better designs

The idea is to collaborate. Let’s start with the assumption that the whole design team is involved in the planning and doing of whatever the user research project is.

Now, let’s talk about some ways to expedite analysis and consensus. Doing this has the side benefit of minimizing reporting – if everyone involved in the design direction decisions has been involved all along, what do you need reporting for? (See more about this in the last section of this article.)

Continue reading.


Observers are your friends

 

(This article was originally published on May 30, 2008. This is a refresh.)

 

Research that you do alone ends up in only your head. No matter how good the report, slide deck, or highlights video, not all the knowledge gets transferred to your teammates. This isn’t your fault. It just is.

So what to do? Enlist as many people on your team as possible to help you by observing your usability testing sessions. You can even give your observers jobs, such as time-keeper if you’re measuring time on task. Or, if you are recording sessions, it could be an observer’s job to start and stop the recordings and to label and store them properly.

The key is to involve the other people on the team – even managers – so they can

  • help you
  • learn from participants
  • share insights with you and other observers
  • buy in
  • reach consensus on what the issues are and how to solve them

Who should observe: Everyone

Ideally, everyone on the design and development team should observe sessions. Every designer, every programmer, every manager on the project should watch as real people use their designs. People on the wider team who are making design decisions should also observe sessions. I’m talking about QA testers, project managers, product managers, product owners, legal people, compliance people, operations people — everyone.

Continue reading.


Call centers as a source of data

Usability testing is a fantastic source of data on which to make design decisions. You get to see what is frustrating to users and why, first hand. Of course you know this.

There are other sources of data that you should be paying attention to, too. For example, observing training can be very revealing.  One of the richest sources of data about frustration is the call center. That is a place that hears a lot of pain.

 

Capturing frustration in real time

Often, the calls that people make to the call center surface issues that you’ll never hear about in usability testing. The context is different. When someone is in your usability study, you’ve given them the task and there’s a scenario in which the participants are working. This gives you control of the situation, and helps you bound the possible issues you might see. But when someone calls the call center, it could be anything from on boarding to off boarding, with everything in between as fair game for encountering frustration. The call center captures frustration in real time.

We could talk a lot about what it means that organizations have call centers, but let’s focus on what you can learn from the call center and how to do it.

Continue reading.


It’s here! Usability Testing Pocket Guide, second edition

I’ve been thinking a lot lately about where the teams I work with are on the scale from design literacy, to fluency, to mastery. I don’t mean can they talk design, I mean, how close are they to understanding the differences between good and bad design? What steps will it take to move these teams closer to mastering design to deliver great experiences?

One of the most effective tools for moving teams from literacy to fluency — getting them to the point where they can see the differences between design that will work for users and design that won’t — is usability testing.

Sometimes teams just need a tiny nudge to make better design decisions. To level up their understanding of their users. To so something about elements of a product or a service that are frustrating to users.

Sometimes, that nudge comes from a product manager or a sales ops person or a customer service rep. But this time, the nudge can come from you. This tiny book of steps and tips that makes learning from users feel simple and obvious. Like anybody can do it.

Know why you are doing a usability test

In 11 steps, your teams can work with subject matter experts and other users to collect data on the usability of their work in every sprint and all along the development path.

This 32-page, 3.5 x 5-inch book includes a quick checklist to help you know whether what you’re doing will work.

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 know you want one. Get one for each person on your team, too.

What to look for in a usability test


Talking to strangers in the street: Recruiting by intercepting people

 

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.


Deconstructing delight

 

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:

Deconstructing delight from Dana Chisnell

 

You can listen to audio of the talk from the IA Summit here.

There are also a few articles about the delight framework.


The essence of usability testing, in your pocket

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.

usability-testing-pocket-guide


Why are researchers afraid of developers?

 

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.

 

Researchers are afraid of developers because researchers feel a need to convince developers that what the researchers know is important. We plead. We make flashy presentations. We tell stories. We bring cookies. But usually, none of these works because developers don’t have to do anything with what researchers tell them.

 

The obvious answer is to overthrow HR and make it so developers are rewarded for shipping the right thing, the best thing — the finest user experience possible. This has actually happened in some organizations (not the overthrowing part, but the changing of rewards part). But barring the overthrow of HR, what can you do?

 

You could go get a new job in an organization that does reward everyone for delivering great design. You could up the quality of your bribes, uh, cookies. Or, you could get in the heads of developers to appeal to what they see as the Greater Good.

 

Here’s the thing: They’re already working for the Greater Good. Giving them research results is like trying to get a little kid to eat vegetables. You say, “It’s good for you/us/the company/users!” They say, “Whatever. I gotta ship.” How do you get them to eat their peas?

 

Consider: Stop telling a long story about how everything is broken and how we can’t possibly ship this mess. Instead, think about what 10 small things you pull out of the data that developers could change in the design that would make a positive difference for users. Small things that might also make it likely that developers will not have to sit with the app all night for the next 3 nights debugging after shipping. Small things that make it likely that later support calls will be reduced. Small things that will make it likely that more people will download and use the app.

 

These should be things that don’t take much time, won’t cause refactoring, and won’t generate much in the way of additional testing time and effort on his part. Small things that make the developer look good. And less intimidating. And more accepting. Who knows what could happen then?


Rethinking user research for the social web

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.