如何做系统(电脑一键安装win7系统)

编辑导语:B端产品比C端产品复杂。如何设计一个复杂的系统是很多设计师头疼的问题。笔者结合自己的工作经验，分享一些产品设计过程中的思考。有兴趣的朋友来看看吧。

做过B端产品的同学应该深有感触。b端产品不同于C端产品，涉及复杂的业务流程和用户的众多角色，不同角色关注点不同，导致对同一系统或业务流程的描述不同，需求也不同。

对于复杂的B端系统，我们如何从前期需求获取、业务梳理、原型设计等方面来思考和设计整个产品？

下面，基于我最近牵头的一个法医鉴定相关的项目，用实例和大家分享一下我对产品设计的思考。

一、充分调研

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

我国司法鉴定分为四大类，包括法医鉴定、物证、视听资料、环境损害。

这四个类别相互独立，每个类别都有自己的过程或需求。

这四大类又分为18个子类，每个子类又有很多子领域。如“视听资料鉴定”分为“录音鉴定、图像鉴定、电子资料鉴定”三个子类。

电子数据认证可分为真实性认证、功能性认证、存储性认证和相似性认证。

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

我选择阅读公司章程，包括《司法鉴定通则》和《司法鉴定执业标准》，作为研究准备的第一步，从而对司法鉴定有一个大致的了解，找到不同业务领域的共同点。

例如，一般评估流程包括:

受理登记->:受理->:执行/补充材料/驳回->:执行->:评估审核->:评估(签发)->:文件生成->:归档。

这是所有领域司法鉴定的一般流程。

对整个法医行业有一个整体的、大概的了解后，走出去和用户交流，有一定的行业知识储备，后续的沟通会更顺畅。

我们的用户包括司法鉴定的主管部门(即司法局)，司法鉴定领域的四类用户，包括机构负责人、鉴定人、鉴定助理、案件登记员、司法鉴定委托人。

在和用户交流的时候，我更多的是一种“多听少说”的状态，因为他们是这个行业的专业人士，是未来系统的真正用户。他们更了解自己的行业和岗位，也是最了解自己需求的人。

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

比如，现场需求的痛点之一是“鉴定人完成司法鉴定(次)后，鉴定辅助人(人)需要将案件的审查材料、过程资料归档到档案管理室(处)，但司法鉴定的周期较长，涉及的资料、文件较多，归档时难免出现遗漏或丢失文件的情况。”

通过前期充分的知识学习和与用户的交流，可以有效的了解行业知识和业务需求，为我们后期梳理业务流程、角色、架构设计、原型设计打下坚实的基础。

二、业务聚焦

我们在做产品的时候，最怕一开始就贪图大而全的产品。

B端业务本身业务流程复杂，涉及角色多。如果它的设计和实现从一开始就满足所有用户的需求，那么经常会出现一些问题:

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

我们需要关注用户的主营业务和主要需求，以及公司希望在这个场景下做出的创新和优势，不要陷入任何需求都可以满足的陷阱。当资源有限时，我们需要做出取舍。

在上图中，我列出了法医鉴定的一般流程，我认为是最小可行产品的业务流程。

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

比如主管部门可以实时了解辖区内鉴定机构的鉴定情况，鉴定人希望通过系统减少重复操作，受理登记人希望更快更好地完成备案，等等。

而且整个司法鉴定过程涉及的操作和文书附件不计其数。

但有些操作和单据在实际业务流程中使用频率较低，所以在梳理业务流程之初，我选择性地忽略了它们。

其次，因为这个行业已经有类似的竞品了，我知道他们通过对使用情况的分析，更侧重于日常的识别过程。

近年来，随着司法行业的大重组，各大司法机构需要进行重新评估。评估的内容主要是检查和评估身份证明文件和其他材料。对于那些平日里不重视文件的机构来说，面对如此严格的评估，往往会不知所措，可能会被停业整顿甚至吊销执照。

因此，我们在解决一般业务流程的基础上，进一步将系统的重点放在“文档评估”部分，这也是我们产品的一大亮点。

最终，如果团队在专注业务时举棋不定，可以选择最简单的方式，优先专注于“付费客户”的需求进行设计和实现。

类似的“付费用户”是老板，实际用户是员工。老板最大的需求是能够实时监督管理员工，以更高效的方式完成工作，于是有了钉钉的初始版本。

三、主线流程和角色梳理

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

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

例如，司法鉴定的主要流程和节点包括:

技术前期服务(预览)->:验收->:实施->:签发文件->:鉴定结束。

所涉及的角色包括案件登记员、鉴定助理、司法鉴定和技术主管。不同的业务流程涉及不同的角色和完成的任务。

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

四、业务流程细化

一个主线业务往往有很多分支任务，而这些任务也是完成主线业务的必要条件，所以我们需要进一步细化主线业务；其次，每一个操作都必须伴随着信息的输入和输出，所以我们还是需要找出前提条件和输出数据来完成操作；最后，除了主要业务流程之外，还有很多异常流程需要我们关注。

例如，上图详细描述了检查和验收阶段。在流程上，审批需要分为立案受理登记、初审、审批受理、办理手续四个步骤。同时，你可以看到我在表中增加了另外三列，包括输出文档、必要程度和备注。前一个操作的输入作为下一个操作的输入，每一步的逻辑顺序不变；“必要的”操作是对主线业务的进一步细化，“可能的”操作是对异常情况的注解。备注里有一些补充说明。

这样就可以通过“事件对应时序”、“事件对应人”、“人对应运营”、“运营对应产出”的逻辑来梳理复杂的业务，从而更清晰地把握业务脉络。

五、产品功能架构设计

产品功能架构(Product functional architecture)是对业务流程和运营的抽象功能块，业务主线梳理(总)->:业务流程和角色细化(分)->:产品功能框架设计(总)，我们离产品原型设计只有一步之遥。

其实在之前的流程梳理中，已经按照“人+物+逻辑顺序”的方式揭示了产品框架，一个完整的业务系统的共同功能构成了我们的产品框架。

不及物动词结论生意很简单，本质是解决问题，但人往往很复杂，不了解事物本质很容易把简单的问题复杂化。

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

简单的道路在人们心中是无数的。

本文由@弹跳怪兽原创发布。每个人都是产品经理。未经许可，禁止复制。

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