4 years of PhD in performance management and 5 years of product management has taught me many things, one of which is how to do good UX research.To summarize, to do a good piece of research, 4 things are important:
Know the audiences and how to creates value to them
For example, as product manager, I am doing a piece of research on open-source chat bot platforms for the management team to make decision on which to integrate and for development team to design system architecture around it.
Funny enough, although the questions these 2 teams wants to find out are to certain extent the same: cost and benefits, the information needed to make meaningful judgement are dramatically different. Moreover, each will find what the other team want to be non-sense.
Management wants to know the financials, if additional resources are needed and if needed, where do they come from, any risks;
Development wants to see the documentation, technical support, does it work with the current architecture;
Thus as product manager, I will be addressing all the research requirements:
I need to understand the functional requirement, why do we I thus have to compare the function provided which the short and long-term needs; if it supports videos, if it has chinese libraries already available to use; if it supports customized UI and what can be customized; if it provides 24*7 technical support; if it be deployed on premise or on cloud; and if it works in China; I shortlist the candidates based on the requirements.
I need to do the math based on the current and projected number of interactions; i also look at the libraries provided and analyze if additional cost needs to be spent on buying special libraries; if the current system monitoring tools are adequate;
I need to read though the documentation and compare with our service structure to see how much the integration change our existing flow, if any new API needs to be developed.
I found it useful to have a 5 minutes discussion with the audience to align the objectives of my research as early as possible; I take this chance to find out what needs to be answered and echo back my interpretation of what they’re asking for or what they’re trying to accomplish. I may also ask for the format of result presentation and if possible, get some reference later, many people are obsessed with format, especially executives.
After all, rework is expensive.
Provide "Ready-to-bake" Insights:
In the early days, I used to view it as my responsibility to make specific recommendations from my research, but I quickly found what really matters is that insights effectively lead to clear potential solutions.
And the solution comes from the audiences.
In other words, present the problem in a way that clearly lends itself to a specific solution and let the team connect the final dots so that they consider it their idea and take ownership over it. People are more likely to follow-through on something when it is their idea and everyone implicitly ascribes ownership of the idea to them.
One way to do this is to frame key research insights as questions to spur discussion. Doing so can effectively portray the researcher as a facilitator of collaboration rather than someone who provides heavy-handed mandates for the team.For example, suppose my focus group users found it difficult to navigate the category filters. Instead of recommending that the team “Use the full page instead of drop-down menu,” I instead ask “How can we make it clear to users what level s/he is on and if there is any sub-categories under?
Everything That is Not Part of the Solution Must-go:
I never share every interesting finding from a study. I share enough to tell the story.
As product manager I regular meet with senior management, it is more important that those people leave the room with the key points to act upon. Once they leave the room, I may get another opportunity to convey the key points, but I’ve lost your best opportunity to make a lasting impact.
What is part of the solution is a follow-up email. I typically send an email that shares the deliverable with the immediate product team as well as with the entire product organization. This may seem like a minor, perfunctory step, but it is a very important factor in determining what happens next.
Research is Just Part of the Solution:
The research is really the beginning of the journey rather than the end. I need to make it easy for my team to track the insights and take action to address them. There is no best tools for that, just use the one everybody use and make sure you use it in the way everybody is using.
Sometimes the insights needs a lot of work to make its way into impact. Depending on the specific needs, plan how and when the insights will be utilized. Re-framing may be needed to open up new audiences for my insights.
Not everybody needs your research through, because either the problem is not relevant to them or the solution does not change what they do. For example, I do not involve customer service team in my payment gateway research, it makes no difference to their work flows either I choose Global Payment or First Data Merchant Solution or something else.
Turning research insights into positive action is a combination of what I do and what I am able to empower others to do. Technology and organization constantly change, we are researching and transforming all the time, so it is important we:
Comments
Post a Comment