只有对需求有清晰地认识，我们才能定位要通过设计解决的问题，为给出正确的设计提供条件。如果对需求的认识是模糊或是错误的，那无论你怎么努力都只能做出错误的设计，而且会有大量的反稿，浪费团队的时间。

用户需要什么样的产品呢，形形色色的用户并不会记得自己说过的所有话，他们只会记得他们想要的，而不想要的都是产品设计人员强加的，用户需要的产品一定是能解决某个具体问题的产品。

用户按照使用熟练度的维度可以分为专家型用户、随意性用户、主流用户。

第一类不用说一般是技术狂热者，他们舍得花时间研究新产品，探索产品的新功能，他们愿意畅所欲言，对如何改进当前产品固执己见，但他们不是典型用户，他们的判断会出现偏差；他们不会体验到主流用户遇到的问题，可能总对会飞的汽车感兴趣。

第二类是随意性用户，他们可能使用过类似的产品或服务，他们有兴趣使用更高级更复杂的产品，但却不愿意接触全新的东西，要想让他们认可新功能，那么新功能必须足够简单。

第三类用户是主流用户，他们自己不会因为你的技术而使用你的产品，使用你产品的目的是完成某项任务。他们会掌握一些重要功能的使用方法，但永远不会产生学会所有功能的想法。

这些人的口头禅就是：“只要能打电话、能发短信就行了”。

大多数人属于这一类，以前总是觉得用户使用产品一段时间后就会转变为资深用户进而成为专家，后来发现完全不是这样，和使用时间的关系不大，就像同事每天从同一个地铁站进入的A口进站，但是有一天你问他A口有没有厕所时，他说没注意到过，即不知道。

正如Giles Colborne 所说个人对产品的态度与他们在使用产品或服务上花费的时间相比，前者对他们的影响更大。

很多时候用户其实没法说清楚，也可能无法描述出问题的根本，说了很多现象与场景，复杂的根源需要产品人员去探索，用户要买的其实不是某个产品，而是他们需要运用一个产品来完成某种任务或解决某个问题。但产品又不是直接由用户去生产的，用户可能只会说“我要一匹更快的马”或“我要一辆跑的更快的马车”，产品人员却需要透过表层去理解、不断的问为什么，直到把用户的真实需求理解。

如果失去思考，那么软件就会被用户牵着走，如“这里为什么没有打印，我们经常要打印呀”，“这里为什么没有合计呀，我们还要用excel再计算一次”，“这里为什么不支持全部导出呀，我还要一页页的选”，渐渐的功能不断增多，软件会变的臃肿，甚至连按钮都没有地点放，就像那个古老而复杂的遥控器的按钮一样，页面上到处是各种各样的操作按钮，使用者最终也会发现每次要做一件事时都要思考该点击哪个按钮。

而且B 端的设计难点不在于精美的外观和复杂的设计，而是要符合产品的实际需求，并有效提升业务运营的效率。

那么对于 B 端产品人员最大的挑战其实是理解需求。

只有对需求有清晰地认识，我们才能定位要通过设计解决的问题，为给出正确的设计提供条件。如果对需求的认识是模糊或是错误的，那无论你怎么努力都只能做出错误的设计，而且会有大量的反稿，浪费团队的时间。

认识业务需求

在 B 端的项目中，需求来源是市场人员与客户的反馈、相关部门的业务场景。当然，在一些特殊的情况下，可能是老板或者客户的口头描述。

但无论什么形式，B 端产品的需求，是由业务的需求衍化而来。例如，在一个电商平台，本来只销售服饰类产品，但随着业务的发展，引入了新的鞋靴品类，那么原本的产品创建流程就需要调整，比如增加下列需求：

• 创建过程增加品类选择，方便数据库分类和筛选操作；
• 选择鞋靴品类后使用于服装不同的商品属性，尺码由字母改成数字；
• 创建鞋靴的客服专员角色，并分配对应权限和接口；
• ……

所以，B 端产品的需求，是因为业务上有需要，所以才制定，而不是产品经理凭空想象，觉得这个功能很厉害，用户一定会喜欢就直接做上去。

那么对于商业一窍不通的设计师，该怎么分析和产品需求相关的公司业务呢？可以通过以下的步骤来解决：

确定业务目标

对于企业日常的运作，每一条业务线都需要消耗人力成本，形成支出，所以在制定时，我们对它的预期就应该是能为企业带来收益，虽然有时候这种收益不是直接的盈利。

我们第一步要做的，就是先撇开所有业务有关的细节部分，去发现它所要达成的目标和预期。比如：前面提到的新增一条产品线，目标就是为了扩大销售品类满足顾客的需求，增加营收。

