做业务系统先研究用户还是先研究业务规则？

做C端产品时，用户喜不喜欢、愿不愿意使用，往往直接影响产品设计。但进入CRM、ERP、财务、供应链等业务系统后，只问“用户想要什么功能”很容易把需求做偏。

原因在于，业务系统里的用户通常带着明确岗位职责进入系统。谁能看哪些数据、什么情况下允许修改、谁负责审批，这些事情往往已经受到公司制度和业务流程约束。

因此，业务系统并不是不需要用户研究，而是需要先理解业务规则，再研究用户怎样完成工作。

业务系统里的用户有什么不同

业务系统中的“用户”，更准确地说往往是一个业务角色。

例如同一套CRM里，销售、销售主管、财务和管理员虽然都在使用系统，但关注的数据和能够执行的操作完全不同。

• 销售主要维护客户和跟进记录。

• 主管需要查看团队数据和业务进度。

• 财务关注合同、回款和发票。

• 管理员负责账号、权限和系统配置。

因此，设计业务系统时，比年龄、兴趣等普通用户画像更重要的，是弄清楚角色负责什么工作、能看到什么数据，以及拥有哪些操作权限。

为什么要先理解业务规则

用户提出的需求并不一定能够直接实现，因为很多操作受到业务规则限制。

例如用户提出：“已经审核的数据最好还能直接修改。”

表面上这是一个编辑功能需求，真正的问题却可能是业务中经常出现审核后需要纠错的情况。产品需要继续确认：审核后的数据能不能修改、由谁批准、修改前后是否需要留痕。

如果不了解这些规则，只增加一个编辑按钮，虽然操作更方便，却可能破坏审批和审计流程。

所以产品经理在访谈之前，至少应该先了解现有制度、流程、权限和关键业务条件。

用户说的需求可能只是方案

一线用户很熟悉自己的工作，但他们提出的往往已经是一个具体解决方案。

例如：

• “这里增加一个Excel导出按钮。”

• “把这个审批步骤取消掉。”

• “给我开管理员权限。”

产品经理真正需要继续追问的是：为什么要导出？审批卡在哪里？当前权限为什么无法完成工作？

这样才能把“用户提出的方案”还原成“真正存在的问题”。

同一个问题可能有多种解决方式。例如用户要求导出Excel，原因也许只是两个页面的数据无法同时查看，那么增加跨页面数据对比功能，可能比不断导出文件更合适。

角色权限需要和流程一起看

业务系统中的角色不能只根据岗位名称划分。同样叫“运营”，在不同公司甚至不同部门里，负责的工作可能完全不同。

更可靠的拆分方式是判断：

• 这个角色负责什么业务目标。

• 需要处理哪些业务对象。

• 可以查看哪些范围的数据。

• 允许执行哪些操作。

• 完成之后交给谁继续处理。

角色确定后，权限和流程才能继续设计。

例如采购人员可以创建采购单，但超过一定金额后必须由负责人审批；财务可以确认付款，却不能随意修改采购内容。这些并不是单纯的界面权限，而是业务规则在系统中的具体体现。

用户研究真正应该研究什么

规则决定“必须做什么”，用户研究更适合解决“怎样做得更顺畅”。

例如公司要求客服必须记录投诉，这项要求不能因为员工觉得麻烦就直接删除，但可以继续观察：

• 有没有重复录入已经存在的信息。

• 字段和分类是否过多。

• 常用内容能不能自动填写。

• 操作时是否频繁切换页面。

• 系统是否能够及时反馈处理状态。

这些问题不会改变业务规则，却直接影响工作效率。

因此，业务系统里的用户研究更适合关注操作成本、信息获取、异常处理以及实际工作中出现的阻碍。

跟岗往往比单纯访谈更有效

复杂业务如果只通过会议访谈了解，很容易遗漏真实工作方式。

用户可能告诉产品经理一套标准流程，但实际工作中却同时打开多个系统、反复复制Excel、通过聊天软件确认信息，甚至用纸笔记录临时数据。

这些动作使用时间长了以后，用户自己也可能不会主动认为它们是问题。

因此，业务系统调研通常适合把访谈和跟岗结合起来：访谈了解用户怎样理解工作，跟岗观察工作实际上怎样完成。

如果制度流程、用户描述和实际操作出现差异，这些差异往往就是值得优化的地方。

异常流程也需要提前研究

很多业务系统的问题并不出现在标准流程，而是出现在例外情况。

例如：

• 审核后发现数据错误怎么办。

• 审批人休假时谁来处理。

• 订单执行一半需要取消怎么办。

• 接口同步失败后如何补数据。

如果产品只根据正常流程设计，上线后就容易不断增加临时按钮和特殊权限。

因此，调研时不仅要问“正常情况下怎么做”，还要问“如果做不下去了怎么办”。

业务系统需求可以这样整理

一个业务需求不应该只写成“增加某个功能”，至少需要同时说明几个基本信息。

这样可以把业务规则和体验问题分开。规则决定系统必须遵守什么，体验设计则解决在这些规则下如何让用户更高效地完成任务。

对于CRM、ERP、财务、供应链等业务系统来说，用户研究的价值并没有降低，只是研究对象不能停留在“用户想要什么”。先理解角色、规则和流程，再观察真实工作中的阻碍，通常比直接收集功能清单更容易得到能够真正落地的需求。

参考资料

1. 业务系统用户与业务规则相关文章

2. NIST基于角色的访问控制模型说明