沐鸣平台首页_全面了解 B 端产品设计：如何理解需求？
在上一篇《全面了解 B 端产品设计：基础扫盲篇》内容中，我们已经知道，B 端的设计难点不在于精美的外观和复杂的设计，而是要符合产品的实际需求，并有效提升业务运营的效率。
那么对于 B 端设计师最大的挑战其实是理解需求。
只有对需求有清晰地认识，我们才能定位要通过设计解决的问题，为给出正确的设计提供条件。如果对需求的认识是模糊或是错误的，那无论你怎么努力都只能做出错误的设计，而且会有大量的反稿，浪费团队的时间。
所以本篇内容，就和大家谈谈，我们该如何理解 B 端需求。
在 B 端的项目中，设计师主要的需求来源是产品经理的需求文档或者原型，当然，在一些特殊的情况下，可能是老板或者客户的口头描述。
但无论什么形式，B 端产品的需求，是由业务的需求衍化而来。例如，在一个电商平台，本来只销售服饰类产品，但随着业务的发展，引入了新的鞋靴品类，那么原本的产品创建流程就需要调整，比如增加下列需求：
- 创建过程增加品类选择，方便数据库分类和筛选操作；
- 选择鞋靴品类后使用于服装不同的商品属性，尺码由字母改成数字；
- 创建鞋靴的客服专员角色，并分配对应权限和接口；
- ……
所以，B 端产品的需求，是因为业务上有需要，所以才制定，而不是产品经理凭空想象，觉得这个功能很厉害，用户一定会喜欢就直接做上去。
那么对于商业一窍不通的设计师，该怎么分析和产品需求相关的公司业务呢？可以通过以下的步骤来解决：
对于企业日常的运作，每一条业务线都需要消耗人力成本，形成支出，所以在制定时，我们对它的预期就应该是能为企业带来收益，虽然有时候这种收益不是直接的盈利。
我们第一步要做的，就是先撇开所有业务有关的细节部分，去发现它所要达成的目标和预期。比如，前面提到的新增一条产品线，目标就是为了扩大销售品类满足顾客的需求，增加营收。
当然，一些比较大的目标，理解起来很容易，看起来也很清晰，但只得出这个结论对业务的理解是远远不够的。无论是企业还是个人，一个远大的目标，都要由若干小目标所组成，即实现这个结果的条件。所以，我们还需要去找出实现这个目标所要达成的其它目标。
这就是一个比较艰难的任务，因为它涉及诸多商业问题。所以，要明白一点，多数时候光靠自己的思考是得不出答案的，我们该做的是去请教了解或者熟悉这个业务的同事，一定要有目的性主动去了解，而不是等待别人一条条和你说明。
然后，我们就要把获得的结论用笔记或思维导图软件串联起来，分析这个业务目标的完整性，比如下图：
这是一个我简化后的业务目标拆分，在真实的项目里往往比它更复杂，且我们可以针对一些非常重要的二级目标再进一步拆分，这就要根据大家对业务的判断来进行了。
做好了这些内容，就能对当前产品有关的业务内容，有一个清晰的认识，即使是你完全没有接触过的行业也可以用这样的方法获得宏观上的认识。
接着，我们要做的，就要把目光从概念落实到实处，即公司在实现这些目标时的具体执行方式。
可能有同学接触过产品流程图，业务流程图和它比较像，即实现目标结果所要进行的一系列实践，但不同于产品流程的特点是，业务流程的执行过程更「线性」，不需要表现出太多的布尔和循环。
比如我们对能正确选品展开分析，那么在整个确定选片的链条中，它的执行步骤如下：
同理，我们也可以以这样的方式画出其它目标的流程图。之所以我们不把整个业务流程在一幅图中画出来，这是因为包含的步骤太多会导致流程图可看性极差，且不同的目标执行并不一定具有强关联性或先后顺序，所以拆分才更合理。
掌握这部分内容是至关重要的，因为未来我们在理解产品具体的需求和制定交互流程的时候，都要与业务流程进行关联。
还要注意的是，如果时间不够，绘制和维护这些图形又需要大量时间，那么我建议使用类似 MarkDown 之类的笔记工具直接记录，提升效率，不要被「图形」的字眼给束缚住。
所有业务的实践，除了一些自动化的器械和程序以外，主体都是人。但人会被分配到不同的岗位，不同的权限和责任，所以我们能参与业务的所有成员定义出「角色」的分类。
例如，在前面的流程案例中，确认选品到筛选目标商品的执行，都由商品运营人员处理，到了评审阶段，就会涉及到市场、总监、老板等其它角色，提交采购订单还涉及到财务，最后验收入库由仓管完成。
我们不仅要找出角色对应到业务流程的事件，还要确定他们在这个事件中发挥的作用。在我过去的制作习惯中，会喜欢将角色做成一个标示符号，然后对应添加到流程图中，并进行对应标注，如下图所示：
这种方法可以进一步降低整理材料的复杂性，能让我们轻易看懂，即使在团队内部讨论的时候也方便分享。
最后，就是对我们已经做完的内容进行总结了。在这里，我们要找出的优缺点，不是像职业经理人一样去优化业务流程的反思，这不仅超出了我们的职责范畴，也不是设计师的眼界和经验能够体会的。
虽然说要找出的是优缺点，但实际我们要做的是发现当前流程体系内的问题。
那么什么是流程的缺点？这点除了我们自己的想象以外，还必须主动去观察和沟通，每个事件的相关角色对当前遇到的问题感受是最清晰的，我们需要通过咨询他们来最终完善所有结论。
比如，商品运营分析用户评价的时候，当前的后台评价列表缺少筛选功能也不能导出 Excel，结果需要依靠翻页手动记录，非常耗费时间，那么这个缺点就会演变成为产品的需求之一。
这样，我们就可以把业务中出现明显问题的步骤进行标注，同样是通过在流程图上标注完成。
当然，很多时候我们获得的产品需求中，就会包含对于业务问题的分析，我们也需要将它们直接和业务流程关联起来，具体处理的位置在哪里，有哪些角色参与其中。
完成这一步以后，我们对业务的认识就会有质的改变。这时候，我们就可以用自己的角度去判断，当前产品给我们的需求是否符合实际的需要，接下来我们要做的交互和设计，到底是在解决什么样的问题，对整体的目标实现，有什么样的帮助。
虽然这些内容看起来很麻烦，但是只要自己尝试做一次，就一定会获益匪浅。
尤其是对于完全不了解当前产品解决问题和公司业务内容，只知道跟着产品的原型图画图的设计师来说，我相信你们尝试执行一次以后，就不会再对自己当前的工作感到迷茫。
欢迎关注作者的微信公众号：「超人的电话亭」
