Ten thousand words long article! A very comprehensive guide to B-side product design

This article wants to discuss with you how B-side products should be planned.

Many people say that the most important thing in making B-side products is to understand the business logic. As long as you understand how the business works, you can make products that meet business needs.

However, the complex business demand environment of B-side products is like a dense forest. If a product manager is not careful, he will get lost in the business details and make a product that only covers the surface of the business. The fundamental reason for this situation is that it is difficult for us to fully digest the business processes and norms that an industry has spent several years or even decades to establish in one or two weeks.

Faced with such a complex scenario, the best approach for product managers is to proceed step by step, starting with the most general business goals, then analyzing the business processes, to the work content of each position, and finally the details of data and reports.

As Gale's Law states, a complex system that works must have evolved from a simple system that worked. A complex system designed from scratch is simply not workable, and you can't tinker with it to make it work. You have to start over with a simple system that works.

This process from rough to fine is like when we inspect an ancient site, we first circle around the outside and use a drone to take a bird's eye view of the entire building to get a general understanding of the overall outline. Then we go inside the building, walk through the main passage, understand the internal structure, and finally study each area in detail.

Product Background Analysis

Only by knowing yourself and your enemy can you fight a hundred battles with no danger of defeat.

Whether designing a C-end product or a B-end product, we must first conduct an in-depth analysis of the "users". C-end products directly look at user characteristics, create user portraits and group them. B-end products need to analyze the business process of the enterprise and then look at the needs of different users.

The task of the first stage is to have a general understanding of the business areas served by the product. We can conduct research from the aspects of industry background, business goals and demands, organizational structure, job division, etc. Although the first level is not enough to let people understand the specific logic of the business operation, the panoramic view of the business drawn by the business architecture is of great help to further understand the needs, so as not to get lost in the dense forest of needs.

1. Target customer group analysis

Every product has a specific user group, and B-side products are no exception. The first step in background analysis is to figure out who the product is sold to.

When we are making C-end products, we are used to using "user stories" to help us define user types. When we are making B-end products, we can also use a "corporate story" to help us clarify the needs of the target group.

“The target customer group is a ____ company. Before our product, they worked like this: ____. The current way of working has ____ problems, so they want to use our product to solve ____ needs and expect to achieve ____ results.”

Suppose we want to develop a CRM product for real estate agents in second- and third-tier cities. The company story can be written like this:

• The target customers of the product are small and medium-sized real estate agencies in second- and third-tier cities. Before our product was introduced, they mainly used common CRM tools on the market to manage their customers. However, the tools currently used are not adapted to the processes of real estate agencies, resulting in non-standard processes, some links being conducted online and some offline, inadequate data supervision, and chaotic management of sales staff. Therefore, we want to use our product to standardize the process in order to improve business quality and standardization efficiency.

Through this corporate story, we can determine what industry and size of companies the product is targeting, and then clarify the core demands of such companies. In the future, when developing functions and designs, we can focus on this core demand, which is also the direction for continuous product updates and iterations.

2. Business goal analysis

This short company story is of great help to our subsequent demand analysis. Next, we have to do a multiple-choice question to help us understand the positioning of the product.

How important is our product to the business?

• Survival needs: This product is related to the company's survival;
• Core development needs: This product will help the company improve its core productivity and competitiveness;
• Secondary development needs: This product does not have a significant impact on the company's production or development, but it is beneficial for the company to solve some specific problems, help the company improve its work in non-core areas, or improve its work in core areas;
• The icing on the cake requires: It is better to have this product, but it doesn’t matter much if you don’t have it, as there can be other alternative solutions.

Any B-end product must satisfy a certain value of the enterprise at a certain stage. If our products directly affect the core business processes of the enterprise and are of great help to the production and sales of the enterprise, then such products are more popular with the enterprise and are more popular at all stages of the enterprise's operation, such as various business process systems, ERP and CRM in some vertical industries, etc. If our products are of the type that improves the operation and management of the enterprise, they will only be more popular when the enterprise grows to a certain scale and management needs arise, such as the common CMS, OA, HRM, etc.

