Welcome to the large-scale emotional topic: How to conduct effective demand analysis - business scenarios! Perhaps we can’t be familiar with the word scene. In the entire product implementation process, it is so silly. The scene is very specific because it exists objectively, and we can capture it with the naked eye; but the scene seems very abstract, and we have to worry about what the scene is and what is the connection between the scene and the function every day. Today, let’s explore the mystery of the scene together!
Content Review
In the previous issue, we talked about the relevant knowledge of business processes. According to conventions, let’s first review: the reasons for the division of labor in
- : scale, risk, and professionalism; the three management elements of
- business process: audit, rules, and exceptions; the five basic elements of
- business process: division of labor, activities, collaboration, product relationships, and branches; the starting point of
- business process is the external service request; the end point of the business process is to meet service requests; the optimization strategy of
- business process: "ESIA Analysis Method".
business process and business scenarios are interlocking and progressive. Before starting the topic of this article, I would like to give you two sentences:
- business process refers to the process of meeting external service requests through collaboration between different positions; while business scenarios are relatively independent and reportable business activities mainly completed by a certain position;
- management users pay attention to the logic of things to things, and the core of their focus is the business process; while operation users pay more attention to the logic of people to things, and the core of their focus is the business scenario.
Word of Thinking
All changes in behaviors stem from changes in thinking styles. I made these two sentences into a picture alone, which is also to attract everyone's attention.
In the first article in our demand analysis series, we discussed two different ways of thinking: "product thinking" and "technical thinking". The two sentences in the above figure are the further reflection of the two ways of thinking at this stage of the user scenario. The red arrow in the picture
is a gap that many people cannot cross. In most cases, we are "in the name of demand analysis, perform the reality of functional decomposition!" (People who are taking the exam, please raise your hands~) The change in
thinking mode is really difficult. This not only requires our unwavering belief, but also requires our practice of hard work.
Purpose significance
Let’s first talk about what the purpose and significance of our research business scenarios are? You may say that the research on business scenarios is definitely for further demand analysis. Yes, this is indeed the meaning of the purpose, but this description is too general, and the business scenario can bring more than that.
The media for value transfer
I once mentioned the related content of value-driven and task-driven in my full-time report. I think we should clarify the purpose and significance of anything we do, rather than simply carrying out work to complete the tasks assigned by our superiors.
. This kind of thing needs, after layer-by-layer transmission, the only function that is finally received may be left. So, we may often hear this voice: "Why did this requirement be so fixed at the beginning?" "I don't know, this is how the product manager is." And as time goes by, the product manager may forget why he had to make this requirement.
This will cause the team to lack stamina, and it is very painful when a person does not know what the meaning of what he is doing. Business scenarios perfectly act as a medium for value transmission, bringing self-motivation to the entire team.
Benchmarks for communication and communication
There are many students' needs review meetings, and they finally became product manager complaint meetings. Those development and pre-sales development and pre-sales, with the "original intention" of making the product better, are getting further and further on the road of complaints and unable to extricate themselves. After all, the opportunity to piss off the product is an opportunity that cannot be missed.
The face of the angel, the heart of the devil, a lot of problems are like wild horses running wildly! "You see how good the function of a certain product is, why don't we add it?", "We have competitors, and what are the advantages of doing these functions?", "A small function, you have such complexity, have you considered the development cost?"...
Even if you have a good tongue, it is difficult to resist the eloquence of everyone at this time, because they are all asking questions with divergent thinking. Since the moves are invisible, you cannot effectively defend and counterattack. Finally, I was physically and mentally exhausted and had no choice but to say: "That's what the boss/customer requires!" Then, with the mentality of ten thousand grass-rooted horses galloping by, the meeting ended. And they all cast questioning and contemptuous eyes: "So these are your YY needs!"
So how can they "get lost"? In fact, it is also very simple. All communication must have a benchmark, otherwise it will turn into endless debates. The benchmark for demand communication is business scenarios. We only communicate from one dimension: As a user role, I want to complete the activity to facilitate the value of .
presentation form
Since the business scenario is so important, how can we present it? There are two most classic forms of presentation of business scenarios, one is user stories, and the other is use case diagram .
User Story
In fact, we have already come into contact with user stories : As a user role, I want to complete the activity to facilitate the realization of the value . This is the classic descriptive format of user stories.
User story three elements:
. Who: Who wants to use this; . Activity: What activities to complete;
. Value: Why do you need to do this and what value can you bring.User Story 3C Principle:
- Card (Card): User Story is generally written on small notes cards. A short description of the story, workload estimates, etc. may be written on the card;
- Conversation: The details behind the user's story come from communication with the customer or product manager.
- Confirmation: Pass the acceptance test to confirm that the user story is completed correctly. These abstract theories of
have been introduced. Let’s take a look at how to record this user story:
We can see that the user story card contains three types of information:
- story title;
- story description;
- rule description: In order to complete the story, sometimes it is necessary to formulate the implementation rules of the story, the definition of the noun involved, etc. The rule description is initially formulated by the product manager and revised and confirmed after the story is discussed. The writing method is listed in exhaustively.
use case diagram
I wonder if any classmate has drawn such use case diagram:
Well, I'm fine, I'm sure I drew this way before anyway~
Range, this is a very typical pseudo-use case for naming technical verbs + business nouns!
What can we see from the use case diagram?
's function of adding, deleting, modifying and checking has nothing to do with the scene. And what's the point of drawing a picture if you can tell a word?...
Let's take a look at another use case picture:
What do you see this time? Is it possible to see the user scenario in this way? Actually, is this difficult? The answer is not difficult at all. The two pictures correspond to each other, and the same expression is still adding, deleting, modifying and searching. This is back to what we said at the beginning. The most important thing is the change in our thinking style!
The method of drawing use case diagrams is very mature. I won’t go into details here. If you are interested, you can check the information yourself.
Scenario Analysis
In the paragraph of purpose meaning, we mentioned that the purpose of the research scenario is to further require analysis.So let’s take a look at how to analyze the scenario?
Analysis method: Scenario-challenge-scheme three-step method
- Step 1, Scenario refinement: Refine the scene into an event stream, first sort out the normal steps expected by the user, and then write down the changes;
- Step 2, Problem/Challenge Identification: For each step, think about what problems they will encounter and what challenges they face from the user's perspective;
- Step 3, Think about the response plan: For these problems, think about what solutions the system should provide.
Don't worry, don't worry, do you think these bold knowledge points are too dry? Let's give a case to moisten the throat:
travel is definitely something you have experienced. So if we were asked to analyze the needs of an online travel service website, what should we do? Let’s take the “itation plan” scenario as an example and analyze it together.
Step 1
refines the scene into an event stream. This is easy to list based on everyone's own experience. I will give the answer directly here:
Then, let's write down the changes. Let’s analyze whether there may be changes in the second step? For example, if there is not enough time to arrange this, or if there is not enough money... Then we also record these two possible changes:
Step 2
Let’s think about what problems or challenges users will encounter throughout the process.
determines the Jingshi Entertainment Shopping Spot you plan to go to. Think about your travel experience. The biggest question here is whether you have been struggling with where to go? When you come back from a trip, if you ask if you have gone to a certain place, if you say no, others say that you have gone to the vain for your trip. What a depressing thing that will be.
determines the order of order and the time it is expected to take. The biggest difficulty is not to know the distance between these points of interest, how to transfer to transportation, and how long it takes for each point of interest.
Similarly, when preparing the corresponding luggage, are we also worried about what kind of luggage we should bring? Do you need sunscreen, do you wear sportswear, or casual clothes, do you need insect-proof agents, etc.
We also record all these in the table:
Step 3
Let’s take a look at what solutions should be provided for these problems.
What do we design to be similar to a shopping cart if we don’t know what are the problems and are afraid of missing this kind of problem? Then add the recommendation functions such as "Top Ten Suggestions", "Classification View", and "Tourists Must Go" to enhance the experience;
For problems of not knowing the distance, play time and transportation, we display all the points of interest on the map, and then mark the time of each attraction, the recommended path, traffic suggestions between two points, and the estimated time, and at the same time count the total time and total money. Is it possible to solve the problem?
for which luggage should be brought better. We give a list of essential items, weather conditions, precautions, etc., which are enough for users to determine what luggage to bring;
for changes in the absence of time and insufficient money, we directly eliminate a certain attraction on the map, and the system will automatically recalculate the total time and total money spent, which is OK.
Finally, for the scenario analysis, we will come up with a table like this:
, and a complete scenario analysis ends here. Can we explore the technical feasibility next?
Let me say one more thing. The above analysis content is the summary content given by me from the perspective of "prophet". During the analysis process, everyone will definitely encounter many difficulties and there are also a lot of extra work to do, such as business understanding, competitive product analysis, etc. The most important thing here is this way of thinking.
Easter egg
What users feel when listening to you
Football commentary is generally like this:
"A player received the ball, and had a way to sink to the bottom, a cross from the bottom, and a breakthrough in the middle, and the ball went in!"
And when the user listened to you, he seemed to be listening to such a football commentary:
"A player received the ball and passed the ball to 7 meters at the top 45° angle to himself, and the other player received the ball and passed the ball to 3 meters at the top 30° angle to his upper right. At this time, the player who followed pushed 1 meter directly in front, and the ball went in..."
This is the feeling you brought to him when communicating with the customer. So, change your thinking style as soon as possible, otherwise you will be the "code monkey" in the eyes of users!
Conclusion
Personally think that "business process" and "business scenario" are the most important contents in the demand analysis process. After the analysis of the two, we can "blatantly" start discussing the functions.
In addition, last week we analyzed NetEase Cloud Music to expand the [small note] function of offline scenes. You can feel the mystery from the two different dimensions of the scene analysis and the application of scenes. There is not much left in the
requirement analysis series. I will try my best to summarize it for one issue, and at most two issues will be summarized for you. Let's see you next time.
Related Readings How to conduct effective demand analysis of
? (III) How to conduct effective demand analysis of
? (II) How to conduct effective demand analysis of
? (1)
NetEase Cloud Music, I will give you a [small note]
# columnist #
Xiaozhuang classmate; public account: Xiaozhuang classmate product notes, everyone is a product manager columnist. B-end product manager in the field of smart campus.
This article was originally published by Everyone is a product manager. Reproduction of
is prohibited without permission from
. The title image is from Unsplash, based on CC0 protocol
