One of the main role of the researcher, is to provide quality, reliable
data to the product team. However, it is not quite as easy as it may
seem. Researchers, for lack of appropriate information or skill, may be
at risk of generating data lacking in quality. There are multiple
strategies that can be taken to ensure the highest quality of the data
being collected, including careful review of the research protocol and a
general skeptical approach to one’s research methodology. In this post,
I’ll introduce the underlying reason why a good researcher should
always initially cast a critical eye on the data he is being fed, and
apply this to his own data. I will then discuss some common threats to
good data collection I have encountered in recent weeks, and in
particular the threats of bad recruitment.
As a user experience researcher, your goal is to provide knowledge to the product team about the audience they are designing for(*).However, the effort spent creating that knowledge is ultimately wasted if it is not appropriately shaped to support the product team’s processes and needs. The ultimate goal of a UX researcher is to empower product teams to make decisions that make sense from the user’s perspective. To do so, UX researchers have to provide not only good and reliable insights, but in a manner that sparks their collaborators’ interest. Dr. Monty Hammontree, director of our UX organization, describes this as the degree of engagement between the product team and the user insights you provide. At the bottom of a scale is awareness, where the team knows about your research output. At the top is action, where the team makes design decisions based on the deep and rooted knowledge you have provided. As a UX researcher, you want to achieve the highest level of engagement of the product team with your insights.
In certain ways, this discussion of the rules of engagement with a product team reminds me of a fascinating paper on participatory design trade-offs by Michael Muller [1, 2] which I read for my Ph.D. thesis . What is fascinating is that as a designer planning your participatory process, the approach pans from going into the users' world to bringing the users in the design world. It is not a binary space, but rather a continuum. The same applies to communicating research and making your research meaningful to the product team. You can take the product team into the user world and get them participating, or you can yourself go into the product teams' world and provide insights from the inside. Chances are, there is not one good solution for every problem. Rather, the researcher has to adapt to what the situation requires, and to the people he is working with. He has to use his problem solving skills to adapt to the situation at hands, its inherent challenges, and its evolving nature. A researcher has to be a great communicator, able to communicate his insights on many different levels, in many different ways. And the researcher has to tailor his ways of evangelizing his data in ways that makes in more meaningful and actionable by his audience.
Ultimately, tailoring the communication of the research insights should lead to the researcher having a stronger impact. I was walking back to my office after an engaging lunch with Tracy Lovejoy (ethnographer at Microsoft), when I realized that I had been using my observation skills every day to understand the product team around me, their process, and their desires, their frustrations, and the gap in their understanding of the user. It dawned on me that a user experience researcher can use his critical skills not only for the sake of gathering insight, but also as a way to understand the audience of his insights to tailor their communication. On top of allowing the researcher to better communicate, these observations allow for an interesting shift in the perception of the product team from people you need to convince to people you are working for, that you are trying to empower. Through these observations, you can be more efficient at your job by also identifying collaboration opportunities and uncovering how and when UX can make a difference.
In short, you can consider your product team the same way you consider your user, and use similar techniques for understanding them, and to push those insights into implication for designs and collaborations.
So, if the goal of a user researcher is to impact the way the product is shaped to better reflect the users' needs, desires, attitudes and behaviors, you have to tailor the your research output to maximize impact. Once you know better how your product team works, and the individuals that compose it, their work styles and attitudes, the kind of knowledge that they respond to, what better way to maximize impact than by shortening the distance between this knowledge and its applications in the design of the product? Again, to draw a parallel with Michael Muller’s participatory design continuum, this is about making another step in the product team’s world.
When I write up my research, I often ask myself: "What would I design if I take this piece of information?" In short, I always challenge myself to construct my research output in a way that makes a clear path to design implications --it infrequently happens that sometimes the design implications appear obvious--. By being knowledgeable about design, I can imagine myself being the consumer of this information, rather than the producer. I put myself in other people's shoes, the people that will use this data. I use my skills as a user-centered designer/researcher in as many ways as possible.
To conclude, this dual approach to becoming a better researcher by applying UX skills in the interaction with the product team leads to:
As Monty told me this week: "It's as much about who you are designing with as it is about who you are designing for."
(*) While they tend to call them customers, I find myself more at peace calling them users.
I always try to help the product team understand their customer well enough such that the design implications fall out of the understanding, rather than making them very direct. I'm not an expert in building compilers, developer tools etc, but I am an expert in observing how developers use compilers and developer tools. The product team are the experts in building compilers etc, and it's important for me to acknowledge that. I use my observations to reach deep insights about the experiences that developers are having, then I share those insights with the team. We then both try to figure out what is the best way to design an experience that takes those insights into account. There really is no way that I alone could come up with the best design since I don't design and build compilers. I might know how compilers work, but that is different to designing and building one.
I totally agree with you, Steven (even though in my case, my design and technical skills are often enough to get involved in this design conversation). However, the shape the communication of your research insights can be improved by knowing how someone who would have to use them could receive them.
It's not only about empathy, as you very well know, but also about creating abstract knowledge that can be reused and applied, simplifying the complex.