Backend · Business Product · Product Design · Product Manager · Prototype · Jun 22, 2022

Business product prototyping Tips

by HILLERIC

Have you ever been criticized for not considering the plan well during the review of the plan? If you want to pick an embarrassing moment for a product manager, it must be counted as one that was criticized by developer and operator at the review meeting.

The reason is that the product plan is not well thought out, the logic is not smooth, and there are many loopholes. This is especially true for product manager who have just entered the industry. When I made the plan, I felt that I had considered it very well. When I got to the review meeting, I found that many things were really not considered.

Back when I first started out, I had the same problem. After doing it for a long time, I gradually found that the things that are easy to ignore are often concentrated on certain types of problems. So I combined these years of experience and compiled a scheme for self-checking of the plan, which is easy to remember.

1. Additions, deletions, query, edition, display, calculations, and comprehensive examination of abnormal situations

Anyone who has developed a system knows that the four most basic operations of the system are adding, deleting, querying and modifying data, plus how to display data, data calculation rules, and data transmission, basically All operations on data are covered.

Addition: For example, if we want to create a learning system, what needs to be added is the data of courses, classes, personnel and other dimensions.
Deletion: Need to pay attention to whether confirmation is required when deleting, is it logical deletion or physical deletion?
Query: data query. Whether the query is a precise query or a fuzzy query, etc.
Edition: Editing of data. Need to consider who has permission to edit? When to edit? Which fields to edit, etc.
Display: Display of data. How to display the style, how to deal with the display if there is too much data or text.
Calculation: The calculation rules of the data. For example, what are the rules for calculating the reading volume of an article?
Transmission: The transmission of data. For example, whether the data is synchronized in real time or is synchronized regularly. Whether it is incremental or full when synchronizing, etc.

It can be seen that for these seven operations on data, each operation has some details to pay attention to. We can carry out a step-by-step inspection in combination with 5W2H, 5W2H, namely who, when, where, why, what, how, how much .

who: mainly involves permissions. Who can perform the corresponding operations;
when: mainly involves when the operation can be performed, such as when deleting, when some data is related, the deletion operation is not allowed;
where: Where is the entry mainly involved in the operation? Where is the specific location displayed?
Why: why is it necessary to have this feature? Can it not be;
what: What is the specific part of the operation?
how: how to operate, what is the operation process?
how much: how many steps are there? Can it be reduced?

5W2H does not necessarily involve every dimension, but it can help us to consider it more comprehensively. I organized the seven operations and 5W2H into a corresponding two-dimensional table, as follows:

The above are all considered according to the ideal situation, but in actual implementation, there will always be strange things, so we should consider the abnormal case as comprehensively as possible. The so-called exception refers to what we should do when the program does not execute according to our expectations.

The most basic is that the name is repeated, or the network is interrupted when performing operations or synchronizing data, the corresponding data cannot be found when searching for data, and so on.

2. The copy shall be concise and unambiguous, and the copy of similar scenes shall be consistent

When we make product plans, sometimes we need to write prompt text, the purpose of which is to inform users of the current state of the system in a timely manner.

There are three types of prompts: one is to guide the user to perform a certain operation, such as filling in the mobile phone number; the other is to prevent the user from performing a certain operation, such as prohibiting deletion; the last is a simple notification to inform The current status of the system, such as successful submission, successful deletion, etc.

Regardless of the type, the purpose is to quickly and accurately transmit the information of the copy to the user, so the two principles of writing this type of copy are concise and unambiguous.

Quick requirements are concise, and precise requirements are unambiguous.

The so-called brevity is to describe it clearly in less sentence. For example, the prompt for deletion: "Are you sure to delete? It will be invisible after deletion" is not simple enough - "It will be invisible after deletion" is a bit redundant. There is a principle here, that is, the long prompt should generally not exceed 20 words, otherwise the principle of brevity will be violated with high probability, and you can try to reduce it to within 20 words.

The so-called unambiguous is to be logical to ensure that everyone understands the same after seeing it.

Another point is that in similar scenarios, the content of the copy and the sentence patterns used in the copy must be consistent, so as to maintain the unity of the product and give users a professional feeling. A common counter-example is that in the same submission scenario, some prompts are "saved successfully", and some are called "submitted successfully".

3. The interaction design is expected, and the intermediate state should not be forgotten

