UX Research and Collaborations: Maximizing UX Skills

UX Research and Collaborations: Maximizing UX Skills

  • Comments 2

Great research does not matter if nobody reads it

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 [3]. 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.

Observation skills come in handy

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.

Being Knowledgeable About Design Cannot Hurt

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:

  • A better understanding of your collaborators and their needs, difficulties, goals, and attitudes.
  • A communication of insights that is more tailored to its audience, and provides directions or highlight challenges for the design process.

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.

  1. Michael J. Muller and Sarah Kuhn. Participatory design. Communications of the ACM, 36(6):24–28, 1993.
  2. Michael J. Muller, Daniel M. Wildman, and Ellen A. White. Participatory design through games and other group exercises. In Proceedings of the 1994 ACM SIGCHI Conference on Human Factors in Computer Systems, pages 411–412, Boston, MA, USA, 1994. ACM. ISBN 0-89791-651-4.
  3. Yann Riche. Designing Communication Appliances to Support Aging in Place, 2008, Ph.D. thesis Université Paris Sud, France.
  • 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.

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post