For product managers who are just getting started, it is easy for the designed product functions to fail to meet user expectations. Part of the reason for this is that the demand analysis is not done well and the essence behind the matter is ignored. So let’s take a look at how to do a good needs analysis.
Look beyond the surface
Only by looking at the essence through phenomena and understanding the real needs of users can we better provide solutions to meet user needs.
What is a phenomenon , the external form or result shown by something.
When we receive requirements, what we describe from users is often just a phenomenon, and it is superficial. Because the user's understanding of the product is biased and incomplete compared to ours, the demands put forward are mostly just from the perspective of what they know. If you start designing product functions based only on appearance, the final result is likely to not meet expectations or it will be difficult to do better.
For example, the user's demand is "need a faster horse". From the superficial appearance, in order to meet the user's needs, we need to find a horse and a faster horse.
What is essence , the inherent attributes of things that have an impact on the nature, characteristics, occurrence and development of things. When we analyze the phenomenon and further understand the nature of the transaction, we may be able to surprise users beyond expectations when we deal with the problem. For example, if the user's request is "need a faster horse", and we further understand that the user's purpose is to get from point A to point B faster, then the focus may not have anything to do with the horse.
So how do we quickly see through the phenomenon to see the essence and do a good job in demand analysis? We can explore the real purpose or motivation behind user needs from several factors: user role, scenario, user behavior and purpose.
User Role (Who? What?)
A role can be an individual user, a certain type of user group, or an organizational group, that is, the user's identity and role.
Let’s continue to combine the above examples to diverge. We need to get from point A to point B faster. Is providing a car really the best solution? Not necessarily. When we expand our service targets to different user groups, we may end up with multiple solutions for different user groups. What needs to be noted here is whether the role we are facing is a user group, or an individual or individual in the role, which will determine whether we get general needs or personalized needs.
for example:
For user groups who are more concerned about cost and "need to get from point A to point B faster", a more desirable solution may be to call a taxi (such as tourists from outside the city).
For user groups who "need to get from point A to point B faster" who don't care about cost but care about comfort, the most needed solution may be a car (such as business leaders).
From this we can see that what kind of solution we come up with has a lot to do with different user groups, so we need to determine what kind of user group, that is, the role we are facing.
The scene (what conditions and environment?)
The scene includes the specific time and place, that is, the user's environment and conditions. After we determine the user role, it is not enough. Relevant factors in the user's scenario may still affect whether the solution we provide is perfect.
Continuing with the above example:
For “the need to get from point A to point B faster”, we identified the user role as business leaders.
In view of urban traffic congestion, the more necessary solution may be to take a helicopter.
For situations where you need to travel far away from the province, a more necessary solution may be an air ticket.
Different scenario factors determine the rules and prerequisites for our actions, so we need to understand the scenarios related to user needs and the constraints that appear in different scenarios.
Behavior and Purpose (What to do? Why to do it?)
Behavior and purpose, the behavioral subject relies on the intermediary role of consciousness and concepts to pre-imagine behavioral goals and results according to its own needs. Is the solution we provide based on different user groups/roles and corresponding scenarios the best solution? Still not necessarily, we still need to figure out the user's behavior and purpose. Behavior is the actions performed by users to achieve their goals. It is the entry point for us to explore motivations or purposes.
Continuing with the above example:
We identified the user role as a business leader in a scenario of urban traffic congestion.
For those who need to get from point A to point B faster for the purpose of participating in a meeting, the most needed solution may be remote video conferencing.
Regarding the need to get from point A to point B faster, the purpose is to pick up the son who is about to get out of school, then the more necessary solution may be to call his wife and ask her to help pick him up.
At this point, in addition to determining the user role and understanding the scenario, we also need to figure out user behavior and the motivations behind the behavior.
Doesn’t it become easier to see the essence of things after we have mastered the characters, scenes, actions and purposes?
case analysis
For example: user demand "I need to buy an electric drill", we substitute this demand into our formula.
Role : Who Needs to Buy a Power Drill - The Househusband
Purpose of behavior : What to buy an electric drill for, why buy an electric drill - buy an electric drill, drill holes and install hooks to hang clothes
Scene : Under what circumstances and conditions - in a study, on a smooth wall
So the final real need is to help the house husband solve the problem of hanging clothes in the study. In addition to providing electric drills, perhaps a simpler and more effective solution would be to provide hooks with suction cups. Users who want to buy an electric drill are probably just unaware of the existence of suction cup hooks.
Let’s give another example that I encountered in product work:
The user demand is "I need to delete historical data." The final result obtained through understanding and analysis is: a certain enterprise needs to delete background historical data regularly to prevent sensitive data from being leaked by employees. Then the real need of users is to prevent sensitive data from being leaked by employees, not to delete historical data. The solution we provide is to hide sensitive information in historical data and only display it for specified permissions.
Requirements analysis is a process that requires seeing the essence of things through phenomena. During this period, we need to determine the user roles we are oriented to, the scenarios in which users are located, the behaviors displayed, and the purposes and motivations behind them. Finally, we combine various factors to obtain Come up with better solutions