当然，一些比较大的目标，理解起来很容易，看起来也很清晰，但只得出这个结论对业务的理解是远远不够的。无论是企业还是个人，一个远大的目标，都要由若干小目标所组成，即实现这个结果的条件。所以，我们还需要去找出实现这个目标所要达成的其它目标。

这就是一个比较艰难的任务，因为它涉及诸多商业问题。所以，要明白一点，多数时候光靠自己的思考是得不出答案的，我们该做的是去请教了解或者熟悉这个业务的同事，一定要有目的性主动去了解，而不是等待别人一条条和你说明。

然后，我们就要把获得的结论用笔记或思维导图软件串联起来，分析这个业务目标的完整性，比如下图：

这是一个我简化后的业务目标拆分，在真实的项目里往往比它更复杂，且我们可以针对一些非常重要的二级目标再进一步拆分，这就要根据大家对业务的判断来进行了。

做好了这些内容，就能对当前产品有关的业务内容，有一个清晰的认识，即使是你完全没有接触过的行业也可以用这样的方法获得宏观上的认识。

绘制业务流程图

接着，我们要做的，就要把目光从概念落实到实处，即公司在实现这些目标时的具体执行方式。

可能有同学接触过产品流程图，业务流程图和它比较像，即实现目标结果所要进行的一系列实践，但不同于产品流程的特点是，业务流程的执行过程更「线性」，不需要表现出太多的布尔和循环。

比如我们对能正确选品展开分析，那么在整个确定选片的链条中，它的执行步骤如下：

同理，我们也可以以这样的方式画出其它目标的流程图。之所以我们不把整个业务流程在一幅图中画出来，这是因为包含的步骤太多会导致流程图可看性极差，且不同的目标执行并不一定具有强关联性或先后顺序，所以拆分才更合理。

掌握这部分内容是至关重要的，因为未来我们在理解产品具体的需求和制定交互流程的时候，都要与业务流程进行关联。

还要注意的是，如果时间不够，绘制和维护这些图形又需要大量时间，那么我建议使用类似 MarkDown 之类的笔记工具直接记录，提升效率，不要被「图形」的字眼给束缚住。

总结角色职能

所有业务的实践，除了一些自动化的器械和程序以外，主体都是人。但人会被分配到不同的岗位，不同的权限和责任，所以我们能参与业务的所有成员定义出「角色」的分类。

例如，在前面的流程案例中，确认选品到筛选目标商品的执行，都由商品运营人员处理，到了评审阶段，就会涉及到市场、总监、老板等其它角色，提交采购订单还涉及到财务，最后验收入库由仓管完成。

我们不仅要找出角色对应到业务流程的事件，还要确定他们在这个事件中发挥的作用。在我过去的制作习惯中，会喜欢将角色做成一个标示符号，然后对应添加到流程图中，并进行对应标注，如下图所示：

这种方法可以进一步降低整理材料的复杂性，能让我们轻易看懂，即使在团队内部讨论的时候也方便分享。

找出优缺点

最后，就是对我们已经做完的内容进行总结了。在这里，我们要找出的优缺点，不是像职业经理人一样去优化业务流程的反思，这不仅超出了我们的职责范畴，也不是设计师的眼界和经验能够体会的。

虽然说要找出的是优缺点，但实际我们要做的是发现当前流程体系内的问题。

那么什么是流程的缺点？这点除了我们自己的想象以外，还必须主动去观察和沟通，每个事件的相关角色对当前遇到的问题感受是最清晰的，我们需要通过咨询他们来最终完善所有结论。

比如，商品运营分析用户评价的时候，当前的后台评价列表缺少筛选功能也不能导出 Excel，结果需要依靠翻页手动记录，非常耗费时间，那么这个缺点就会演变成为产品的需求之一。

这样，我们就可以把业务中出现明显问题的步骤进行标注，同样是通过在流程图上标注完成。

当然，很多时候我们获得的产品需求中，就会包含对于业务问题的分析，我们也需要将它们直接和业务流程关联起来，具体处理的位置在哪里，有哪些角色参与其中。

完成这一步以后，我们对业务的认识就会有质的改变。这时候，我们就可以用自己的角度去判断，当前产品给我们的需求是否符合实际的需要，接下来我们要做的交互和设计，到底是在解决什么样的问题，对整体的目标实现，有什么样的帮助。

总结

虽然这些内容看起来很麻烦，但是只要自己尝试做一次，就一定会获益匪浅。

尤其是对于完全不了解当前产品解决问题和公司业务内容，被用户牵着走的时候，我相信你们尝试执行一次以后，就不会再对自己当前的工作感到迷茫。

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

题图来自Unsplash，基于CC0协议