I believe this question is not difficult to answer, but it can help us accurately understand the positioning of the product itself. In many cases, the clearer the positioning of the product, the easier it is to consider from the customer's perspective and understand the customer's ideas.

Strategic analysis allows us to have a clear idea of ​​the product, and the subsequent demand analysis is the focus of our product design.

Business classification and demand sorting

When making C-end products, the most important step is demand analysis, that is, thinking about what types of users encounter what problems in what scenarios. So when making B-end products, what is demand analysis for B-end products?

This seemingly simple question is not so easy to answer. Many people think that the B-side demand is what needs to be done to help users complete business processes. But this understanding is incomplete. The author believes that the B-side demand includes three types:

• Business needs: that is, solving problems encountered during the operation of the enterprise. Business needs are also the goal of product construction.
• User needs: describe what tasks users need to complete and the problems encountered in the process of completing this task; it is worth noting that user needs are usually scattered and contradictory. Users will raise needs from different angles and levels, usually in one sentence. Moreover, since users are at different levels and departments of the enterprise, the phenomenon of "blind men touching an elephant" is inevitable, which leads to the one-sidedness of the needs.
• Software requirements: are the requirements that product managers generate to guide development after analyzing, refining and organizing business needs and user needs. They are the final product of demand analysis.

The main purpose of demand analysis is to obtain software requirements that provide guidance for system development. Before that, the first thing we need to do is to explore business needs and user needs. The main task is to sort out all the business types of the target customer group, divide the different business types into clear boundaries, and sort out all the business needs and user needs in each business type. This process is also a process of demand clarification.

1. Business process analysis

Business process analysis is to analyze the characteristics of business activities for each business event and determine the relationship between business activities. The specific things to do are:

• What information is needed to record these business activities;
• Record what data (reports) these business activities will generate and determine the routes for data transmission;
• Identify which departments and positions are responsible for these business activities.

The core value of an enterprise is to handle the demands of external customers, creating value for the enterprise while creating value for customers. Therefore, the process triggered by business events is the core clue when analyzing needs.

There are several key points when conducting process analysis: first, understanding the hierarchy of the process; second, understanding the types of processes; and third, mastering the skills of finding processes through business events.

Hierarchy of processes

The process has three levels: organizational level, department level and position level.

• Organizational level: refers to business events that have been abstracted and refined, and refers to the general direction of business flow. For example, a product may include organizational-level processes such as production, sales, and after-sales service;
• Department level: refers to what activities each position is responsible for and the relationship between these activities. For example, a product may require the cooperation of the raw materials department and the processing department during the production stage. It is the main clue of demand analysis and the main output of process analysis;
• Position level: refers to the specific operational steps of each business activity, which may be performed by one or more people in a certain position and belong to the demand details.

If we design a CRM product specifically for real estate agents, then when investigating business processes, buying and selling second-hand houses are two different organizational-level processes. Buying a second-hand house involves a series of processes such as viewing the house, checking files, signing contracts, notarization, redemption and transfer of ownership, etc., which belong to department-level processes. When viewing the house, it involves the buyer and seller to initially negotiate the price, payment method, delivery date and other matters, which belong to the position-level process.

Types of processes

In an enterprise, business processes can be divided into different types according to their goals. Generally, we can divide them into three categories: production processes, management processes and support processes.

• The production process is the most important part of the process and the business link that reflects the value of the enterprise. It is usually the easiest to identify;
• Management process is the control of production process, usually the supervision and control of process efficiency and quality;
• The support process is a supplement to the production process and is usually a link that supports the main process. It is not necessary but easy to be overlooked.

In this real estate agency CRM product, house viewing, file checking, contract signing, property redemption and transfer are all part of the production process. In addition to this main process, each link has a corresponding review operation, which is a management process.

