Design research has been a key component of most of the projects I've been involved with at Cooper. Since it adds time and cost, sometimes we have to go to great lengths to convince clients to include research in a project. But design research isn't just about giving the design and product team a leg up on understanding user goals and needs. It's also about minimizing business risk and validating—or challenging—the current strategy. Typically, the insights we gain by talking with and observing users help our clients look at their business goals through a different lens. In addition to providing necessary input for designing successful products and services, this new perspective helps them make better decisions about the long-term trajectory of their product roadmap and approach. For some products and companies, it can be even more transformative, as the insights they gain help them re-imagine not only how to design and deliver better products, but also how to better structure their internal organization to do so.

Of course, companies can only make these kind of strategic pivots if they have the appropriate decision-makers engaged in the initiative, with time set aside in their decision-making process for integrating the input that may come out of user research. I've found that the business executives who treat design initiatives as a strategic endeavor and not just a tactical execution of product definition get much more value for their design dollar.

It’s rare, but it sometimes happens. You will be in an interview and you hear something that doesn’t quite ring true. Knowing the warning signs and what to do in these edge cases will help you make course corrections during the interview so that it is still useful.

Screen capture from Rock Star Games' title L.A. Noire

Have you ever used a public service that understood your needs? We all have horror stories of waiting in seemingly endless lines at the DMV or hunting forever to find the information we need on poorly designed city websites. Who is making sure that government uses effective design and technology to meet the needs of citizens in the 21st century?

Introducing Code for America

Code for America is a brand new non-profit that is taking on this challenge. And part of the challenge is understanding the target users of the technology. To help in that effort, Suzy Thompson and I taught a day-long workshop on Research for UX Design to the fellows at Code for America.

Code for America signage at their offices in San Francisco, autographed by the 2011 fellows

Code for America helps local city governments leverage the power of the web to become more efficient, transparent, and participatory. Built on a model similar to Teach for America, CfA encourages developers and designers to apply for a year-long fellowship, during which they will create open-source technology solutions for city governments. Out of over 300 applicants, CfA chose 20 fellows for their inaugural year, from a wide variety of backgrounds including Web 2.0 startup entrepreneurs, developers for local city governments and school districts, open source contributors, a researcher for the New York Times, a digital journalist, an intellectual property lawyer/programmer, and a museum exhibit designer.

Code for America 2011 fellows (image used by permission from Code for America)

Code for America Institute

The fellows are spending the month of January in San Francisco at the Code for America Institute, learning from guest speakers about a wide variety of topics, including treating government as a platform (Tim O'Reilly), building local communities (Danielle Morrill), being a change agent and nurturing social network communities (Caterina Fake), and taking an entrepreneurial view of their city projects (Eric Ries).

Host City Projects

Each of the fellows is assigned to one of four city teams, each with a target project:

The fellows will spend the month of February in their host cities, learning about the IT infrastructure and interviewing city stakeholders and users of their system. They will return to San Francisco in March to design and develop the open-source applications. They will present and hand-off the applications to their host cities in the fall.

Cooper Training

Because Cooper has extensive experience connecting user research to product design, Code for America asked us to come in and present a one-day workshop. From our courses on interaction design and design communication, we carved out a day's worth of materials on finding stakeholders and users, preparing an interview instrument, conducting interviews, debriefing interviews, and synthesizing and presenting research findings. We also gave them a look-ahead to personas, scenarios, and framework design.

The fellows got a chance to plan an interview instrument and conduct a 45-minute interview with members of the CfA staff. Conducting good ethnographic interviews takes practice -- I think the fellows came out of our workshop with a sense of confidence in talking to their city stakeholders and application users in February. I look forward to hearing about what they learn about their users, and to helping them create personas and scenarios from their findings. And I can't wait to see the amazing applications that result from their work.

Great Government Research and Design

A question to our readers: Where have you seen user experience design principles applied to government applications or services, to achieve an amazing outcome? At Cooper, we're currently working on a project with CalSTRS (California State Teachers' Retirement System), and in the past have done pro bono work with the SF Department of Health. I have also read about fellow Cooperista Renna Al-Yassini's service design work for the Roudha Center in Qatar. What user experience design work in the government or social service sectors has impressed or inspired you?

