True Partnership with UX Research

Recently I was approached on WeChat by a user experience (UX) researcher with a very intriguing topic. “How would you communicate with product managers when you have valuable user findings? How can you carry out the values of your research via the products they will build?”

I hopped on a WeChat call with her and we talked for about one hour. After listening to her situation, I talked about my “True Partnership” principle and several tips. Now happy to share them broadly upon her suggestion.

The Situation

She works in a centralized design studio at a large multinational company, partnering with more than a dozen of product managers and other cross-functional partners.

Some partners work with her on the same site, others work remotely in other cities including international offices.

Her current partnership is mostly based on a project. However people are moving around in the company and projects are going on and off both due to good and bad reasons. Therefore she may work with the same stakeholders again and again.

I knew her for decades and knew she is a top-notch world-class researcher. I have no doubt of her research quality or the values of her findings.

I believe this situation is pretty common for UX researchers in any global or multinational companies. I very often encountered similar situations when I mentored UX researchers in the Silicon Valley. Upon her suggestion, I would like to write up this article about the “True Partnership” in UX Research which I have been practicing for years.

True Partnership

In a nutshell. A true partnership makes UX Researchers totally different from a vendor, a consultant, or an agent who is strictly bounded by a specific contract, for instance in the form of a carefully calibrated statement-of-work (SOW).

As a true partner in a team, a UX researcher becomes

• someone who lives in a valued, trusted, and reciprocal relationship with their cross-functional partners on a leveled ground. Note: I used “partners” here instead of the more common “stake-holders” because the latter carries a strong annotation of authority.
• someone who adds values beyond the exact words of a “contract”. They don’t only do exactly what they’re told and nothing more. Instead, they work hard to deliver above and beyond.
• someone who is willing to say “no” and willing to fight for ideas and engage in intelligent discourse.
• someone who is willing to co-own the project, including all its entailed risks and challenges, as well as the interests and credits.

Partnership Is A Daily Job

We build and maintain relationship with others all the time, no matter formally or casually. It’s very important to constantly observe and assess your stakeholders through business meetings, design reviews, ideation jams, hallway chats, emails, and instant messages, etc.

If you’re a UX researcher, please ask yourself when working with a specific stakeholder, “Do they care about user experience or user experience research? Do they put the end users’ interests first? Have they made user friendly changes in their past?” If the answer is consistently YES for all questions, you shall congratulate yourself for finding a good partner.

You shall study your stakeholders, because in a particular sense they are your first users — who will USE your research findings to build user friendly products for your end users in the market. You know, as a researcher you have a great research tool-kit under your belt. Use it at your convenience with your discretion.

Also like a good researcher, you shall use multiple methods and run longitudinal studies to observe, track, determine and refresh to what extent a specific stakeholder, a specific function is a true partner for UX research. :)

In the main body of this article, I will list all tips that I gave to the researcher during our one hour discussion. However I’ll leave out some very specific examples, and keep the points at a moderately high level for the sake of your read time. The tips are mostly to help the in-house UX researchers, not the cross-functional stakeholders or UX research agents.

When planning a project

• The earlier the better. Very often product stakeholders err on the side of involving UX researchers too later during the product development process, also very often UX researchers err on the side of proposing foundational research projects too later. “You can use an eraser on the drafting table or a sledgehammer on the construction site.” What said by Frank Lloyd Wright is still true to both sides. Fast paced development and organizational silos didn’t help at all. As a researcher, you shall join your stakeholders’ activities to understand their situations, then proactively figure out what research can be useful, and how to make the findings actionable in the right way at the right time.
• Ask why and why now. In the event of receiving a research request, we’d better understand from the stakeholders’ view, why a research is needed to be conducted at this point. Ask about the target users, market, the value proposition, the product position, and competitive landscape to understand the large picture. Ask about the specific questions the stakeholders need to answer through a primary research, and also ask what literatures need to be reviewed and what experts need to be interviewed before jumping into a primary research. It’s also important to understand the real window of time to conduct the research.
• Ask so and so what. “So” is about what specific product changes the stakeholders need to make a decision about, and “so what” is about what business/tech/UX needles the stakeholders aim to move. For example, if the target needle is to help the restaurant owners to increase their profits by reducing losses, honestly a business analyst is in a better position to help calculate the profits and losses (P&L).
• Have stakeholders to participate. “George, I trust your research abilities so go ahead to do the study. I don’t have to be involved and actually I’m very busy with my own stuff.” It’s very common, and I always treat it as an orange flag — not immediately a red flag but it will lead to difficulties when I need to “sell the findings” to them to get an easy buy-in. I often replied with, “It’s your business that you care the most. I don’t have to care about it unless you really care about the study. If you do care, show me by joining the study which is yours from the beginning. Your choice!” Surprisingly, it often worked very well in my experience, and my stakeholders actually made time to join the study.
• Run a “Pre-mortem”. Borrowed the idea of post-mortem, I often run a pre-mortem to identify the risks and threats before conducting a research project. I would like to do it together with stakeholders so that we can collectively define backup plans (a.k.a plan Bs) just in case the first research attempt failed. Postponing the primary research to a better time also isn’t rare at all as a result of a good pre-mortem.
• Assume NO before say YES. As you can see from the aforementioned, UX researchers shouldn’t easily accept a research project which down the line will take time, resource, and of course lots of money. Research is neither free nor cheap, and you shouldn’t start a study upon stakeholder’s whims. I always let stakeholders know from the beginning they shouldn’t assume the study will happen unless we can collectively say with certain confidence“Yes!! We’re ready because we have a good plan in hand.” It’s especially useful when we face a totally new domain that full of unknowns and uncertainties.

