When we are designing Internet or system products, most product managers understand the importance of product creativity and interaction design. However, how to turn an excellent product idea into a real product, and how to reflect the beauty of interactive design, we must carry out product design in a rigorous and orderly manner.
In the design work of To B products, especially back-end products, even though these products are usually more complex in logic, they can still encounter a product manager receiving a demand task, and start to draw prototypes and interact with each other. In fact, this method of work is often undesirable. It is the first priority to clarify the nature of the demand and reflect it in a reasonable and perfect way in product design. From then on, we should abandon all unmarginal illusions and start product design from the most calm and rational perspective.
Step 1: Analyze the requirements and ask questions
When doing needs analysis, a big taboo for product managers is to do it as they are, without asking questions. There are two possibilities for not asking questions: the first possibility is that the requirements have been raised and there are no questions to ask; the second possibility is that the requirements analysis is not in place.
For example, there was once a business department’s requirement to change the original T+1 financial product redemption experience to T+0 real-time payment. However, the demand did not propose a specific implementation method, only that they could advance a portion of the money to investors. When we analyze this demand, we must first understand that the first priority of this demand is that, in any case, investors should get the redemption money immediately after the redemption.
- The first wave of problems to be solved is more general:
- Once T+1 becomes T+0, does the original T+1 product still exist?
- Should I recreate a T+0 product or change the original T+1 product to T+0?
- Will this T+0 product be the only T+0 product in the system or the first of multiple products of the same type in the future?
After finding the answers to this wave of questions, we will have a general understanding of the boundaries of the T+0 redemption business. If it is an isolated case, it is a functional module-level task. If it will be carried out on a large scale in the future, then we should start to consider the scalability of the function from now on (However, the market is always changing fast. At first, it is only to do it first. Later, there are many situations in which it will be carried out in large quantities. It mainly depends on the product manager himself. Is the judgment accurate?).
After finding the answers to the first wave of questions, it will enter the second wave of questions:
- Which departments will cooperate in this business?
- Who leads and who collaborates?
- From which account will the funds be withdrawn and when?
- Is there a refund, and what conditions trigger the refund?
- For each node of these processes, who will advance, who will review, and who will be notified?
The answer to these questions is the most critical material that can complete the product design. Questions in this dimension should be asked at the atomic level that can no longer be asked. The test standard for whether the question is completed is whether the product manager can dictate the flow of information and capital in the entire process smoothly. If there is one thing that is not understood, that one will become a pit in realization.
The third wave of issues is also very important. The issues at this level are mainly at the system level. E.g:
- Which systems can coordinate to fulfill this requirement?
- How does the system interact with each other?
- How to ensure data consistency?
- Once one system goes down, how does the other system roll back or tolerate faults?
In this wave of questions, technical colleagues may be required as consultants, but the Q&A does not need to be too detailed, because it is currently only in a demand analysis and has not yet been designed.
After three waves of questions, 70% to 80% have answers, we can write a rough demand analysis report to the business department for confirmation. Oh, I know a lot of product managers say I don’t have time to write this stuff? Yes, you can not write, but you can’t think about it.
Step 2: Use case first, frame boundary
If there is a back-end product manager who does not know the use case, it is a big pity. Because there is no use case, there is no whole system. In short, as long as the pre-set use cases can be completed, no matter how poorly implemented the system is, it is at least a qualified system.
I won’t talk about how to write use cases here. I personally think that the best reference is “Elephant-thinking in UML”. The significance of writing a good use case is to divide clearly, which requirements need to be implemented and which do not need to be implemented in the current version that needs to be implemented. This is very important. If it is not clearly divided, it is likely to appear in the writing of the requirements document. New requirements are constantly added, which delays the version plan and makes the version function uncontrollable.
Step 3: Divide modules by role, divide templates by function, and make pages by template
In the eyes of many people, the prototype design of the back-end product does not seem to pay so much attention to interaction. It is just a bunch of “so-and-so management” operation pages. Most of the domestic back-end products we have seen, such as various OA systems, process management back-ends, ERP back-ends, data management back-ends, etc., are mostly scribbled and unimaginable.
Having said that, I can’t help but want to turn aside:
- Why is my country’s food world famous, high-end kitchenware is still used in Germany?
- Why is our country the birthplace of Chinese medicine culture, and now high-end Kampo cosmetics are still only South Korean horse heads?
There are many reasons. If national defense strength or aerospace science and technology needs the support of national financial resources, then we are not good at innovative designs of civilian products. This seems to be a social problem.
So, how should we do page-level functional design? There is only one purpose, to reduce the cost of learning and improve the efficiency of use .
Assuming that the product has been in use for many years, unless there is a new design for significant simplification and ease of use, the original interaction logic should generally not be changed, no matter how idiotic you think the logic is. The reason is very simple. The users of this product are likely to be some call center staff who have not graduated from junior high school, and they are likely to be people who rarely deal with computers. They are not people like us who research various Internet products every day. When we have completed the prototype, we should simulate users to try to see if we can complete the set work, rather than immersing ourselves in the application of various so-called high-end interactive design concepts.
Next, continue to the topic.
In the module design, why are there “this management” and “that management” modules, who is managing them, and what is the purpose of management? What is the pre-work (pre-process) of this module? What is after finishing the work of this module (post-process)? These all need to be considered clearly.
Personal advice is to use one or a type of role work as a large module, and treat different sub-tasks in this type of role as sub-modules. In this way, this kind of role can focus on processing work, without the need to jump between different modules of the entire system here and there, and forget the operation if you are not careful.
Here is also a simple example.
I have seen some product designs that put certain business applications and reviews on one page. Personally, I am very opposed to this design. The first disadvantage of this design is that it forces the technical implementation to set permissions to the button level, which increases the workload; the second disadvantage is that for operators and auditors, it is impossible to display different content separately. The information you see must be exactly the same. After all, you share a page, so the scalability is also poor.
Let’s talk about sub-templates by function.
Each page has its own function, and no page has any function. General page functions can be roughly divided into: comprehensive display page (dashboard type page), form ticket type page-that is, fill in some data and save the page, list type entry page-that is to display data tables with some index links Pages (such as product list, investor list, etc.), data query pages-that is, pages with search and result areas, and detailed homepage pages-that are pages that display all the data of an object (such as personal information, account details) Wait). In addition, the pop-up window also has some templates, which are not listed here.
If we can preset some templates and reuse them as much as possible in the page design, not only can we save our working time, but also the learning cost of users can be further reduced, because for most people, analogy is better than starting from scratch. Learning is much easier.
Of course, this is a gradual process. We should also iterate on our page template library in each product iteration, and continue to reintegrate and split to adapt to the new business and further optimize the original business.
When we have completed the above three steps, it can be said that most of the product design work has been completed, but this is only the design stage, and these work have not yet reached the stage that can be submitted for development.