I recently had the opportunity to return to a place I hadn't been for quite some time--the principal's office. My last project included interviewing 11-17 year olds about their homework habits, and I needed a hall pass from the secretary. In preparing for the interviews, it occured to me that I hadn't spoken to many 'tweens since I was one myself. Would they call me Mister? Ask to trade Bakugan? And the high school kids--would they be too cool to talk to me, answering every question with nothing but a yes, no, or dismissive smirk?

As it turns out, interviewing school-aged children isn't too different from interviewing adults. But as I learned, there are a few do's and don'ts you might do well to keep in mind.

Have an adult introduce you to the child
Allow a parent, teacher, or guardian to make initial introductions. This establishes your credibility to the child and communicates the adult's consent for conducting the interview.

Treat kids like regular people (that is, like adults)
Kids can tell if you're being patronizing and will adjust their own behavior accordingly. Treat them as you would any interviewee, thanking them for their time and explaining what they should expect from the session.

Interact with them at eye level, but don't get too close
Minimize physical power dynamics by sitting in a chair or kneeling alongside kids when you conduct the interview. At the same time, be aware of their personal space and don't give them a chance to feel vulnerable or uncomfortable with your presence.

Be specific with your questions
Kids tend to be quite literal in adult conversations, so be direct with the questions you ask and the responses you give. Don't be surprised when you point to a toolbar and say "what do you think these do?" and the response is "save saves, print prints, open opens, and delete deletes."

Avoid technical and professional lingo
You've picked up a career's worth of acronyms and jargon that your interviewee will not be familiar with. Also, look for the words kids use to describe things, and use those both in your interviews and when designing for your young audience.

Don't ever take pictures or video without parental permission
There are many legal and ethical issues around photographing and videoing minors, and if you don't have a clear need for it, don't bother. If you do ask, be prepared to take no for an answer without any further discussion. Put parents/guardians at ease with things like "we only use these internally for reference" and "don't worry, this won't end up online or on TV." When appropriate, set up your video to capture the session without recording the child's face, for example by training the camera on the screen when discussing software.

Don't crack jokes or be sarcastic
Kids won't be prepared for casual joking, for as much as you work to set up a peer relationship they are still talking to an unknown adult. Jokes will often be misinterpreted as serious comments. As an example, I was running a feedback session with a powerpoint deck that ended with a blank screen. When one child clicked past the last prototype slide and into the blank screen, I remarked "OH! You broke it!" then spent the rest of the interview making him feel better that he hadn't just busted our computer.

Recognize when an interview isn't going well and finish it quickly
This happens with adults too, but sometimes you'll get a kid who just isn't able to converse with you. Spend a minute or so looking for an opening, and if you can't break through, let them out of their misery and end the interview quickly. Don't abort it or say it's not working, just ask a few easy, obvious questions, thank them for their participation, and move on.

What else?
I'd love to hear more about other people's experiences interviewing children and involving them in user feedback sessions. What advice do you have?

Here’s a quick tip for you as you conduct your goal-directed interviews with users and potential users: Leave a four-second pause after your interviewee pauses their response, allowing them to add more information or additional detail.

This is hard to do. In ordinary conversation, people will often step in and fill these silences. Especially with a stranger, we don’t want to leave the conversation “hanging,” preferring instead to offer up some response or reflection on what the other has said.

But an interview is not a cocktail conversation. The interviewer is trying to get as complete a picture as he or she can of the user’s thoughts. To help do this, we want to give them that room to think about what they’ve just said and append as necessary.

There comes a time in any parent’s life when she has the face the inevitable: Her child’s first cell phone. That time has come at last for me, and I confess I have been dreading it. What if she buys 50 ring tones? What if she calls China? What if she sends a prank photo to a friend and ends up going to jail and having to register as a sex offender for life? (That’s right, I’m a parent: I can go from “my kid might overspend my money” to “my kid might go to jail” in ten seconds flat.)

It was with utter delight, therefore, that I stumbled across kajeet, a cell phone service for ‘tweens and their parents. What sets kajeet apart is not their phones (they don’t make any), or their network (they’re essentially a Sprint reseller), but the service. With kajeet, parents can fine-tune what their kids can and can’t do, and who pays for what. You can set up separate wallets for the parents and the kid, such that the parents can pay for phone calls to Mom and Dad, but the kid has to pay for calls to friends or goodies like ringtones and wallpaper. You can set up times of day for certain activities, like only emergency phone calls during school hours. You can even track the location of your kid’s phone using its built-in GPS and online tracking tools.

