In the business system, is the "user" you refer to actually a real user?

For consumer-facing products and tool-type business-facing products, user research focuses on users' operation habits and pain point demands, while developing business systems should pay more attention to business rules. In business systems, rules determine functions, and ease of use is only an added bonus. It does not mean that users are unimportant, but that business rules play a leading role.

When developing business systems, product managers will conduct user research to deeply understand user demands through interviews, research meetings, on-the-job follow-ups and other methods, but there is one issue worth clarifying first — is the person you are researching really the "user"?

Consumer-facing products are user-dominated, users can use them as they want, and user research is to study their habits and preferences. Tool-type business-facing products are also user-dominated, whether users will use the product and how they use it determines the success of the product, and researching users' pain point demands is the source of product iteration. But business systems are different. Users of business systems carry out their work in accordance with business rules, and the rules stipulate what they must do, how long they can spend, and according to what standard the calculation is made. Before studying users' operation habits and pain point demands, you must first figure out the rules.

I. Learn Business Rules First

The first step to figure out what rules define users is to fully understand the rules.

Those who develop financial systems need to master financial knowledge, those who develop CRM systems need to understand sales processes. Only by being familiar with business rules can you carry out research and design work better. Otherwise, you can't even understand what users are talking about when communicating with them, let alone guide them. There is also a more practical reason, not understanding business rules will easily make you trapped in users' personalized demands. Most of the demands put forward by users are "solutions they think of", not "real demands under the rules". If you don't understand the rules, you will easily take personalized demands as general demands and implement them into the system.

For this reason, when I conduct user research for business systems, my first stop is usually the rule documents. I will sort out all business-related rules first, and then go to the site to carry out user research.

After finishing learning the rules, the user research really starts, and at this time you will find that users are far more complex than they seem on the surface.

II. Rules Define Users

In business systems, users are just people who use the system. Most of what they do and what data they can view is not chosen by users themselves, but assigned by rules.

I once developed an auxiliary power trading system that serves integrated power generation and retail enterprises (which have both power plants and power retail companies), and needed to deliver two sets of systems for power generation and power retail at the same time. The users of the two systems are both called "traders". On the surface they seem to be the same type of people, but in fact their jobs are completely different.

The declaration rule stipulates that in spot trading, power plants need to declare the volume and price (how much electricity to sell at what price), while power retail companies only need to declare the volume (how much electricity to buy). As a result, traders of power plants focus on generating units and quotation, while traders of power retail focus on the load of their agency users.

The market rule stipulates that power plants settle accounts at node electricity prices, while power retail companies settle accounts at the average market price. As a result, power plants need to predict not only the average market price but also the node electricity price, while power retail companies only need to predict the average market price. Naturally, the two groups of traders focus on different market data.

It is not that the two groups of people are inherently different, but that the rules give them different roles. To understand users, you must first understand the rules that define users.

III. Rules Determine Functions

Rules define users, and also determine the functions of the system.

In business systems, the existence, form and branching of functions are derived from rules, not determined by user habits.

When sorting out the function lists of the two systems in the early stage, we found that the two lists almost correspond item by item, including market data analysis, spot price prediction, trading decision assistance, revenue analysis, and settlement reconciliation. They looked like two copies of the same system, and we once thought that we could reuse most of the content easily. But after the research, we found that the two systems must be developed separately, because the rules require the two sides to do different things, and the system has to provide different functions.

The declaration rules are different: power plants declare volume and price, power retail only declares volume — the trading decision assistance module is completely branched;

The market rules are different: power plants predict average market price and node electricity price, power retail predicts average market price — spot price prediction is branched according to permissions;

The data objects are different: power plants maintain unit parameters and costs, power retail maintains agency users — basic information maintenance is completely branched;

The settlement standards are different: the electricity fee of power plants is revenue, the electricity fee of power retail is expenditure — the standard of revenue analysis is branched.

The parts with the same source also come from the rules. For example, market data and meteorological data, the two sides are facing the same market, so these parts can be fully shared. In addition, there is a unique CRM function for power retail that serves the retail marketing business, and a large data dashboard for the leadership to track and manage the overall situation that aggregates data from both sides.

All these are finally sorted into a branching decision table. For each function module, judge "to share or to branch" based on the difference of rules. This table directly determines the development cost, system architecture, and even the contract quotation.

Functions are determined by rules, does that mean user research is useless? The answer is no. Rules only draw the boundary, and there is still space for users inside the boundary.

IV. User Space Beyond Rules

Rules manage "what must be done", but cannot manage "how to do it". In this space, user research can really play a role.

Still take the auxiliary power trading system as an example. The rules require power plants to declare volume and price, and control the boundary and process, but how to use the system operation to achieve profit under the rules is the idea of traders and the enterprise itself. We spent two full weeks on interviews and on-the-job follow-ups to observe this space, to understand where users get stuck when implementing the rules and what support they need.

Through on-the-job follow-up, we can find that traders of power plants get stuck in strategy analysis: the trading window time is limited, they need to compare strategies of different dimensions, calculate the revenue of each strategy and then choose the optimal one. While traders of power retail get stuck in prediction: the accuracy of power demand prediction directly affects the declaration, if the prediction deviates, they will be deducted money for deviation assessment. Therefore, in these two sets of systems, the pain point demand of the power generation system is "excellent strategy", and the pain point demand of the power retail system is "accurate prediction". These findings determine whether the system is easy to use.

But it should be noted that these research optimizations are for "how to do it", not "what to do". Whether a function should exist or whether it needs to be branched is still determined by the rules. Ease of use is only an added bonus. If the rules do not support it, no matter how easy to use the system is, it is useless.

V. Summary

The "user" in the business system is a user, but more importantly, he is an executor of the rules. Rather than saying that we are researching users, it is better to say that we understand the rules through users. The rules stipulate what users must do, and habits and efficiency only play a role within the boundary drawn by the rules.

Therefore, when developing business systems, product managers must first become experts in business rules, and then experience designers. Rules set the boundary, users fill in the boundary, ease of use is the added bonus within the boundary, and the boundary itself is always determined by the rules.

This article is from the WeChat official account "Everyone is a Product Manager" (ID: woshipm), author: Flying Dog, published with authorization from 36Kr.