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

用例是指用户在系统中执行的一系列动作，通常用「动词+名词」的方式表达。值得注意的是，用例是有目标的，它能够为参与者带来有意义的结果，例如「填写搜索房屋条件」显然对于参与者来说没有任何意义，就不是一个合适的用例。

另外用例是对一组使用场景的抽象。用例与场景之间的关系像是计算机概念中，类与对象之间的关系。一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。

例如我们在系统上找房源的时候，可能会遇到很多场景：使用搜索框直接搜索心仪房源、根据筛选条件挑选房源、根据推荐的新盘挑选房源、拉取两三个房源对比后挑选等等，不管有多少种情况，只要是在做挑选房源这件事，那么这些场景在系统中，都可以概括为一个「挑选房源」的用例。

在传统的结构化分析与设计方法中，对事物的分析视角都是站在解决方案层面思考的，即这个系统需要有什么，从系统的角度出发做功能规划。这样做出来的产品，常常有用户抱怨太难用，很难理解系统的意思，也不知道从哪里去找需要的功能。

而以「用户故事」驱动的需求分析方法，是一种更侧重于「从用户的角度出发，将系统当做一个黑盒子」的视角，这种方法能够有效解决上述问题。

从另外一个角度来说，用户故事的关键点在于发现使用系统的用户，了解并梳理这些用户如何使用系统，从而达到「以人为本」的需求分析。

B 端产品怎么找用例?又如何把用例找「全」呢?这是一个经常困扰产品经理的问题。

实际上，我们可以从针对各个业务事件处理过程的流程图中得到用例。正如前文所述，流程图是我们与企业中层管理人员沟通后得到的产物。只要有针对各个业务事件处理过程的流程图，我们就可以从中导出相应的用例。

跨职能流程图对应的不同岗位是可能产生用例的参与者，再加上他们所负责的事情，就是完整的业务用例。也就是我们的客户完成一项业务需要做的所有事情。但是我们做一款产品，很多时候不能满足客户的所有业务环节，只能挑选与我们产品相匹配的核心场景的业务链条深入分析。

因此，对于我们来说，本阶段挑选的业务用例实际上就是系统用例。而系统用例的判断要点在于该用例「是否属于系统范围」，以及他们所做的这个事情能否产生业务价值，只要满足这两个条件的所有用例都必须记录下来。这样一来，我们就能够得到完整的系统用例。

有的读者可能会问：用例分析要分析到什么地步才能结束?

笔者的建议是不要追求完美，只要感觉已经把客户的业务都弄清楚就可以考虑结束，而不必等到事无巨细的每件事都梳理完整。

面对一个陌生的领域，一个经历了多年发展变化的业务流程，要在短时间内弄清楚的确是一个不小的挑战。用例分析的意义在于帮助产品经理在短时间内从结构、整体上了解业务构成。用例是比较高层次的业务抽象，更容易被人们理解和接受。所以进行这一项工作，只需要感觉到业务的整体信息已经可以掌握，就可以考虑停止更广泛的用例获取。以现有的用例作为基线，进行接下来的工作。产品不断迭代的前提就是建立在用例不断优化、不断调整的过程中。

在客户调研的时候，经常看到产品经理傻里傻气地问客户：你对这个产品有什么需求或者有想法吗?但不管用户怎么回答，似乎都很难让我们满意。客户提不出需求，你会觉得我们的客户对这事好像也没那么上心。更多的时候是客户提的需求都是不痛不痒，或者你感觉极具个性化，让你感觉做也不是，不做也不是。

和 C 端场景一样，B 端场景中的用户需求也像是一个冰山，有很大一部分信息是埋藏在海平面之下，这就对需求调研工作带来很大的困扰。主要的需求分为三种：

• 意识到的需求：这是在海平面以上的需求，通常是一些困扰用户的问题，或者是用户自己能想到的功能。大部分产品经理在调研过程中获取到的都是这一类需求;
• 无意识的需求：它是用户在实际工作场景中「没有意识到是问题」的问题，这种问题需要产品经理对业务有一定的理解才能够发现。如果对这些场景能做到「感同身受」的话，相信在产品规划的过程中能够设计出更合理、高效的方案;
• 进一步的需求：调研的用户毕竟不是技术专家，只是普通的业务人员，因此他们没有办法对其工作提出产生变革的解决方案。因此需要产品经理对问题充分理解的前提下，选择合适的实现方式以创造出用户未想到的功能。

在设计这款针对房产中介的 CRM 产品时，业务员反馈他们在客户选房的时候，需要将不同房源的信息发送给客户。于是产品经理听完后，在房源列表中，每一条房源的操作按钮区域增加了一个分享按钮。

满心欢喜地给到业务员时，业务员说这功能不实用，因为没办法把多个房源的信息合并在一起发给客户。但是产品经理认为，你可以一条一条发给客户呀，所以产品的设计还是能满足业务需要的，但业务员希望得到的是多个房源信息合并后，摘出关键信息发给客户比对，而不仅仅是展示每个房源的信息。

这个场景就是只发现意识到的需求，而没有深究以及进一步分析的结果。

实际上 B 端产品的需求获取并不难，难的是与用户交流沟通的过程。因为我们的用户仅仅作为一个使用者，他只是站在自身使用的视角，想让自己的工作方便一些或是在利益分配上对自己更有利，很难站在系统规划的角度考虑全面整体的东西。

遇到这种情况，最有效的应对策略是需求分析从流程入手，搞清楚业务活动在平时是如何开展的，再逐步过渡到存在什么样的障碍，有什么困难等等。在这个过程中，多问几个为什么，多思考客户诉求背后代表的心理状态与利益冲突。

所以这一阶段，我们主要做的工作是收集针对业务活动的问题点、需求点。这时候我们获取到的是原始的用户需求。

（编辑：核心网）

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