When doing product design, we will encounter a lot of business processes. When we need to explain a relatively complicated process to the development, a clear flow chart is very important.
When we do product design, we will encounter a lot of business processes, some are simple, some are complicated, some are single-job, and some are multi-job. When we encounter a relatively complicated process that needs to be explained to the development, no matter No matter how detailed the statement is, it is far less useful than a clear flow chart.
If you think a business process is too complex to be expressed in a flow chart, then most likely you cannot express it in words.
Some product managers with a liberal arts background are more sensitive to text than graphics, so they can use very detailed text to describe the details of a process, but if you ask them to draw a flow chart, no one can see it I understand, if you happen to be such a person, I hope this article will help you.
1. Understanding the flow chart
Before drawing a flowchart, you need to know what the different graphics on the flowchart represent, so that you can use them correctly when drawing a flowchart.
Generally, [ellipse] is used to indicate the start or end node of the process, [rectangle] is used to indicate the regular node of the process, and [diamond] is used to indicate the judgment node of the process, and nodes are connected by [arrow]. When drawing, you can consider adding different colors to different graphics, so that the recognition is higher.
Such a convention makes it easier for the drawer and reader of the flowchart to reach a consensus, and also makes the drawn flowchart more readable.
2. Single job flow chart
This is the simplest form of flow chart, which is just a flow in the system, or even a certain system function module; it only describes a user's action, or just describes the operation logic of a function module.
For example, we can draw the simplest user login operation flow chart:
the above picture describes the process of a user completing a business operation from the perspective of user operation. This kind of flow chart is called [business flow chart].
Let's draw a flow chart of login verification:
the above figure describes the processing logic of a function from the perspective of the system. This kind of flow chart is called [system flow chart] or [function flow chart].
We can even draw its verification flow chart separately for the operation of entering the mobile phone number:
Through the above simple flow charts, let's summarize how a qualified flow chart should be drawn:
1. Use correct graphics to express the corresponding nodes. The text of the nodes is concise and clear to describe the actions to be executed. Notes can be added if necessary. For example, the judgment of the first 3 digits of the verification mobile phone number in the above figure, because there are many conditions, if all possible first 3 digits are written out, the flowchart will be too bloated. In this case, just give a simple example Just use an example or add a comment to let the developer know what judgment is to be made here. As for the detailed judgment rules, they should be recorded in the requirements document in detail.
2. For the same judgment node, control the judgment results within 3, and 2 are the best. If there are many judgment conditions, divide it into as many judgment nodes as possible, and each node only processes one judgment condition. If a judgment condition has 2 results, then the two judgment conditions together may have more than 4 results.
3. The lines cross and overlap as little as possible.
4. Merge process nodes with the same function as much as possible. This can make the flowchart more concise, but be careful not to use the same or similar node copy if the two nodes have different functions.
5. The main flow is drawn from top to bottom, and the branch flow is extended from left to right. People's reading habit is from top to bottom, from left to right.
6. If a process is too complicated, the sub-processes that can be independent can be drawn separately as flow charts. For example, in the above example, draw two separate flow charts for the main process of login and the sub-process of verifying the mobile phone number input during login, which is easier for development and understanding. If mixed in one flow chart, it will make people feel that There are too many processing logics, and the main process and sub-processes are interleaved. People who look at the picture will find it too complicated and difficult to understand.
Based on the above conclusions, let's look at an extreme negative example:
From the above example, we can know that this flow chart has the following problems:
1. All nodes use wrong graphics.
2. A judging node performs multiple conditional judging at the same time, resulting in too many judging results and confusing process.
3. The process lines overlap, which affects reading.
4. Regarding whether the 11-digit number is a separate judgment condition, it only needs to output an error prompt result. Too many prompts make the process too redundant.
5. The process is "both left and right", and it is easy to feel at a loss when reading.
3. Multi-job flow chart
The multi-job flowchart is much more complicated, it may involve multiple roles, it may involve multiple systems, and it may even involve multiple roles and multiple systems at the same time, and the following will illustrate one by one.
Before that, we need to know a new graph - [swim lane graph].
As the name suggests, a swimlane diagram has multiple swimlanes, and each swimlane can represent a role or a system, so that we can express the collaboration process between multiple roles or multiple systems in different swimlanes.
To give an example of multi-role collaboration, assume that the main process of asking for leave in the OA office system is as follows: employee asking for leave→approval by superior supervisor→approval by HR manager→approval by general manager. The leave will only take effect after all approvals are completed. If one of them refuses, the process will not be submitted to the next approver. Let's draw this flow chart:
each vertical swim lane represents a role, arranged from left to right according to the approval order, and then draw the process of each role in the corresponding swim lane.
The flow of multiple systems is also drawn in the same way. What if multiple roles and multiple systems exist at the same time?
Still in the above example, we assume that attendance is a separate applet. Employees ask for leave through the attendance applet, and the approver approves through the OA system. This time involves multi-system and multi-role collaboration. What we drew above is a vertical swim lane diagram. At this time, we only need to introduce a horizontal swim lane diagram to represent multiple systems:
1. Process optimization
Whether a flow chart is good or not depends not only on whether it is drawn clearly and easily, nor whether it is drawn beautifully and concisely, but also whether the logic it expresses is reasonable and optimal.
The above picture shows the fields that need to be filled in when registering on most platforms. First, we draw a flow chart for verifying whether the mobile phone number has been registered in the registration process according to the registration conditions in the above picture: there is no problem with the drawing of this flow chart,
logically is also established, but is it reasonable or optimal? Let's analyze it.
If the user finally registers successfully according to the main process, this process is no problem, but if the user's mobile phone number has already been registered, for the user, at this time the user has already entered a lot of information, and you tell the user that the registration cannot be done. Users will feel disgusted and even annoyed. For the platform, the SMS fee for sending the verification code is an avoidable expense.
Therefore, we can optimize this process. First, after the user enters the mobile phone number, the system first checks whether the mobile phone number is registered. If it is registered, the user can be reminded immediately: If the user ignores the prompt, continue to fill in the
registration Information, when sending the verification code, if the mobile phone number has been registered, it is meaningless to send the verification code to the user at this time, so when sending the verification code, it is necessary to verify whether the mobile phone number has been registered again: through this
process Optimization can achieve the purpose of reducing costs and increasing efficiency.
Cost reduction: reduce costs. With the optimized process, when the user sees that the mobile phone number has been registered, he will not continue to enter, which reduces the time cost for the user to enter subsequent information; the mobile phone number has been registered and does not send a verification code, reducing SMS charges and reducing the economy of the platform cost.
Synergy: increase efficiency. With the optimized process, when the user enters the mobile phone number, if the mobile phone number is already registered, the user can immediately switch to log in, interrupting the registration process that is not necessary to continue in advance, shortening the entire operation time and improving operational efficiency.
If a process is too long, we need to pay attention to the nodes that jump out of the process when planning the process.
For example, in the above registration flow chart, we can continue to go down after finding that the mobile phone number is not 11 digits as shown below, and report all error messages to the user at one time after all the judgment conditions are executed: this method is harmful to the
user In terms of experience, it is relatively good, and we can know all errors and correct them at one time, but sometimes our system process is very long, and each step requires a lot of judgment and takes a lot of time, so we will use another method, It is to interrupt in advance and jump out of the process, as follows, when it is judged that the user's mobile phone number is no longer 11 digits, it will no longer judge, and directly report an error message: After optimization, the process becomes simpler, but it also means that the
drawn The flow chart will be more complicated because more process scenarios have to be considered. Therefore, optimizing the process is the work that really tests the product manager's skills.
Let's take a look at how the above attendance process can be optimized.
If we analyze it carefully, we will find that the attendance process also involves other scenarios.
Scenario 1: The person who submitted the leave application is the head of the department, and there is no direct supervisor in the system. In this scenario, if a person is a superior supervisor, after submission, the superior supervisor will be approved by default and directly submitted to the HR manager for approval: The second scenario: Assume that the
immediate superior of the HR manager is the general manager, HR When the manager asks for leave, what is the procedure? In fact, the process of this scenario has not changed, but there is a special situation, that is, the person who asks for leave happens to be the approver, and at the same time, the superior is the direct approver and the final approver. In this case, we still follow the process. When the same approver is reached, the default approval can be passed:
In fact, none of the processes are missing, but because the roles overlap, two roles complete the process of four roles. Although the process is simplified and the approval is automatically passed, when designing the system, even the approval nodes that are automatically passed need to be recorded in the system.
Finally, I would like to say that when doing product design, don’t abuse flowcharts, and don’t draw flowcharts as soon as any logic comes up. Some logics are very simple and can be explained in one or two sentences, so there is no need to draw flowcharts. See the flowchart Too much, and it is easy to get tired.