Output of process analysis: cross-responsibility flow chart

In fact, when looking at a business flow from different angles, there may be many different processes. There may be large and small processes, and there may be sub-processes in the main process, etc. Therefore, process analysis is a huge project. It is difficult to describe the process clearly only through words. We need to analyze it systematically, so we can use the "cross-responsibility process diagram" to help us sort out the context.

The cross-responsibility flowchart is a standard tool for business analysis. It defines a set of standard modeling elements and analysis methods. The following figure shows the process of a real estate agency selling a house.

Seeing this picture, many readers may be confused: This picture is too simple. Negotiation and transfer procedures involve many business judgments, why are they not reflected in the picture?

This is because they belong to the detail level. The principle of judgment at this stage is: they will not affect the process of other lanes, and they do not need to be shown at this stage. In this scenario, although the negotiation and bargaining are complicated, its judgment process will not affect other lanes, so we can ignore it for now.

2. Role and usage scenario analysis

Many readers may wonder, "I am making a B-side product. After sorting out the process, I can know what functional points need to be designed to describe the needs. Why do I need to analyze roles and usage scenarios? For a B-side product, users should be the same during use. Isn't it redundant for us to divide these users into different roles?"

Indeed, I had the same idea when I first came into contact with B-side products. Until one day, a friend described their product to me.

"Our product is a collection system for government officials to manage the collection process. This product includes functions such as filling out calculation forms, selecting resettlement housing, selecting compensation standards, and checking the number of people who have signed contracts. The calculation form is divided into certain modules..."

I was really confused at the time. Then I asked him two questions:

• Who is using this system?
• What problems does this system help these people solve, and how?

After asking these questions, I immediately realized that these two questions are typical use case analysis methods.

A user story is a series of actions performed by a certain type of user to achieve a specific goal. At the description level, we can temporarily ignore the business goals, so a user story contains two elements.

Participants

Participants are anything outside the system that interacts meaningfully with the system in this process. Participants can be not only people, but also other systems or hardware devices.

For example, when viewing a house, the salesperson retrieves the floor plan and detailed information of the house from the backend system. At this time, the backend system is one of the participants. If our new house has not been renovated yet, when VR glasses are used to let customers see the effect after renovation, VR glasses are also participants in the process. A participant is a role, not a specific person. In some scenarios, even one person can play multiple roles.

What to do (use case)

A use case is a series of actions that a user performs in a system, usually expressed in the form of "verb + noun". It is worth noting that a use case has a goal and can bring meaningful results to the participants. For example, "fill in the search conditions for houses" obviously has no meaning to the participants and is not a suitable use case.

In addition, a use case is an abstraction of a set of usage scenarios. The relationship between use cases and scenarios is like the relationship between classes and objects in computer concepts. A scenario is a specific behavior, and a use case is an abstraction of a class of related behaviors.

For example, when we are looking for a property on the system, we may encounter many scenarios: using the search box to directly search for a property of interest, selecting a property based on filtering criteria, selecting a property based on recommended new properties, pulling two or three properties for comparison and then selecting, etc. No matter how many situations there are, as long as we are doing the task of selecting a property, these scenarios can be summarized as a "selecting a property" use case in the system.

In traditional structured analysis and design methods, the analysis perspective of things is to think from the solution level, that is, what the system needs, and to plan functions from the perspective of the system. Users often complain that the products made in this way are too difficult to use, it is difficult to understand the meaning of the system, and they don’t know where to find the required functions.

The "user story" driven requirements analysis method is a perspective that focuses more on "starting from the user's perspective and treating the system as a black box". This method can effectively solve the above problems.

From another perspective, the key point of user stories is to discover the users who use the system, understand and sort out how these users use the system, so as to achieve a "people-oriented" needs analysis.

How to find use cases for B-side products? And how to find all the use cases? This is a problem that often troubles product managers.

