编辑导语：B端产品相比于C端产品，更为复杂。如何设计好复杂的系统更是让不少设计师为之头痛。本文作者根据自己的工作经历，和大家分享自己在产品设计过程中的一些思考。感兴趣的朋友一起来看看吧。

做过B端产品的同学应该都有比较深刻的感受，B端产品不同于C端产品，牵涉的业务流程繁琐复杂、用户角色多，且不同角色之间所关注的点不一样，导致对于同一个系统或者业务流程，描述不一样需求也不一样。

而对于复杂的B端系统来说，我们要怎么样从前期需求获取、业务梳理、原型设计来完成整个产品的思考和设计。

下面我用最近一个由我主导落地的与司法鉴定相关项目为基础，用实例和大家分享一下我在产品设计中的思考。

一、充分调研

产品经理工作职责最重要的部分是通过发现问题、提出解决方案、验证问题，以此来满足用户需求。

我国将司法鉴定分为四大类，包括法医鉴定、物证类、声像资料类、环境损坏类。

四大分类互不相干跨度非常大，每一大类都有独有的流程或要求。

而这四大类下又分为18子类，每个子类下又分别有很多分领域，比如“声像资料类鉴定”分为“录音鉴定、图像鉴定、电子数据鉴定”这三个子类。

“电子数据鉴定”又分为“电子数据真实性鉴定”、“电子数据功能性鉴定”、“电子数据存证性鉴定”、“电子数据相似性鉴定”。

面对这种同一行业但具有不同分领域的情况，我们最应该做的不是第一时间和用户方沟通，考虑到司法行业的特殊性，需要按照严格的规章制度来开展业务，不同领域的用户需求是有差异的。

我选择首先通过阅读了解包括《司法鉴定通则》、《司法鉴定执业规范》等章程性文件，作为调研准备的第一步，以此希望能够对司法鉴定有概括性的认识，同时也希望能够在不同业务领域中找到共同点。

比如在通用的鉴定流程就包括：

收案登记->受理审核->鉴定实施/补充材料/不予受理->鉴定实施->鉴定复核->鉴定审核（签发）->文书生成->归档。

这就是所有领域司法鉴定的通用流程。

在对整个司法鉴定行业有了整体性、概括性认识后，再去出去和用户沟通，具有一定行业知识储备后，后续的沟通才会更加顺畅。

我们的用户包括司法鉴定的主管部门（也就是司法局），四大类司法鉴定领域的用户，包括机构负责人、鉴定人、鉴定助理、收案登记员、司法鉴定委托人等。

在与用户沟通时，我更多的处于“多听少说”的状态，因为他们是这个行业的专业人员，也是未来系统的真实用户，他们更加了解自己的行业、岗位，也是最知道自己需求的人。

对于不太善于描述需求的用户，我们需要以提问的方式来引导用户，通过“人、事、时间、地点”四要素来描述真实的业务场景和切实痛点。

比如其中一个场景需求痛点就是“鉴定助理（人）在鉴定人完成司法鉴定后（时间），需要在档案管理室（地点）对案件的检材、过程资料等进行归档（事），但是司法鉴定的周期长，涉及的资料文件多，在归档的时候难免出现遗漏或文件丢失的情况。”

通过前期的充分学习知识、用户沟通，我们才能地从理解行业知识、业务需求，为我们后期梳理业务流程、角色、架构设计、原型设计夯实基础。

二、业务聚焦

我们在做产品的时候，最忌讳在最初就贪图大而全。

B端业务本身业务流程复杂、涉及角色多，如果一开始就奔着满足所有用户需求的目标设计、实现，往往会出现一下问题：

• 大而全的版本设计周期、开发周期较长，公司的时间成本、金钱成本高；
• 大而全的版本对于用户来说学习成本、使用成本较高；
• 若后续需要改动，需要配合改动的子板块较多，改动起来非常麻烦；
• 市场机会稍纵即逝，太长的研发周期可能会错过一些机会。

我们需要聚焦在用户的主线业务、主要需求，以及公司希望在这个场景上希望做出的创新点、优势上，不要陷入什么需求都可以满足的陷阱中，在资源有限的情况下我们需要做出取舍。

