B端产品设计师如何做好需求对接和管理

本文就自己和他人的一些真实经历，总结下近期关于B端产品设计的一些思考，记录下来分享给大家。

主要内容包括：

• 产品设计师困境
• 需求收敛能力
• 对上汇报技巧

#01 产品设计师困境

1、业务层面

B端产品具有天然的复杂性，特别是数据管理类的产品，非技术出身的产品设计师会承受很大的业务压力。比如我现在正在做的API、网关等，想要完全搞懂业务逻辑面临着很大的困难。

目前我没有找到好的解决办法，只能通过主动学习、主动沟通，弥补业务层面的劣势。一方面需要不断地向技术人员取经，另一方面要去研究竞品，在实战中逐步成长。当然在沟通中要注意一定的技巧：

1）适当放低姿态

既然是向别人学习，就不能红口白牙，两手空空地直接请教。需要事先了解一些基础知识，带着问题和方案去请教别人。毕竟大家的时间都非常宝贵，别人没有义务去帮助你成长。

2）价值交换

偶尔可以进行一些小的“回报”，感谢下别人的付出。比如一杯奶茶，一瓶饮料等等，让对接过程更加顺畅。

2、用户场景

产品定位是产品设计的最底层原则，决定了产品的设计方向，但是产品定位是由用户场景决定的。

在做B端产品时，熟悉用户场景和工作流程非常重要。有些情况下，对产品设计师而言，这些信息并不容易获取，需要依靠解决方案、售前、交付同事，进行相关信息输入。

在信息不全的情况下，或者挤牙膏式的信息输入，会导致一遍遍的改稿，产品设计师真就就变成“画图仔”了。所以在开始产品设计前，一定要想方设法了解到这些信息。

如果实在没有相关的信息输入，可以通过竞品分析不断求证，引导相关人员给出一些产品信息。

3、工作流程

上下目标对齐才能保证方向的一致性和工作效率，才能有效配置项目中的各种资源，并产生最大价值。

一些传统的公司正处于数字化转型时期，产品设计开发流程并不完善，产品设计师更多地被定义为设计执行层。产品定位或者目标通常是管理层去敲定的，这些信息往往不会主动地传递给产品设计师，或者信息在二次传递过程中发生了扭曲，导致产品信息不准确。

产品设计师在承接任务时，需要融入自我的思考，适当去挖掘和追问更加底层的产品信息，判断需求的价值和合理性。否则产品设计师在汇报方案时，可能会发现设计方案与领导的预期不一致，导致设计工作的返工。比如你接收到的消息是要做一款平台型产品，结果领导只是想要一个简单的工具型产品。

本质上来说，产生困境的根本原因来自于对用户场景理解不到位，由此产生了各种信息理解的偏差。

#02 需求收敛能力

在工作中，你会发现最困难的不是“要做什么”，而是“不要做什么”。在产品需求讨论和评审会上，大家会天马行空地提出各种可能性的需求；项目现场会不断地反馈客户需求；领导会时不时提出几个产品需求。

深究下来，这些需求并不是完全没有道理。是不是要照单全收，一一安排上线呢？

通常需求要基于产品价值和用户价值来进行评判后，再决策是否推动上线。

1、用户价值

从两个方面衡量：

• 解决了用户什么问题？满足了用户什么需求？
• 这类用户是核心用户吗？这个用户需求必须要满足吗？

2、产品价值

从两个方面来衡量：

• 如果做这个需求，能给我带来什么好处？
• 如果不做这个需求，我会有什么损失？

如果产品设计师不能够清晰的理解用户和场景，不能够对需求做出合理分析，就无法做出取舍。

举个最近的案例：

为了管理好各个终端系统，最开始的产品需求是希望由终端用户自主完成系统的认证工作。但是经过分析发现，这样做只是方便后台系统的管理，对用户没有任何价值，反而增加了用户的操作成本，并且在这个过程中可能会产生意想不到的问题，比如错误输入、功能理解偏差等。

如果这项认证工作交给系统实施人员来完成，他们无法获取到其中的部分认证信息，需要与客户二次沟通，也不是最佳方案。

最终我们重新梳理了业务流程，将市场人员纳入到整个流程中，他们是信息流转的发起端，将信息在控制在后台管理系统中，保证了终端系统的用户体验。

另外即使是合理的用户需求，还需要根据产品的发展阶段、公司各类资源的配置，做出优先级排序，制定好迭代策略，控制好版本节奏逐步完成。

#03 对上汇报技巧

产品需求会存在各种不确定性，汇报的目的就是不断地澄清差异、寻求共识。如果是比较大的产品需求设计汇报，最好分阶段完成汇报工作。

产品设计师想要憋个“大招”、一把“梭哈”，准备通过一次完整的设计汇报呈现给领导，其实风险是比较高的。一方面前期的投入会比较大，需要产品和设计师都要参与其中，一旦需求发生变更，带来的返工成本也会比较高。另外如果汇报的信息量太大，领导一时很难消化，汇报的效果也不一定好。需求汇报达不到预期效果，后面的原型设计方案有可能得不到展示的机会。

对于大的业务需求，或者0-1的产品设计，建议可以分为2个阶段：

1）确认产品需求

无论是上级指派的需求，还是产品经理挖掘和推动的需求，都需要有个确认的过程。在这个阶段，关注点要停留在需求本身，通过用户场景、竞品、流程等这些前期分析，将需求梳理清楚，并达成一致是最重要的。

产品设计师可以通过各种分析材料，完整清晰地讲清楚需求内容，获得领导对需求的态度，为后续的方案设计明确方向。

当然也可以辅助快速的线框图，让参会者更好的理解产品页面流程。不过我个人认为这不是必需的内容。

2）确认设计方案

明确产品需求后，后续就可以推进方案设计了。这个阶段要呈现什么样的结果给领导，需要根据领导的喜好来确定。有的领导喜欢了解设计细节，可以给出交互流程，设计逻辑；有的领导只喜欢看UI图，更关心视觉表现，那就精心准备一套设计图就可以了。

我个人认为在B端产品中，交互或者视觉的设计汇报并不是特别重要。一方面为了提高设计效率，设计师和前端通常会应用大厂的设计规范，甚至是视觉样式，或者沉淀出一套比较符合领导认可的设计规范。后续在设计应用中并不会出现太大的分歧。

另一方面大多数领导并不是特别在意细节，更多的是关注整体的界面样式。只要前期需求明确，不会产生大的变化，设计方案通常会比较容易通过。