In fact, we can get use cases from the flowcharts of each business event processing process. As mentioned above, the flowchart is the product of our communication with the middle-level managers of the enterprise. As long as there is a flowchart for each business event processing process, we can derive the corresponding use cases from it.

The different positions corresponding to the cross-functional flowchart are the participants who may generate use cases, and together with the things they are responsible for, they form a complete business use case. That is, everything our customers need to do to complete a business. However, when we make a product, we often cannot meet all the business links of our customers, and we can only select the business chain of the core scenarios that match our products for in-depth analysis.

Therefore, for us, the business use cases selected in this stage are actually system use cases. The key points of judging system use cases are whether the use cases "belong to the system scope" and whether what they do can generate business value. All use cases that meet these two conditions must be recorded. In this way, we can get a complete system use case.

Some readers may ask: At what point should the use case analysis be completed?

My advice is not to pursue perfection. As long as you feel you have figured out the client's business, you can consider ending it, without having to wait until every detail is sorted out.

Facing an unfamiliar field, a business process that has undergone many years of development and changes, it is indeed a big challenge to figure it out in a short period of time. The significance of use case analysis is to help product managers understand the business composition from a structural and overall perspective in a short period of time. Use cases are relatively high-level business abstractions that are easier for people to understand and accept. Therefore, to carry out this work, you only need to feel that the overall information of the business has been mastered, and you can consider stopping the acquisition of more extensive use cases. Use the existing use cases as a baseline for the next work. The premise of continuous iteration of products is based on the process of continuous optimization and adjustment of use cases.

Obtain user needs

When conducting customer research, we often see product managers asking customers in a silly way: Do you have any needs or ideas for this product? But no matter how the user answers, it seems difficult to satisfy us. If customers can't raise any needs, you will feel that our customers don't seem to care that much about this matter. More often than not, the needs raised by customers are not important or you feel that they are very personalized, making you feel that it is not right to do it or not to do it.

Like the C-end scenario, user needs in the B-end scenario are like an iceberg, with a large part of the information buried below the sea level, which brings great trouble to demand research. The main needs are divided into three types:

• Aware needs: These are needs that are above sea level, usually problems that bother users, or features that users can think of themselves. Most product managers obtain this type of needs during the research process;
• Unconscious needs: These are problems that users "do not realize are problems" in actual work scenarios. This type of problem requires product managers to have a certain understanding of the business to discover. If you can "empathize" with these scenarios, I believe that you can design more reasonable and efficient solutions during product planning;
• Further requirements: After all, the users of the survey are not technical experts, but ordinary business personnel, so they have no way to propose solutions that will change their work. Therefore, product managers need to fully understand the problem and choose the appropriate implementation method to create functions that users have not expected.

When designing this CRM product for real estate agencies, sales staff reported that they needed to send information about different properties to customers when they were selecting properties. So after hearing this, the product manager added a share button to the action button area for each property in the property list.

When I happily gave it to the salesperson, the salesperson said that this function was not practical because it was impossible to merge the information of multiple properties and send it to customers. However, the product manager thought that you can send them to customers one by one, so the product design can still meet the business needs, but the salesperson wanted to merge the information of multiple properties and extract the key information to send to customers for comparison, rather than just displaying the information of each property.

This scenario is the result of only discovering the perceived needs without delving deeper and conducting further analysis.

In fact, it is not difficult to obtain the demand for B-side products, but the difficult part is the process of communicating with users. Because our users are just users, they only stand from the perspective of their own use, want to make their work more convenient or more beneficial to themselves in the distribution of benefits, and it is difficult for them to consider the overall situation from the perspective of system planning.

When encountering this situation, the most effective response strategy is to start with demand analysis from the process, figure out how business activities are usually carried out, and then gradually transition to what obstacles exist, what difficulties there are, etc. In this process, ask more questions and think more about the psychological state and interest conflicts behind the customer's demands.

So at this stage, our main work is to collect problems and needs for business activities. At this time, we get the original user needs.

