万字长文！超全面的B端产品设计指南

其实从不同角度来看一个业务流的时候，可能会有很多不同的流程。流程会有大小之分，主流程中可能会有子流程等，因此流程分析是一项庞大的工程，仅仅通过文字将流程描述清楚是很困难的，我们需要系统化地分析，因此可以借助「跨职责流程图」帮助我们梳理脉络。

跨职责流程图是商业分析的标准工具，它定义了一套标准的建模元素与分析方法，下图展示了房产中介卖房时的流程。

看到这张图，也许很多读者会很疑惑：这张图也太简单了吧。谈判议价以及办理过户手续都涉及许多业务性的判断，为什么在图中都不体现呢?

这是因为它们属于细节层次，在本阶段判断的原则是：不会影响其他泳道的流程，在这个阶段都不需要表现出来。在这个场景中，谈判议价虽然复杂，但是它的判断流程并不会对其他泳道产生影响，因此我们可以暂时不看。

2. 角色与使用场景分析

不少读者会有这样的疑惑，我做 B 端的产品，把流程梳理完了就能知道需要设计什么功能点来描述需求了，为什么还要去分析角色与使用场景呢?对于一个 B 端产品来说，用户在使用的过程中应该是无差别的，我们硬是把这些用户分成不同的角色那不是多此一举吗?

确实，我刚开始接触 B 端产品时也是相同的想法。直到有一次，一位朋友给我描述他们的产品。

「我们这款产品是一个征收系统，给政府人员管理征收流程用的。这个产品包含填写测算表、选择安置房、选择赔偿标准、查看签订合约人数等等功能，填写测算表里又分为了某某模块……」

当时确实是把我听懵了。随后我问了他两个问题：

• 这个系统到底有谁在用?
• 这个系统帮助这些人解决什么问题，怎么解决?

问完之后我马上意识到，这两个问题不就是典型的用例分析方法吗?

用户故事是指某种类型的用户为了完成某特定目标所执行的一系列操作。在描述层面我们可以暂时忽略业务目标，因此一条用户故事包含两个元素。

参与者

参与者是指在系统之外，这个流程中与系统进行有意义交互的任何事物。参与者不仅可以由人来承担，也可以是其他系统或者是硬件设备。

例如在看房的过程中，业务员从后台系统调取房屋的平面图以及详细信息，这时候后台系统就是其中一个参与者。如果我们的新房还没有装修好，用 VR 眼镜让客户看到装修后的效果时，VR 眼镜也是流程中的参与者。参与者是一种角色，而不是一个特定的人，在某些场景中甚至一个人能够充当多个角色。

做什么事情(用例)

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!