在上图中我列出了司法鉴定的通用流程，我将其作为最小可行产品的业务流程。

司法鉴定过程中不同人需求不同。

比如主管部门能够实时了解管辖范围内鉴定机构鉴定情况、鉴定人希望能够通过系统减少重复操作、收案登记员希望能够更快更好地完成归档认为等等。

且整个司法鉴定流程中所涉及的操作、文书附件不计其数。

但部分操作和文书在实际业务过程中使用到的次数较小，所以在最开始梳理业务流程的时候，我选择性的忽略。

其次由于在这个行业已经有类似竞品，我通过使用分析后，了解到他们更多地将系统聚焦在日常的鉴定过程中。

而近年来随着司法行业大整顿，各大司法机构需要进行重新评审，评审的内容主要是对鉴定文书等资料进行检查、考核，对平日里对文书不重视的机构，面对这样严格的评审往往会出现应接不暇的情况，可能会被停业整顿，甚至吊销执照。

所以我们在解决通用业务流程的基础上，将系统进一步聚焦在“文书评查”板块，也作为我们产品的一大亮点。

最后如果在业务聚焦时团队内部举棋不定，可以选择最简单的方式，选择优先聚焦在“买单用户”的需求上进行设计实现。

类似钉钉的“买单用户”是老板，实际使用用户是员工，老板最大的需求就是能够实时监督员工、管理员工，以更高效的方式完成工作，所以也才有了钉钉最开始的版本。

三、主线流程和角色梳理

在B端业务中，完成一项任务问题需要执行很多操作，但并非所有的操作都是主线业务流程和关键节点。

我认为主线业务流程是完成任务的最短路径，最短路径中的操作就是关键节点，操作是由人完成的，所以关键节点上的人就是关键角色。

比如司法鉴定的主线流程和节点包括：

前期技术服务（预检）——>受理审批——>鉴定实施——>文书出具——>鉴定收尾。

其中涉及到的角色包括收案登记员、鉴定助理、司法鉴定、技术负责人，不同的业务流程由不同的角色参与并完成任务。

我们以上我们通过”人+事“的方式，梳理主线流程和关键角色是为了大致了解不同角色职责与执行任务顺序，进而抽象出业务规则和流程。但这样的结果还是非常粗旷，不足以作为我们产品涉及的依据，我们需要进一步梳理。

四、业务流程细化

一条主线业务往往会有很多分支任务，这些任务也是完成主线业务的必要条件，所以我们还需要进一步细化主线业务；其次每一次操作必定伴随着信息的输入和输出，所以我们还需搞清楚完成操作的前提条件和产出数据；最后在主线业务流程外，还有很多异常流程也需要我们注意。

比如上图是对审查受理阶段进行了细化，在流程上审查受理又需要分为”收案登记“、”初始审核“、”审批受理“、”办理手续“四个步骤，同时可以看到我在表格中添加了另外三列，包括输出文书、必要程度以及备注。上一个操作的输入作为下一个操作的输入，每个步骤的逻辑顺序是不可改变的；”必要“操作是主线业务的进一步细化，”可能“操作”是异常情况的标注。备注里是一些补充说明。

以这样的方式我们就把复杂的业务通过“时间顺序”对应”事“，”事“对应”人“，”人“对应”操作“、”操作“对应”输出“的逻辑梳理出来，这样能够更加清晰把握业务脉络。

五、产品功能架构设计

产品功能架构是对业务流程和操作的抽象成功能板块，主线业务梳理（总）——>业务流程及角色细化（分）——>产品功能框架设计（总），我们距离产品原型设计，就只差一步了。

其实在前面的流程梳理过程中，根据”人+事+逻辑顺序“的方式产品框架已经显露出来了，再加上一个完整业务系统的常见功能就组成了我们的产品框架。

六、结语

业务是单纯的，其本质就是为解决问题，但人往往是复杂的，在不了解事情本质的情况下容易将简单问题复杂化。

产品经理是否厉害不在于把系统设计得多么复杂、多么高大上，而在于能够以最简单的方式解决用户需求。

大道至简，繁在人心。

本文由@蹦蹦怪 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于CC0协议。