In fact, in the entire process of business classification and demand sorting, business process analysis, role and usage scenario analysis, and obtaining user needs are all accompanied by user research. User research is a planned and step-by-step process. Specifically, when targeting different interviewees, the key points of the interview are also different. For specific key points, please refer to the following table:

In addition to user interviews and questionnaires, having the opportunity to observe actual business work on site is also a good way to obtain requirements, which helps product managers to establish a more intuitive understanding of business scenarios. When the understanding of key tasks is unclear and many things cannot be expressed in words, on-site observation is a good way.

At this point, we have collected enough business information for us to carry out subsequent demand analysis.

1. Determine the details of the requirements

Complete use case

The task of this stage is to fill in the details of the use case. The user stories in the previous stage have already explained how the business is executed, but there is no mechanism to express how to "achieve it". For example, after a real estate transaction, some contracts can be archived directly by the salesperson, while some contracts need to be reviewed by the department manager before they can be archived. In addition, what are the preconditions for archiving, and what changes will occur in this business after archiving? These are all issues that need to be considered in this stage.

Therefore, in the stage of perfecting the use case, we need to do the following:

• Map use cases to requirements;
• Describe the flow of events for a use case;
• Supplement the preconditions and postconditions of the use case;
• Identify the rules and constraints for the use case.
• Use cases match requirements

Using use cases as the smallest unit of requirements is a method of classifying and managing requirements from the perspective of business flow. At this stage, the first thing we need to do is to organize the original user requirements obtained in the user research phase into corresponding use cases, so as to establish a mapping between the original user requirements and the software requirements (use cases).

In actual operation, we can use the following table to manage demand tracking. The first three columns describe the number, description and proposer of the user's original demand, and the next two columns are the corresponding use case number and use case name. These original user demands come from user surveys, demand descriptions provided by users, and feedback obtained during the use of the system.

With such a table, we can manage user needs more appropriately and it is also easier to find conflicts in needs.

Expressing event flows

For use cases, the three most common event flows are:

• Basic event flow: It is a description of the expected path of the use case. It is the scenario encountered most of the time and is also the core path that meets user expectations and business intentions;
• Extended event stream: also called branch event stream, mainly used to describe different user choices and express abnormal situations;
• Sub-event stream: used to summarize the repeated parts of the event stream, similar to the "loop structure" in the code.

In the example of buying a house, the basic event flow is that both parties complete the transaction according to the predetermined route, the price negotiation process between the two parties is the sub-event flow, and the transaction process between the buyer and the seller is interspersed with more transaction situations, which belongs to the extended event flow.

Supplementary preconditions and postconditions

The so-called precondition refers to the state that the participants and the system should be in when the use case starts. This state is detectable by the system and is meaningful. The postcondition refers to the state that the system should be in when the use case ends. This state is also detectable by the system and is meaningful. Let's deepen our understanding through the following examples:

• The customer has the intention to buy a house: This is not a prerequisite because it cannot be detected by the system;
• Customers log in to the system to view the house pictures: This is not a good prerequisite. Although the system can detect it, the significance of this is not very helpful to us.
• Review passed, contract completed: This is a good post-condition that the system can detect and the event has an impact on the process.

Generally speaking, a precondition is usually a state, and a postcondition may be a state or a subsequent behavior. Not all use cases have preconditions and postconditions.

Rules and design constraints

Rules are things that should be considered in the implementation phase, while constraints are various conditions that restrict technical means. Adding rules and design constraints at this stage is the last thing we do when organizing use cases.

From the perspective of demand, the rules involved in use cases can be roughly divided into two categories: business rules and data rules.

• Business rules: These are rules related to business logic and business processes. For example, in a business system, after a salesperson contacts a buyer, the system will not assign this customer to another salesperson; after a salesperson releases a customer, other salespeople can contact this customer, etc.
• Data rules: These are rules related to business attributes. For example, the maximum length of a marketing SMS message sent by a salesperson to a customer is 200 Chinese characters; the salesperson's effective performance for the month is the total amount of all orders that have been paid for that month, etc.

