业务系统里，你的“用户”真的是用户吗？

在面向消费者的产品以及工具类企业级产品中，用户研究聚焦于操作习惯与痛点需求，然而开发业务系统时，更需要优先考量的是业务规则。在业务系统里，规则主导功能设计，易用性只是额外加分项。这并非否定用户的重要性，而是强调业务规则才是核心驱动力。

开发业务系统时，产品经理通常会开展用户研究，借助访谈、调研会议、现场跟岗等手段深入挖掘用户需求，但有一个关键问题值得预先思考：你所研究的对象，真的是“用户”吗？

面向消费者的产品以用户为核心，用户可自由决定使用方式，研究用户即探究其习惯与偏好。工具类企业级产品同样以用户为主导，用户是否使用以及使用方式决定着产品成败，研究用户的痛点与需求是产品迭代的源头。然而业务系统并非如此，业务系统的用户需遵循业务规则开展工作，规则规定了他们必须执行的任务、操作时长及计算口径。在研究用户的操作习惯与痛点需求之前，必须首先理解这些规则。

一、优先学习业务规则

要理解用户是由何种规则定义的，第一步就是掌握这些规则。

负责财务系统的需要掌握财务知识，负责CRM系统的需了解销售流程，熟悉业务规则才能更有效地开展调研与设计工作。否则，与用户沟通时连对方在说什么都难以理解，更不用说引导用户了。还有一个更实际的原因：不熟悉业务容易陷入用户的个性化需求陷阱。用户提出的需求，往往只是“他以为的解决方法”，而非“规则下的真实诉求”，不懂规则就容易将这些个性化需求当作实际需求来实施。

因此，我在进行业务系统的用户研究时，第一步通常是查阅规则文档，先全面了解业务相关规则，然后再前往现场进行用户调研。

规则学习完成后，用户研究才算真正开始，此时会发现用户远非表面看起来那么简单。

二、规则定义用户

在业务系统中，用户只是系统的使用者，他们能做什么、查看什么数据，大多并非由用户自行选择，而是由规则分配。

我曾参与开发一个电力交易辅助系统，服务于发售电一体企业（既拥有发电厂，又经营售电公司），需要同时交付发电与售电两套系统。这两套系统的用户都称为“交易员”，表面看是同一类人，但实际工作内容截然不同。

申报规则规定：在现货交易中，电厂需申报电量和电价（即以何种价格卖出多少电力），而售电公司只需申报电量（即购买多少电力）。因此，电厂交易员关注机组运行与报价，售电交易员则关注代理用户的负荷情况。

市场规则规定：电厂按节点电价结算，售电公司按市场均价结算。因此，电厂不仅需要预测市场均价，还需预测节点电价，而售电公司只需预测市场均价。这两类交易员关注的市场数据重点自然也不同。

并非这两类人天生不同，而是规则赋予了他们不同的角色。理解用户，首先要理解定义用户的规则。

三、规则决定功能

规则不仅定义了用户，还决定了系统的功能。

在业务系统中，功能的有无、形态及分支，都由规则推导而来，而非由用户习惯决定。

在初期梳理两套系统的功能清单时，我们发现它们几乎逐项对应，都包括市场数据分析、现货价格预测、交易决策辅助、收益分析、结算对账等，仿佛同一系统的两个副本。我们一度认为可以轻松复用。但调研后发现必须分开开发，因为规则要求双方执行不同任务，系统需提供不同功能。

• 申报规则不同：电厂需申报电量与电价，售电公司仅申报电量——交易决策辅助模块完全分支；
• 市场规则不同：电厂需预测市场均价和节点电价，售电公司仅预测市场均价——现货价格预测按权限分支；
• 数据对象不同：电厂需维护机组参数与成本，售电公司需维护代理用户——基础信息维护完全分支；
• 结算口径不同：电厂的电费是收入，售电公司的电费是支出——收益分析口径分支。

而功能相同的部分同样源于规则。例如，市场数据与气象数据，双方关注的是同一市场，因此完全共用。此外，售电公司独有的CRM功能服务于零售营销业务，而领导整体跟踪管控的数据大屏则汇聚了两侧数据。

这些最终形成了一张分支决策表，每个功能模块基于规则差异判断“共用还是分支”。这张表直接决定了开发成本、系统架构，甚至合同报价。

那么，功能由规则决定，用户研究是否就无用了？并非如此，规则仅划定了边界，边界内仍存在用户自身的空间。

四、规则之外的用户空间

规则规定“必须做什么”，但管不了“怎么做”。 在这个空间里，用户研究才真正发挥作用。

仍以电力交易辅助系统为例。规则要求电厂申报电量与电价，控制边界与流程，但在规则之下，如何利用系统操作实现盈利，则取决于交易员和企业的自身想法。我们通过访谈与跟岗，整整花费两周时间，专门观察这个空间，了解规则落地时用户遇到哪些困难、需要哪些支持。

通过跟岗发现，电厂交易员在策略分析上遇到瓶颈。交易窗口时间有限，他们需要对比不同维度的策略，分别计算收益后选取最优方案。而售电交易员则在预测上遇到困难，用电需求预测准确率直接决定申报结果，预测偏差会导致扣减偏差考核费用。因此，在这两套系统中，发电系统的痛点需求是“策略优化”，售电系统的痛点需求是“预测精准”，这些发现决定了系统是否易用。

但需注意，这些研究优化的是“怎么做”，而非“做什么”。功能是否存在、是否需要分支，仍由规则决定。易用性只是锦上添花，若规则不支持，再好用也无济于事。

五、总结

业务系统中的“用户”确实是用户，但他们更是规则的执行者。与其说我们在研究用户，不如说我们是在透过用户理解规则。规则规定了用户必须执行的任务，而习惯与效率都仅在规则划定的边界内起作用。

因此，开发业务系统时，产品经理应首先成为业务规则的专家，然后才是体验的设计师。 规则划定边界，用户填充边界，易用性是边界内的锦上添花，而边界本身永远由规则决定。

本文来自微信公众号“人人都是产品经理”（ID：woshipm），作者：飞上天的狗，36氪经授权发布。