When doing interaction design, when you don't know how to design, there is a principle that has been tried and tested, that is, from the user's point of view, imagine what the user's expectations are?

For example, when a user queries a report, when the query button is clicked and the amount of data is large, the user's expectation is to see the loading status. For example, "loading...", at this time, if you design it, it will basically meet the user's expectations. On the contrary, if you don't design it, you will just wait there, and the user will feel that they don't know what happened. Is there no data? The experience is bad.

But if you further design the loading progress percentage, and even display the remaining time, then it exceeds user expectations, users will praise you for a good user experience.

Intermediate states in the interaction process are often easy to ignore. For example, when synchronizing data, the states are generally divided into not synchronized, synchronizing, and synchronized. It's OK when the amount of data is small. However, if there is a large amount of data, it may be necessary to synchronize for several minutes. At this time, remember to design the status of synchronizing, such as using a rotating icon to represent "data synchronizing.

4. Pay attention to logical loopholes

Logic loopholes are a common problem in prototype solutions. The most common logic loopholes are roughly divided into several types:

1. Overlapping or missing states

That is, the states do not conform to the MECE principle (mutually exclusive and collectively exhaustive), either overlapping or missing.

2. Inconsistencies

The logic is unreasonable, that is, a certain result is desired, but the preconditions are not met. For example, when sending a group message, the total number of messages should not be expected when the number of people and the number of messages is not selected.

3. Lack of details

That is, only the general logic is described, and the specific subdivision scenarios are not considered, resulting in the emergence of logic loopholes.

For example, when a group message exceeds the maximum limit of the day, it needs to be delayed until the next day. There is a missing detail here. Assume that the number of messages per person per day is 3000. When the teacher's balance has 5 remaining, the teacher will send messages to 2 students (student A and student B), each with 3 messages, for a total of 6 messages. How to send it?

If there is no careful consideration, only 5 will be sent, and the remaining 1 will not be sent. But considering the integrity of the message, it is obviously wrong that a student only receives 2 messages. Therefore, it is necessary to supplement the details of this sending: when the sending causes the message to be incomplete, all the messages of the student are not sent, that is, only 3 messages are sent to one student. Another student's 3 entries are delayed until the next day.

4. Object relationship/state changes

When the relationship or state of objects changes, it is often a high-risk area where vulnerabilities occur, and we need to pay special attention:

Logic loopholes caused by state changes: For example, when designing a question bank, when the status of a question changes from enabled to disabled, then it is necessary to consider how to deal with the test paper that has been associated with the question. If there is no corresponding explanation, there will be logical loopholes .
Logic loopholes caused by object relationships: For example, in the design of a CRM system, when the customer's sales change from A to B, whether to clear some personal tags on the customer. Whether it is emptied or not, corresponding instructions are required.

5. Remember the upstream and downstream dependencies of account permissions

For the scheme of business product system, especially in large companies, there are generally mature account systems (such as EHR, user center, etc.) and permission systems. When we design the system scheme, there is no need to design the account and permission settings separately. We can directly use the existing system of the company. Therefore, we must understand the internal logic and call methods of these dependent systems.

In addition, consider the dependencies between the modules/systems you design and the upstream and downstream systems: whether the data you want to get from the upstream system can be provided normally, and whether the data you provide to the downstream system can be normally compatible.

6. Seek a closed loop in each link, and keep all the alternatives

I remember there was a sentence to describe the closed loop of the scheme, that is, your product scheme is all kinds of pipelines containing sulfuric acid. The pipelines must be closed-loop, and there must be no leaks, otherwise the sulfuric acid will overflow and cause "harm".

Therefore, when we design the plan, we must develop a closed-loop thinking. When the plan is self-checked, we must consider whether each process is smooth, whether all abnormal processes are considered, and if all fail, whether there is a least solution.

This shows the importance of flow charts. Be sure to develop the habit of drawing flow charts before making prototype solutions.

Finally, it should be noted that we can have a least scheme to prevent, but remember not to design a scheme with complex logic for low-frequency scenes. On the contrary, if it is a low-frequency scene, even if it is troublesome for the user, it is not a problem if the least scheme is handled manually.

7. Write at the end

Finally, although the purpose of the above formula is to make the solution as perfect as possible, unfortunately, no solution is perfect. Don't expect your solution to solve all problems, as long as the solution can solve the core problem, the rest Imperfections can be accepted.

Only accepting imperfection is the beginning of perfection!