The constraints of use cases are relatively simple, usually referring to non-functional requirements such as performance indicators, or restrictions on hardware and software, user environment, and technology selection. These restrictions may not exist in every use case, but the design constraints of key business activities must be fully considered to avoid design defects caused by planning.

2. Requirements organization and analysis

Requirements analysis is one of the most important activities in requirements engineering. Requirements analysis is not about analyzing how the system can meet user needs, but about choosing a business-oriented guide to connect scattered needs to form a complete and clear framework to prepare for the next stage of product design.

At this stage, we need to do two things: organize the requirements and eliminate the conflicts between them.

Sorting out requirements

After converting user needs into system requirements, we need to sort out each link and each type of requirements according to the business flow, as shown in the following figure:

This structure is organized based on the business process, that is, it is decomposed from the perspective of "things". This method is very suitable for workflow systems and information management systems.

First, we divide our products into different business segments. At this level, we determine which system requirements are for business events to ensure the normal operation of business processes; and which system requirements are for reporting requirements to ensure data transmission during the circulation process.

Next, we will sort out the system requirements in a more granular way, and sort out which system requirements support the business steps and what functional points need to be designed based on these business steps. In this way, all system requirements will be presented to us in a clear and progressive manner.

Eliminate conflicts between requirements

The above method of sorting out requirements is sorted according to the business process. In this analysis process, because our requirements come from different departments and positions, it is inevitable that some requirements are contradictory and conflicting. Therefore, we need to circle all these contradictory requirements in the sorted list, and then quickly find the relevant personnel to eliminate the contradictory requirements through further communication and coordination.

Often, the real reason for demand conflicts is the conflict between users and managers. As a user, his core demand is convenience, efficiency, and hassle-free, and it is best to gain certain benefits in some aspects; as a manager, his demand is standardized processes, traceable processes, and preventing things that harm the company's interests from happening.

For example, salesmen from real estate agencies often need to take clients to see properties, so they naturally hope to have more flexibility and freedom in attendance. However, as managers, they have no way to keep an eye on what the salesmen are doing at all times, and can only manage them through some means such as location clocking in to prevent them from being lazy.

From this example, we can see that different roles have different core demands due to their different positions. When conflicts occur, the author's suggestion is to focus on the production and operation of the enterprise, first ensure the standardization and process of business activities, and then add usability design and emotional design for ordinary users on this basis, so that they feel that the product is not just an aversion and rejection work system, but a product that truly helps them improve their work efficiency.

After completing this step, the system requirements of the entire product are sorted out. Each subsequent iteration will create new system requirements based on business needs and user needs, and continuously improve and enrich the product.

System construction

Finally, we entered the system construction phase and really started to design the shape of a product. Before that, let’s discuss a question: What are the differences in product design between B-end products and C-end products?

The author believes that the design logic of most C-end products will put user experience and efficiency first. Pursuing the ultimate simplicity, usability and efficiency. In the entire product design, it is more focused on the user's experience, carefully polishing the page and interaction, giving users as few choices as possible, and maintaining the usability and fluency of the product. These are the only ways to design C-end products.

However, when making B-side products, all product designs serve the "process". Experience and efficiency are not necessarily the focus of design. A very simple example can make it clear that when a company buys an intermediary CRM product, it is not to make the salesperson easier and "save trouble" when doing business, but to manage the entire process of selling a house, to perform standardized operations, and to provide more accurate and scientific decisions for business decisions. B-side products are more about realizing the information management of the enterprise through computer technology, optimizing and upgrading the enterprise process, so as to achieve the purpose of reducing costs and increasing efficiency.

From this, we can see that when developing C-end products, we pay more attention to the understanding of "people", and require product managers to have empathy and the ability to perceive users. When developing B-end products, we pay more attention to the understanding of "business", and require product managers to have systematic logical thinking, rationally sort out and diagnose the business of the enterprise, and provide reasonable and effective solutions.

