How do Product Managers iterate products based on requirements (Part 2) : The business and system layers of the overall design of the product

Logical layer: entity modeling, role structure, logical flow

The logical layer, as the name implies, is the logical thing, the internal logic of the system and business. Clear logic can be developed, logic is not clear just castles in the air. The logical layer is divided into entity modeling, role structure, and logical flow. Entity modeling explains what major content flows are in the system, role structure explains who uses the system, and logical flow explains how the system works. The following is a detailed description.

Entity modeling

Entities generally refer to things that can exist independently as the basis for attribute positioning. The concept of entity in the industry has this philosophy, but also a specific software module. For example, SKUs, categories and orders in e-commerce can all be called entities, but some entities are important and some are not.

Entity modeling abstracts entities from business processes. Some processes are entity-centric for easy understanding and management. For example, by abstracting the order entity, you can manage the life cycle (state) of the order according to the process.

Entity modeling pays attention to two points: the attributes and life cycle of entities and the relationship between entities.

1. Attributes and life cycles of entities

In the beginning, when choosing which are the main entities, it is important to look at what is flowing in the business process. Sometimes it is not apparent on the surface, so you need to think about the common ground and essence. , for example, on the business process, the administrator will arrange to the user for a period of time a series of work, work is the batch schedule, there is no evidence of entity, by thinking after abstracts the entity of “task”, “task”, the parent task and subtasks 】 【 】, the former refers to the task of administrator, the latter refers to the user’s own task.

Each entity has its own attributes, such as order number, status, seller ID, buyer ID and so on. Attributes are used to make judgment or associate with other entities. The status of an order is to make judgment, while seller ID and buyer ID are associated with other entities. The life cycle is actually a property, and in order to highlight its importance, include all the life cycles of the entity, otherwise exceptions will occur.

2. Relationships between entities

The relationship between entities refers to the logical relationship of entities, including the relationship between entities and entities as well as the relationship between entity attributes and entities. Whether entities are one-to-many, many-to-many, many-to-one, or one-to-one, for example, an account can have multiple orders, and an order can have multiple SKUs. The relationship between entity attributes and entities, for example, [sub-tasks] will be generated after the creation of [parent tasks] in the above example, and [sub-tasks] have the concept of completion and archiving, so attention should be paid to the modification of some attributes after the creation of [parent tasks]. In general, entities and entities are independent of each other, but this is a special case.

The role structure

Every system must have roles, just the number of roles. The role here is at the level of system logic, not at the level of functional modules. For example, the users in the e-commerce background are all internal personnel of the company, divided into different departments. At the level of system logic, their roles are internal personnel, and at the level of function modules, each department is different roles, which are controlled by account, role and permission.

The role division at the logical level of the system is very clear, and the scene corresponding to the role is completely different. As required, the account system is designed for the role, and the appropriate end (PC client, APP, PCweb, MobileWeb, etc.), design style and other things related to the product are selected. Personas are determined by business scenarios, and designing products for personas (another meaning of the target audience) is based on scenarios and core appeals. For example, boss Zhipin includes boss and Nioren in an APP. The entrance is uniform and the account system is open. The core appeal of boss is to recruit nioren at an appropriate price, and nioren’s core appeal is to find a desired job. Didi is divided into passenger terminal and driver terminal. The entrance is not consistent, and the account system is partially integrated. The core appeal of passengers is to get a taxi, while the core appeal of drivers is to make money by running Didi.

Grasp the core appeal of the role as a guiding ideology and program to guide demand planning and product design, which is also the embodiment of cohesion. Roles, modules, functions, systems, entities, and so on can all be summed up in a purpose. That purpose is the guiding ideology, program, and boundary. Before doing this, think about whether it is consistent with the purpose. The purpose can be adjusted, but can not be adjusted casually, to think clearly.

Roles are closely related to processes. The role is the operator and the executor of all operations other than the automatic system in the process. Only when the role is determined can the process be determined, and only when the process is determined can the functions required by the role be determined, so that there is an interaction layer. The importance of the role is beyond doubt.

Logical process

Logical processes are about thinking through the relationships between entities, roles, and functions (actions/judgments/subprocesses). What functions are contained in each module will be found in the process of sorting out the logic, and the priorities of modules and functions can also be clarified, which can be added to the product planning later.