When executing a project

• Foster empathy. It’s why we need stakeholders to attend the research activities. In their own words it may be an immersion time or customer obsession session. UX researchers shall teach them how to fuse with the environments and how to build rapport with end users, what to observe and what (NOT) to ask about, and how to collect artifacts (or data) and how to take good notes.
• Expose to the wild diversity. Most stakeholders love to act on simple data points, for example their fascination about the Net-Promoter-Score (NPS). No matter it’s a field study, a lab test, or a live experiment, once they participate in the research activity, please encourage them to see the huge differences between users, between use cases, and between measurement periods. They might be overwhelmed by the wild diversity, but it’s exactly what will benefit themselves in their decisive moments.
• Separate ideas from facts. It’s natural that our stakeholders record both the objective facts from research and the great ideas triggered by the former. During post-session debriefs, I usually provide to them this framework “We shall keep(or start, stop) doing X because of Y” where X represents the great idea they have and Y represents the facts they saw with their own ideas, heard with their own eyes, and collected with their own hands. The framework was easy to learn and worked very well.
• See the forest for the trees. Ideally research activities shall help the stakeholders break out from the business, technical and operational routines they are deeply imbedded, to see the big picture from the side of our end users. For example one of the competitive benchmarking studies at Google showed that 10+ times technical improvements actually translated into little increase in user’s task successes or speed while they conduct daily search tasks. It might be discouraging but they learned what the searchers actually need, do and feel.

When synthesizing findings

• Less is absolutely more. I have seen now and then some UX researchers prepared a deck of almost 100 slides full of discrete points to impress the stakeholders during a period from 30 to 60 minutes. It’s a pity in the end stakeholders took away so little. At synthesis stage, the discussion result of the “Why”, “Why now”, “So”, “So What” section is important again to guide the synthesis focus.
• Relevance over quantity. Stay relentlessly on the original research goals. Focus on what are the most relevant to the end users and what are most concerning about business, technology, operation and even competitors. Be refrained from adding more insights. Instead, we shall dive deep into the true causes and pathology of each critical phenomenon, in order to refine the insights to be actionable.
• Triangulate to refine findings. Compare and complement with market research insights, data science dashboards, competitive intelligence, business insights, etc. UX research provides information like all other insight teams do, therefore triangulation will facilitate stakeholders to make sound product decisions.
• Filter by business and tech needs. Now it’s time to inspect the insights via business and technical lenses, to see if it’s business wise viable and tech wise feasible to invest. Also specifically discuss about “if not now, when?” As a result, short term and long term plans can be created at this stage.
• Run ideation workshops together. Pivot to the short term actionable user insights, the UX Researcher and stakeholders shall organize an ideation workshop using methods like the “How might we” or “Job to be done”, inviting all functions that will be involved in the building process such as designers, back-end engineers, developers, product marketing managers, etc.

Follow Up and Check

Delivering the report and completing the ideation workshop are just the beginning of a continued journey to make sure the “So” and “So what” exactly answer the “Why” and “Why now”. Unfortunately very often UX researchers drop out due to good or bad reasons. For example, sometimes a researcher moved to other teams or left the company when they have been waiting for a while but couldn’t see actual impact.

• Let researchers speak about research work. Any research insight is just a piece of information that can be easily misinterpreted. It’s the researcher’s job to interpret it and prevent misinterpretations. Stay in the loop as long as you can to present the insights. My own experience is that 20 times speaking of the same insight in the same language results in a feature in the production. That’s why I remembered my research insights and impact so well even after more than 15 years.
• Follow up on the actions. Two weeks after the ideation workshop, I usually follow up with stakeholders about what exactly they plan to do. Based on that, I discuss about what the research could have been done differently.
• Follow up on the real impact. Ninety days, or 3 months, after the ideation workshop, I follow up again to see what business, technology, or user experience needles have actually moved in the external production. Then double check with the stakeholders what could have been done differently on research side as well as on their sides.

Constantly Reflecting on True Partnership.

“We do not learn from experience … we learn from reflecting on experience.” well said by educational reformer John Dewey.

Similarly, we as UX researchers shall constantly reflect about the true partnership with each stakeholder on every collaborative research project. Constantly question what we can do better as UX researchers, and what they can do better next time.

Lastly like any relationship, it’s okay to pause or cease the partnership with a specific stakeholder if things didn’t work out. Nothing personal. Believe me, many non-partners of mine are still good friends in my life. :-)

Truly lastly, all the above are my personal opinions out of my reflections on my own experience. Your claps, critiques, and comments are welcome!!!