How to Create Buy-In for User Research
Based on my experience being the team’s first user researcher at Lenovo AI Lab
Gaining an explicit understanding of the users, tasks and environments through user research is the foundation of a project in User-Centered Design. Without user research, the proposed design will likely be struggling to capture and address the whole user experience. While this is common-sense for HCI practitioners, not every team in the IT industry has come to this realization.
Many acquaintances have complained to me about how under-valued and how little buy-in there is for user research in their teams. In this article, I’d like to give my take on how to create buy-in for user research based on my experience as the first UXer at the Machine learning team of Lenovo AI lab.
My Experience as the first UXer in the team
Last summer, I interned as UX researcher/designer at the machine learning team of Lenovo AI lab by coincidence(It will be another story why I had to give up my UX internship with Cengage). Unfortunately, I was the first UXer ever on the team.
It is not ideal to be an intern without a mentor. What can make it worse is when the team is averse to user research - The team’s lead front-end developer claimed in a team meeting that SAAS products don't need user research. My only ally was the product manager, who had an intuition that user research was essential to improve the team’s product, but failed to convince the team to perform any user research activity.
Finding myself in a tough situation, I was determined to make the best of it by bringing my skills to the table and creating buy-in for user research at the appropriate time, when it would benefit the team and at the same time give me opportunity to practice. As a result of my effort, the team adopted user experience as its long-term strategy and hired their first full-time UXer once I had finished the internship.
Here is my take on how to create buy-in for user research based on this experience.
Ask Valuable Questions
User research is all about collecting evidence about the user so that product managers can draw up informed strategies and designers can create a well-informed design. The methodology of gathering evidence to make an informed decision is nothing new. Software developers need to review product design to determine its technical feasibility and the time it will take for development. Machine learning engineers need to explore the pattern of the dataset to discover the best-fit model.What feels intangible for team members averse to user research is what exactly we need to learn about the user.
As a user researcher, it is your responsibility to come up with valuable questions that matter to the project. Once these questions about the user are pointed out, their importance is usually self-evident, and the motivation for user research is created.
In my case, our team wanted to build a promotional website to persuade supply chain managers to collaborate and create customized machine learning embedded products. In our first meeting, after revealing the project’s goal, the product owner asked me to draw up our initial ideas on the whiteboard. I was quite shocked. I could create a design by following the general guidelines, but it most likely wouldn’t be effective. The design should address the specific needs and pain points of our user. Before starting to design, I proposed that we begin the project by answering the following questions:
- Why do our users need machine learning?
- What do our users think of machine learning?
- What’s the rationale behind their decision to collaborate with our team?
It is quite apparent that these questions about our users are essential to the success of the project, but we didn’t have any clear answers to them. So I suggested a user research project to answer these questions. They agreed immediately.
Nail A Project of Small Scale
Now that the team has realized the need to collect evidence for the project, it is time to initiate a user research project.
Even though you have suggested user research is the cure, colleagues and clients might still feel uncertain about user research. After all, ‘user research’ may still be little more than terminology to them. It is understandable that they might doubt its efficacy. It is best to initiate a small-scale project so the team will be more likely to approve it and you can use this chance to prove the value of user research.
In terms of research methods, a survey is usually low-cost, but it will elicit only limited actionable insight and lack in-depth data. Interviews will return better results. With 5 or 6 interview sessions, everything should run pretty quickly and give you some profound findings to impress your team.
When presenting the research findings, quickly go through what the team already knows so you can focus on explaining what the team doesn’t know. At the same time, include quotes and tell stories to make the presentation more convincing and memorable.
Involve the Team In the Process
As I said above, ‘user research’ may be nothing more than a catchphrase for your teammates. Even if you have approved its efficacy, user research is still a mysterious black box for them. One thing I found valuable is to involve your teammates in the process of user research. For instance, you could bring the PM to an interview session, have a group data interpretation meeting, or create an empathy map with the whole team after sharing your research findings. These activities will demystify user research for your teammates and improve everyone’s shared understanding of the user. Potentially, they will have a better understanding of the complexity of user research and have greater appreciation for your work.
Spread User Research Basics
A product cannot be built without understanding the user need. When there is no user researcher in the team, the responsibility for discovering user needs falls on product managers, designers, or even developers. The truth is that the team will have been doing user research, with or without a user researcher, but it will have been mostly flawed user research.
In my case, our team’s machine learning engineers used to work like this: They would ask, via a casual conversation, a single supply chain planner what features he or she wanted, and build algorithms completely based on his or her request. From a user researcher’s perspective, this workflow is problematic and doomed to failure.
Once you join the team, it is crucial to understand the existing workflow, identify what is not working, and initiate a new workflow so that user research is conducted correctly and accurate information is provided so that the team can make informed decisions.
However, it is unlikely you personally will cover all the user research from now on, so spreading the basics of user research to your teammates can be very helpful in giving them the skillset and understanding to collect meaningful information about the user themselves. One way to spread the knowledge is to use your team as an example and point out what isn’t working in the team. In my situation, I was able to point out three pitfalls the team could have avoided:
- Firstly, never ask users what they want. Users don’t know what they want and by asking them, you risk limiting the scope of your ideas to the imagination of others. Instead, observe, build trust and have meaningful conversations with users to discover their real and unspoken user needs.
- Secondly, don’t interview only one user and design for one user. I understand supply chain planners could share a similar workflow, but there is no way they work and feel the same. Interview at least three users to find the emerging user need, so we are not solving problems for only one user.
- Finally, interviews might not be adequate for us because of the complexity of supply chain planning. Supply chain planners can’t uncover all the subtasks of supply chain planning and the logics behind them all by means of a simple interview. Contextual inquiry fits well in this context to thoroughly understand supply chain planners’ workflow, the context, and the reasons behind their behaviors.
My Career Pivot into PM
My responsibilities for this internship were not limited to user research or UX design. During it, I collaborated with programmers and machine learning engineers to determine their availability and the project’s technical feasibility. With this info in mind, along with evidence about the user, I worked closely with the PM to co-create strategies for two projects. I realized my passion is not limited to creating easy-to-use design or understanding the user. What makes me feel genuinely passionate and excited, is coordinating and supporting a team to build meaningful products. So I decided pivot away from UX and dive into product management.
I appreciate your taking time to read through this, and I would love to hear your opinions. Feel free to leave a comment, check out more of my work, connect with me on LinkedIn, or say a friendly hello!