When I discovered kajeet, I was in parental heaven. The service was so exquisitely tuned to my needs that I started to get professionally curious. What was the process that had led to this product?

The kajeet origin story goes something like this: Three dads saw a need, and created a company. Now, that’s a great start, but there had to be more to that story. They must have done their homework. So to learn more I spoke with kajeet’s SVP of Corporate and Business Development, Carol Politi.

I ventured out of the office last Friday, to join Bolt Peters and friends for User Research Friday at Mighty in San Francisco. Billed as “Emergent User Research Methods. And Drinks” URF08 was attended by about 150 professionals and students interested in the topic of user research. During his opening remarks, Nate Bolt talked about the benefits of user research, and remarked that “good ideas don’t just come from the guys in the black turtlenecks.” Nate’s comment got me thinking, what are the strengths and frustrations of the user research community, and how can interaction designers get the most benefit from user research techniques?

The userati: Dan Saffer, Indi Young, Cyd Harrell and Nate Bolt

Behavioral economist, Dan Ariely’s delightful first book, Predictably Irrational, heaps yet one more shovel of dirt onto the fresh but deep grave of traditional, rationalist assumptions about human behavior. The book is a simple, personal, easy-to-read account of Ariely’s research conducted over the past 15 or so years. This research was conducted at his various host universities; all of them paragons of ivy-covered scientific rigor, including MIT, Stanford, The University of Virginia, and The University of California at Berkeley.

The clear and inevitable conclusion of his dozens of research papers summarized in this book is simple: humans don’t make rational decisions. What’s more, the irrationality of their choices isn’t random, but can be predicted and measured. While many of the experiments deal with choices regarding cash, several of them cleverly divorce themselves from money to clearly demonstrate that the goofy human behavior is human-related, not cash-related.

He identifies several predictable forces that act upon humans during decision making, causing them to make irrational choices. These include the distorting effect of similar, but slightly inferior, products offered for sale; the distorting effect of simply thinking about numbers; the distorting effect of items offered for free; the distorting effect of sexual arousal; social norms, ownership, procrastination, self-control, clinging to options, expectations, and being observed.

When I picked up Jerome’s Groopman’s How Doctors Think, I imagined that it would give me a useful window into the mind of the busy clinician. On medical projects we often find it a bit challenging to get enough research time with physicians. (Aside from maybe lawyers and CEO’s, there are no better exemplars of the “time is money” mentality—American doctors, in particular.)

Dave, Doug and Noah learning how surgeons think.

While I appreciated the informal history of medical education, interesting anecdotes of diagnostic challenges and satisfying dose of medical atmosphere, I learned just as much about design and design research as I did about medicine. (I'm not surprised to discover that I'm not the first to make this connection. In her blog, Elegant Hack, Christina Wodke discusses how she thinks design education should be thought of more like medical education, with a focus on gaining experience over several years in industry, rather than just technical skill in a design program. She'll get no argument out of me there.)

The part of the book that I found most striking is Groopman's discussion of what he calls "classic cognitive errors" in diagnosing and treating medical conditions. I have made and seen each of these errors in understanding people and devising products and services to meet their needs. While explicit knowledge of these categories of flawed thinking isn't a guarantee against them, I do think that by naming them and affirming their reality (often by reference to the work of psychologists), this book can help us remember the kind of mistakes that top-notch professionals make when they're tired, stressed, egotistical, or just lazy.

Even after you’ve sold them on personas, even after you’ve explained that you want to design for a specific persona first, even after you warned them about the perils of the “elastic user,” you can find yourself hearing things like, “Well, I know this guy who would do it this way...”

To help clients who won't be put off by pop-culture references, I reference the parable of The Homer.

For those who aren’t familiar with the Simpsons episode “Oh Brother, Where Art Thou?” (Season 2, Episode 15), it plays out like this: Homer meets his long lost brother Herb, who happens to head an automobile company. Believing Homer to be the perfect “everyman,” Herb instructs his designers to make exactly the car that Homer wants.