The product architecture diagram is usually used in more complex product projects and is one of the indispensable documents when designing complex products. In this article, the author also introduces you to the process and key points of drawing the product architecture diagram, and hopes to inspire you.
1. What is a product architecture diagram
Product architecture diagram is a conceptual diagram used by product managers to express their product design mechanism:
It abstracts the visual and concrete product functions into an informatized, modular, and clear-layered architecture, and transmits the product’s business processes and business models through different layered interactions, the combination of functional modules, and the flow of data and information. And design ideas.
Because product architecture diagrams are usually used in more complex product projects, there are currently very few books and materials on product architecture diagrams (especially entry-level materials are rarely mentioned), but they are indispensable documents when designing complex products. one.
Why paint?
First of all, sort out your own judgment on the direction of the product, and think about the process of how this picture is designed. “What, where is the future scalability” and other issues.
1. Support the output of technology & operations
When this picture is designed, according to the structure and path of the product architecture diagram, the project milestone (RoadMap) can be clearly dismantled, and project members can also generate operating plans and technical systems according to this architecture diagram. Architectural schemes and other schemes that strongly depend on product direction.
2. Let others visually understand your product architecture
It can clearly and simply present your ideas, clarify your product boundaries, and indicate the direction of development. It is often used for demonstration in project planning or project summary, to help people who do not understand your product quickly establish a structure for your product, Cognition of function and complexity.
2. When to draw
It is recommended to write before complex projects:
When you want to start designing a systemic and complete requirement, if you skip the steps of drawing a product architecture diagram and start directly drawing a prototype and writing a PRD, sometimes it is easy to “change and change” and “make a version of the requirement” Then overthrow the situation. If your project is halfway through, but you have never produced this picture, then from this moment, try to produce a product architecture diagram for your product according to the steps below.
3. Preparation before painting
List problem domains
In the early stages of demand, product managers often get only a vague description of requirements, which may come from the boss, operations or users.
It is inappropriate to directly use this sentence as the core product function. The reasonable approach is to list all the problem domains of this product first.
“Problem domain” refers to the spatial collection of all problems that can be solved by your product. Starting from the core requirements, putting all the current problems that need to be solved and may be solved in the future into the scope of the product framework can help your product architecture diagram have higher scalability, and it has room for iteration and optimization in the future.
Taking the needs of WeChat AR as an example, the problem domain is such a collection:
Detailed operation steps:
- Find the words related to the product form and product goals in the received requirements, and list the questions such as “what will the process of XX be” and “how should XX be achieved” until the core can be achieved if these problems are solved The direction of demand and business goals.
- In the process of looking for these problems one by one, whether there are other problems to be solved first, or other business-related problems can be solved / improved.
- List all the questions according to the level, and attach your own preliminary answers to form a preliminary “problem domain” that your product can solve.
4. determine the product direction
After going through the list of problem domains, you should be able to get a vague product direction and functional scope. Summarize the answers to these question domains into a certain product requirement.
Taking the demand of WeChat AR as an example, according to the problem domain, we found that the demand is not only as simple as scanning code components to increase AR recognition capabilities. The role of advertisers needs to be introduced into the entire demand, and cooperation with Tencent and other teams is required. The final product direction description is like this:
1. Detailed steps
The problem domain is very divergent. This step needs to return to the basics, supplement, expand and translate the ambiguous requirements into a product demand that can form a closed loop in terms of business model and user experience.
- Determination of core requirements: Which batch of users and which user needs are solved by the core of my product?
- Product goal: If I measure my product with a digital indicator, what should it be?
- 3. User scenario: What are the basic product forms of core requirements and the paths used by users?
2. Clear business process
This step needs to draw a simple business process based on the core product requirements and answers to the question domain. Business process is a common chart in product design, and the drawing method will not be explained more.
Taking the needs of WeChat AR as an example, from advertisers preparing AR interactions to users using cameras at the front desk to participate in interactions, the entire business process is as follows:
5. start drawing
1. Build a basic framework
The basic product framework is born out of business processes, but compared to business processes, it pays more attention to the enumeration of product functions and the boundaries between functional modules.
2. Detailed operation steps
According to the business process, according to the product mechanism, basic product form and user’s use path envisioned, list the required front page and function & module and other front-end logic.
Put all the mechanisms / functions with similar functions or inclusive relationships in the multiple flowcharts just obtained together to form a simple matrix diagram in a modular form.
Put modules that are obviously in the same product range and the same set of product functions at the same level to get a basic product framework.
3. Clear architecture layering
A product architecture diagram with front-end and back-end relationships is divided into at least three layers: the user perception layer (in which scenarios the user is reached in which way), and the function module layer (through which function modules realize the core functions of the product, and which external Platform functions include information interaction) and data layer (where does the product data come from and where does the product data settle).
After the simple layering in the previous step, we have obtained a preliminary framework, but it is inevitable that there will be the problem of unclear layering. At this time, the hierarchy of the architecture diagram needs to be handled in two dimensions: the boundary of different information levels, the boundaries of modules and modules within the same level.
4. Deal with the boundaries of different levels of information
The hierarchy of the architecture diagram expresses the flow relationship between information, and there must be a logical relationship between different information levels.
Among them, the user perception layer and the data layer can usually be simplified into one layer (the function expression of the user end is often simple in logic, and the source of the data is not the core function of your product), while the function module layer needs to follow the logic of your product The main modules within the layer become the new level.
5. Handle the boundaries of submodules within the same hierarchy
Although the levels are related, the submodules in the same level must be independent and well-defined. Split the function of solving different problems into two sub-modules, so that a problem can only be solved on the same layer, avoiding the situation of moving the whole body at once.
6. Clarify the boundaries between products
Product boundaries are very important for the development and design of system architecture and business cooperation models. Use different colors to clearly identify the boundaries of the products that belong to each part in the product framework. Often, the parts that belong to your own team are indicated by bright colors.
7. Join the information flow mechanism
In addition to expressing the core function of the product, the product architecture diagram should also reflect the path of information flow: the current level of data interaction forms the product function, and the product function generates new data, thereby promoting the function of the next level.
If there is only one main role of the current product, you only need to indicate the way of information flow between the modules with arrows. If the current product involves more main characters, you need to use different color lines to externalize the information interaction between them and each module.
6. Final inspection
A good product architecture diagram should have the following characteristics:
- Clear functional boundaries of the module
- Functions are abstracted, standardized and independent
- The upstream and downstream product function boundaries are clear, and the structure layering is clear and reasonable
- Ability to iteratively optimize
Remember to constantly update the product architecture diagram according to the development of your product. The process of each modification is very helpful to improve the product architecture capability. It will be successful only if it is completed carefully.
