Wired posted an interesting opinion piece about user research, although its title is about startups and innovation.  The central point of the article is that startups often skip user research on the theory that they can fail fast and pivot to the next thing, and that this works but has a massive opportunity cost associated with it¹.  This paragraph quite nicely sums up many of the arguments against doing user research:

When the research focuses on what people actually do (watch cat videos) rather than what they wish they did (produce cinema-quality home movies) it actually expands possibilities. But a common concern and excuse for not doing research is that it will limit creative possibilities to only those articulated by the target users, leaving designers devising a faster horse (lame) rather than a flying car (rad).

Research isn’t transcription.  There’s a lot of other things that research is and isn’t, and the Wired piece is a great starting point to learning more about it.

Of all of the methods of doing user research, contextual inquiry and ethnography are two of my favorites.  They help you understand your the context that your user is operating in.  Working for VMware, I often think about this in terms of what is happening in a system administrator’s datacenter, what their workspace looks like, what kind of mobile devices they use and why, and so on.

These methods are important for consumer products as well.  Take, for example, Procter and Gamble’s newest men’s razor for the emerging Indian market.  They knew from talking to Indians living in America about some characteristics of Indian men that they would have to take into account in designing their razor.  They even tested a new razor on Indian students at MIT, and that razor failed.  It took a trip to India to understand the context of men shaving there for them to fully understand the user need.  Indian students at MIT had running water to rinse their razor in.  Men in India were using a cup of water to shave, doing it in the dark without a mirror, and the process would take around a half-hour.  They also learned that not cutting themselves was a much larger concern for men in India.

The whole article is a really interesting read about what happens when you think you know your user, or when you think you’ve got a pretty good stand-in for your user.  P&G didn’t know their user, and they didn’t know their context.  Once they understood their user, their concerns, and their context, they were able to develop a razor that captured 9% of the market in India, bringing P&G’s overall market share to 49.1%.

(Thanks to @JakeHercules for the pointer to this article!)

When I interview candidates for user research roles, one of the questions that I am always looking to answer is how the candidate has ensured that their research results were acted upon.  For researchers who work inside a company, I want them to have ownership of their research results and recommendations based on the research.  I don’t want them to just throw the report over the wall and hope that someone on the other side of the wall will do something.  I want them to own those results, to work with teams to ensure that they understand the results and the recommendations, to help brainstorm ideas if the recommendations can’t be contained in this release.  It doesn’t help anyone if a researcher conducts fantastic research if the product doesn’t become better as a result of that research.  The best research is the research that impacts the product.

I recently had a conversation with another researcher who was frustrated.  He had done some great research, and had shared the results and recommendations with the team, and had been working with the team to ensure that they understood everything and would be able to take action on them, and was even tracking bugs o ensure that things were getting into the product.  He was doing everything right.  And then he finds out about a meeting after it was already 90% done, in which someone else was talking about the area that he had researched.  The presenter was sharing the researcher’s results and recommendations, and was discussing next steps.  The research results had gone rogue: they weren’t accompanied by the researcher who had a deep understanding of them, and they were being used by someone else who mostly (but didn’t completely) understand them for a different purpose and with a different audience than originally intended.

The researcher was upset: he had put a lot of work into creating, conducting, and disseminating that research.  It barely got acknowledged that the user insights that the presenter discussed were insights from the researcher, let alone that some of the slides were actually taken from the researcher’s presentation.  The researcher felt like his work wasn’t being acknowledged, and that he was being cut out of discussions about this area where he could continue to contribute.

His feeling was valid.  He should have been acknowledged for the work that he had done, and how his work was forming the basis for what the presenter was discussing as future work to be done.  His frustration is completely understandable.  The presenter should have contacted him to ask permission to re-use his slides, as well as get him involved so that he could help address follow-up questions about his work.

I reminded him that there was something really positive in all of this.  He had done all of the right things.  He had done them so well that his research is now just part of that team’s DNA.  It’s part of what they use to make decisions, and now it’s an important part of what they’re using to go forward.  This is one of the best possible outcomes for user research: not only does the team understand it and are taking action on it, it has a continuing impact as they think about what they should do next.  We talked about strategies to get him involved with the ongoing conversation so that he can contribute other things that he learned in conducting that research, as well as help with additional research as they move forward.

Research results can go rogue.  This can be good, this can be bad.  It’s frustrating either way, but I’m so glad that these rogue results are being used for good, and that there are ways that it can be managed to help rope them back in and grow those research results into an even better understanding of our users, their needs, and the challenges that they face.  He did a great job with the research, so good that his research is something that the team has forgotten was something that they didn’t know and couldn’t make headway on until he did that work.  We often talk about how a good UI should fade into the background.  Maybe that’s true for good research as well: it’s so good, and the results and recommendations are so much a part of what we do and so important to our understanding of our product and our user, that we forget that research happened at all.

Kathy Sierra nails it again in her latest blog post “Presentation Skills Considered Harmful”.  She makes the most awesome point that focusing too much on your presentation skills, and not about why your audience wants to see your presentation, means that you’re focusing on the wrong thing.  Focus on your audience and what they will take away.

It’s hard to pick out one quote, so I’ll go with this paragraph:

When you design for a user experience, you quit focusing on your skills and start focusing on their skills. What experience can you help them have? Can you give them a more powerful perspective? Can you give them a new idea with immediate implementation steps they can’t wait to work on? Can you give them a clear way to finally explain something to others that they’ve been feeling but could not articulate? Can you give them a new tip or trick that has such a high-payoff it feels like a superpower? Can you give them knowledge and insight into a tough topic, so they can have more interesting, high-resolution conversations in the hallway?

You might need to improve your presentation skills or style so that your audience can focus on the important message of the presentation.  She puts it this way: “I am a UI.  Nothing more.  And what’s a key attribute of a good UI?  It disappears.”