In the process of planning product prototypes, product information architecture design is an important part. The application of menu structure design, CRUD principles and RBAC model can help us design a more reasonable and efficient product form.

1. Menu structure design

There are two common menu structure designs: one based on "people/things" or one based on "events".

Most general B-end products cannot achieve unified process management due to the vertical differences of various industries, and products need to meet the needs of as many industries as possible, so they can only divide the menu structure based on "things". For example, the CRM system is divided into leads, customers, contacts, high seas, business opportunities, contracts, etc., all based on "people/things" as the division standard.

This division method is flawed to a certain extent, because in the actual business process, the transfer of objects may be intertwined. For example, the circulation of contracts is involved in several links such as real estate transactions, title confirmation, and archiving, and this menu structure does not fully reflect the characteristics of this circulation. At the same time, the responsibilities and powers of different positions may also be intertwined.

B-end products that focus on vertical industries often use the division of responsibilities of business processes as the standard for menu division, that is, a design method with "things" as the main line. The advantage of this design method is that it can effectively avoid duplication and confusion, and the architecture of the entire system is very clear.

CRUD Principle

On the Internet, various Internet books have mentioned the CRUD principle, which is to combine operations such as adding, deleting, querying and modifying into one management page. For example, an order management page includes different operations such as adding orders, deleting orders, querying and modifying order information.

However, in many cases, in an ERP system, orders are entered by salesmen, and then the sales staff updates the order information. When a refund is found, the order is canceled by the finance or after-sales staff. This shows that these so-called "management" operations are often not completed by the same role. If they are merged into the same management page, there will be many problems of confusion in responsibilities and permissions. Fortunately, more and more products are now aware of this problem. In menu design, try to avoid using words such as "such and such management", but divide the scope of the menu more flexibly according to business scenarios.

Does the above statement mean that the CRUD principle is wrong? Actually, it is not the case. The CRUD principle is only applicable to things created by the system, such as managing system users, managing data dictionaries, and managing permissions. Adding, deleting, modifying, and checking system users are usually performed by administrators. At this time, it is reasonable to put all these operations on the same interface.

RBAC permission model

The permission design of B-side products usually applies the RBAC model, that is, each user must be assigned one or more system roles, and each system role corresponds to a clear set of permissions, including access and operation permissions to resources such as menus and page elements. Establish a corresponding relationship between "user-role-permission".

At this time, the user and role, role and permissions are many-to-many relationships, that is, a user can correspond to multiple roles, a role can be assigned to multiple users, and a role has multiple permissions. When there are many users, a user group can be introduced, which not only groups the users and associates the role with the user group.

For example, an employee of a sales department is a user group in the system. When a new salesperson joins, he only needs to set up the user group he is in, and the authority associated with the department will be granted to the salesperson. There is also an advantage in setting up a user group. When the permissions of this department change, you only need to adjust the role permissions corresponding to this user group, and there is no need to adjust the relationship between each user and role.

The above three points are the most critical core design points when we are doing system construction. I believe that after the above thinking, combined with the system requirements list compiled in the previous stage, we already have a general product solution in our minds. Next, we can start drawing prototypes and interfaces to show the literal ideas through visualization. Because the design of the prototype is not the focus of this article, I will not repeat it here.

At this point, I believe you have a clear idea of ​​the entire process of B-end product design. Brother Ren once wrote in his book "The Technique Things that Product Managers Must Understand":

Product managers must be accustomed to being with loneliness. This loneliness is not the feeling of loneliness without friends, but refers to the process of thinking and decision-making that will not give you clear guidance. You can only rely on your own independent thinking and understanding to give vitality to the product and make key decisions.

Of course, this article is not a guide to how to make a successful B-end product. Instead, I hope that when you make a B-end product, you can provide some design ideas to help you make fewer mistakes and think about problems in the right direction. I am not lonely on the road to the product, I hope you and I can encourage each other.