Logical process for different target center will present a different process, with the center of the business process focuses on the business process, with the center of the entity process focuses on the entities (status) of the life cycle, centered on operation process focuses on the interaction and judgment (or to draw interaction layer).

Business-centric processes bring together the above entities, roles, and functions (actions/judgments/subprocesses) on a single diagram. The following two points should be reflected: 1. The service functions of each role are the main functions or operations of each role. 2. Core functions, functions or operations directly related to the business, such as clicking “pay” to generate orders, etc. If there are too many non-core function processes, they can be directly replaced by sub-processes.

Entity-centric processes should reflect the life cycle of entities, and the design of the life cycle of entities should conform to the objective facts. In many parts of the system, the judgment is based on the life cycle of entities. The following points should be reflected: 1. Include all life cycles of the entity, never omit 2. What actions/decisions will adjust the life cycle of the entity is logically and clearly described.

The main process can be sketched out for the developer, and the rest can be sketched out at will, but you have to have logic in mind or you’re not a good product manager.

Interaction layer: module function, page structure, interface prototype

There’s a lot of literature on the interaction layer, so I’m not going to go into that, but just the two most important ones.

1. The interaction layer must be designed based on the business, system and logic layer, otherwise it is just a castle in the air. Among the module functions, which module is derived from the module abstraction of the system layer and which function is derived from the logical process of the logic layer. In the page structure, which end is closely related to the role structure of the logical layer, and how to put it is closely related to the logical flow of the logical layer.

2. The interaction layer should be designed only after the business layer, system layer and logic layer have been reviewed by the demander side, r&d team, operation team and other relevant personnel. Therefore, in the four levels of product design to communicate with the team, users and other relevant personnel, rather than closed car, car has been built to find that there is a problem to tear down all over again, that can be a big trouble.

Local design

Partial design refers to the iteration of non-large version or non-reconstruction of ordinary functions, mainly with the iteration of adding or deleting a certain function/module, experience and so on, which does not touch the core business logic. Here are the precautions. PS: The specific needs and actual situation, every company and products are different.

1. Specify the level of modification

Be specific about which of the four layers of business, system, logic, and interaction you want to change. The higher the level, the more things are usually involved and the more careful you want to be.

2. Sort out old logic related to changes

List the logic, functions, interactions, components and so on related to the change down the hierarchy. First remove the system related to the change, and then remove the modules related to the change, and then remove the functions and interactions related to the change from the module.

I must communicate with technical leaders, architects, back-end engineers and other members to clear out technical problems and discuss solutions. Some problems are invisible to the product but visible to the technology. Communicate with test team members to check the impact of changes and make up for use cases. You must communicate with the designer, check the interactive and visual details of the change, and identify the target audience and usage scenarios.

3. Sort out the new logic of change

Fill in the new logic one by one according to the new requirements according to the old logic sorted out and the use scenarios of target users, just like cloze filling. If you need to add it elsewhere, you need to start with all the logic in that module and design new logic based on usage scenarios, user paths, and so on. For data and entities, consider how old data is handled, for example, if a message has a read or unread state, whether old data is read or unread by default.

4. Inform other departments of relevant problems, plans and changes before issuing the version

Communicate with the demander and related personnel before changing the plan; After the revised plan comes out, a copy should be sent to the demander and relevant personnel to ensure information synchronization and joint decision making.

Before the release, prepare relevant documents of each department, such as QA that needs to be sent to the customer service department, and send them to the docking personnel of each department.

5. Follow up the problems and data feedback of new changes after release

After release, inform all parties and enter the feedback stage. Keep track of issues and data feedback on new changes in order to determine the effect of the release. If any bugs are found in logic and design, deal with them quickly. Avoid major bugs, or you will lose a lot of money. It is necessary to conduct a small ABtest beforehand.

The four articles in the product Manager how to Iterate Products based on Requirements series are finished. Please visit my home page to read the other three articles. This series focuses more on product architecture design.

When writing the article, I found a lot of content can be written, such as a certain vertical domain knowledge, a small module detail design, general methodology, etc. I will also continue to output, please continue to pay attention to, please look forward to.

Search the public account Vency or vencybu2 to share my systematic or extensive deep thinking.