Why do you want to enter UXR?
Regardless of your age, background, and other factors, when you consider entering the UXR world, this is the first question I wish you have an answer to.
Some people told me that they want to be a UXR because they find it interesting talking to people. Some consider switching to UXR after taking a UX bootcamp. Some feel that UXR is a role enabling them to help people. Some feel the academic research cycle is too long hence they want to move into the industry. Some are not satisfied with their current job, assuming UXR will be more suitable for them.
These are all valid.
However, I suggest you know what UXR is about and identify what you like & dislike at work before entering the UXR world (actually before you move to any other world!).
I’ll discuss the first part in this article. For the second part, you can refer to another article
So, what is UXR about?
UXR is here to help the team know the users and solve the right problem in the right way.
To help the TEAM,
The UXR needs to understand the team first. How does the team make decisions? What is most needed information to the team based on current project status? What might be the best way to share the research findings? Do we need an efficient checklist when building new features? Do we need to plan an immersive trip for the team to experience the environment themselves? Or maybe videos and images will help the team empathize with the users. What works for the team is what works the best.
To KNOW THE USERS,
The UXR needs to be familiar with different methodologies, be able to identify the user groups or proxy user groups, and plan the research operation properly, etc.
Solve the RIGHT PROBLEM in the RIGHT WAY,
A lot of time the product team built features that didn’t really solve a problem for the users. In an even worse case, new features might bring new issues to the users. Proving something 100% right is very hard but assuming something is right and trying to find all the elements that are against the assumption is relatively doable. This is the mindset the product team should hold:
- Learning from HOW users have been solving the problems. Try to understand WHY these problems are critical to them? WHY did they choose this solution, not others?
- If the team is planning a feature to help the users solve a problem the users are facing, do users interact with the feature as the team assumes? Do the users encounter any challenges interacting with the feature?
- Sometimes the innovation comes from Business or Technology angles. For example, the company acquires or partners with another organization, which enables new business opportunities. Or technology enhancement leads to unprecedented services. In these cases, it is much easier to design an experience that users can understand than require users to learn new technology or adapt to new ways of solving a problem.
UXR doesn’t naturally become an expert of knowing the users, but by doing user research, interacting with users, observing in the real field, reading more secondary reports, etc. UXR doesn’t represent the picky users complaining about the product but to bring the honest feedback from the predefined target user groups. Let the team understand what would happen if we roll out the feature in the way it is, potentially providing a few suggestions and urge the team to iterate the feature based on the findings.
In some cases we just can’t change the features by the research findings due to limitations or constraints. The question is Why & How. Why can’t we change the feature based on the feedback? And How will we deal with the findings? Should we put that into the backlog? Or should we tackle the issues next quarter?
A product team needs to consider lots of factors along the product development process, e.g. resources required, timeline planning, sustainable business model, revenue generated, technical feasibility, regulation & policy, and user experience. User experience is one of the factors (hopefully), but not the ONLY factor. UXR’s job is to bring users’ feedback to the team but the following decisions should be made by the team, as a team.
One more thing. You don’t need to be a UXR to care about users (or people). As long as the team is building a product for humans to use and want to be used properly, someone from the team needs to understand how the users might interact with the product. If there’s someone from the team dedicated to this mission, this person is likely to be the user researcher. But if there’s no UXR in the team, someone else, whether the product manager, designer, other role, even everyone, needs to step up and understand the users. UXR isn’t here to stop everyone from interacting with the users, but to accelerate and optimize the process of understanding the users. Ideally everyone should not need permission to understand more about the users the team is building the product for. Vice versa, UXR can learn other skills as well. Mutual understanding helps the team build common ground. The greater the common ground is, the more efficient the team will function. Don’t limit yourself by your title.
XFN counterparts
Some of the cross-functional (XFN) counterparts that potentially work together with UXR at different points of the product development process.
Market research
Market research aims to understand specific market(s) and figure out “what people WANT”. For example, these are some of the questions for market research:
“How many people in southeast Asia are holding at least one credit card?”
“Statistically what are the top reasons for people in the region to adopt credit cards?”
“Which demographic groups are more likely to adopt credit card payment?”
“What will be the best channels and packages to induce the target groups?”
Data analysis
Data analysis tries to calculate ROI (Return on Investment) and/or project potential business impact based on predefined metrics tracked from the product/service. If the data is properly tracked, the team will be able to answer questions like:
“How many unrepeated visitors visit our website everyday?”
“What are the top 3 tasks our visitors tried to complete from our mobile website and app respectively?”
“How many orders expired after the users added the goods into their cart? Which potentially cuts how much of our revenue?”
Customer service
Customer service (CS) is usually connected when the users need help to solve unexpected issues that surprise them or stop them from completing their task. For example:
“The food I ordered didn’t arrive but the booking was marked as completed.”
“There is an unexpected amount deducted from my account which I don’t know what that is about.”
“I want to cancel the ticket I booked, but I don’t know how.”
“Why is the promo code not working?”
You can imagine that CS needs to manage users’ reactions. Waiting for food for an hour and not being able to get it eventually can be frustrating and upsetting. CS also helps the users solve the problems they are facing, most of the time ASAP.
In some companies, Market Research, Data Analysis, Product Research (or UXR), and Customer Service are grouped as the Consumer Insight Team. These are teams who try to understand the facts from different angles to help the broader team make the best possible decisions.
Product manager
Ideally, a Product Manager (PM) is the soul of the product team. The PM takes actions that ensure the product will succeed, usually including aligning business goals with the leadership, allocating resources, jotting down product strategy, setting up ultimate goal, scoping the work in a specific period of time, breaking down the path to achieve the goal into stages, reaching out to respective roles for specific requirements, etc. The PM may reach out to data analytics for product metrics to make better judgements. Or reach out to UX Designer or UXR and plan a workshop to form the consensus in the team, even have the leaders included. However, PM works differently depending on types of product, company cultures & scales, level of maturity of the product & the team, etc.
UX Designer
UX Designers (UXD) usually work closely with UXR. UXD designs the solution to solve the problems users are facing, while considering business requirements and technical feasibility. In this process of creating the solution, UXD makes assumptions to be evaluated by UXR collecting the reactions from the users. Hence UXR and UXD need to work together to align the scenarios to be simulated and the findings we plan to collect from the research. In a product core team, UXD and UXR are usually the roles advocate for the users and try to tackle the challenges from a people perspective.
Engineer
Engineer is the one writing codes to realize all the decisions, considerations and ideas into a workable digital website/application. They are usually the most valuable resources in a technology company. Because of their work, the product can start serving the users and generating business values. They usually play the role of assessing feasibility, stability, scalability, complexity, and efficiency in product discussions.
Project manager
In some situations, e.g. complex project or project that requires lots xfn cooperation, a project manager (PJM) might be involved. A PJM aims to make reasonable planning and make sure all the planned tasks will happen on time with expected results.
Operation team
Operation team (Ops) usually interact with customers or users directly. For example, Ops team helps the users to go through the KYC (Know Your Customer) process before the investment account is set, makes sure the guest will be connected by the local guide on time, etc. As UXR needs to learn and potentially recruit specific user groups, the Ops team usually can provide relevant inputs.
Why do we need a UXR
Product development cycle is getting shorter
A few decades ago, when people talked about “product”, what they meant was products like chairs, tables, television (not smart yet), etc. Back then if a consumer brought back a table then found it not built at the right height at a later time, the consumer is likely to keep the table for at least a few years. It was just too much effort to find a replacement, sell the table to someone and buy another new table.
That’s not the case anymore today, especially for digital services/products.
Today when someone downloads an app from any platform, if the user can’t figure out how this app can be helpful in the first five minutes, the user is likely to switch back to the app store and find another alternative to serve them better. The user now has massive options to select. The cost of finding another option and switching to another service has reduced drastically. Every service/product has less than five minutes to win the users’ heart.
Hence providing a smooth onboarding experience, gilding the users to explore the app, supporting users whenever they need, engaging the users at different stages, rewarding the users when they take suitable actions, and encouraging loyal users to advocate for your product, all the above become the small bricks paving the path to a successful business.
Since the first iPhone was announced in 2007, just in 15 years the definition of product life cycle has evolved from a few years to a few months, especially for digital products. The product team can always optimize the product to serve the users more efficiently, with lower cost, with prettier appearance, bigger or smaller fonts. But not all the solutions are good answers to the problems users are facing. Users are the experts in solving the critical problems they’re facing. Able to discover the opportunities from the real scenarios and to identify the potential risks as early as possible, helps the firm generate long term value. UXR plays a critical role to accelerate this process, unprecedentedly. The earlier we can identify the risk, the less it will cost to the company.
Why is it challenging to be a UXR
Uncertainty makes people uncomfortable
If we look at the three circles in the design-thinking paradigm, the “Technology” circle is usually handled by engineers who are trained in Computer Science or related backgrounds. The “Business” circle is usually handled by people trained by MBA or related backgrounds. Experts from these two areas answer questions with relatively certain answers, e.g. the program can or can’t work, the revenue projection of next quarter is lower or higher based on existing conditions, etc.
Compared to these two circles, the “People” circle brings uncertainty and ambiguity to the team, which makes people from the other circles really uncomfortable. They used to be quite confident with the facts from the circle that they’re familiar with. Now they need to deal with human diversity, as we discover more findings from real and diverse users.
“What do you mean that users thought the app stopped when it’s loading the page? That is a big table the app is loading. It’s working just taking a longer time.”
“Yes, logically it is working. But how would the users possibly know?”
The more we empathize with users as a team, the more comfortable we’ll be. Then the team would realize that there’s a gap between the team and the users. We need to form hypotheses and test our assumptions to serve the users’ needs better.
Not everyone understands the value of the UXR
Another challenge UXR may face is that UXR is a relatively young profession compared to market research or many other specialties. The time when some C-level leaders were trained in schools, UXR wasn’t born yet. UXR doesn’t seem as convincing as behavior analysis or business analysis, which is backed by data, lots of time with the significant stars on the report.
As mentioned above, for the business of chairs and tables, UXR’s value might not leverage as much as the digital era today. Data is critical in the digital product era. But it doesn’t need to be an “either or” situation. Data tells what’s happening now but doesn’t explain why this is happening. That’s where UXR can step in and figure it out. These two teams should be partners for each other, not enemies.
It’s even worse because the value of doing UXR is HARD to prove
If we make a decision based on findings from UXR, we almost can’t prove how impactful this decision is, because the alternative is never implemented. That means compared to designers to show off their amazing design work, PMs to demonstrate the development progress and business revenue generated, data analyst to explain the result from an A/B testing, it might be slightly more challenging for the UXR to justify its value.
The best way to show UXR’s value is not by proving it but by applying it. As the famous quote says, “If you think good design is expensive, think about the cost of bad design.” Same quote applies to UXR too. In this fast paced era, do we not need to know more about users?
I personally just think that’s the right thing to do to build more meaningful products and eliminate useless features. It’s easier to build new things, harder to build the RIGHT things.
Learnings form 50+ mentorship practice in 2022
In the year of 2022 I took time talking to people who are interested in topics around Product, Design, Research, Career, Asia, etc. After 50+ conversations, I want to write down what I learned from these conversations.
