作者：维克先生

注：本文所讲的B端产品，主要是指通用型B端产品 ，不涉及定制化开发的B端产品，两种类型的产品设计流程有着本质的差异，通用型B端产品以满足某个群体客户的通用需求为目标。

当我们计划做某个功能时，如何开展设计呢？是确定迭代任务后立刻思考解决方案？还是直接构思功能细节？

需要说明的是：有序地做事和无序地做事在效率和质量上是有很大差别，尤其是对于具有前置依赖特点的环节，若前置动作做不好，返工和走弯路是常事，而这些不必要的成本我们其实是可以避免的。

先说流程，再详细讲解：

1. 找准核心需求场景；

2. 明确此次设计要达到的目标；

3. 为目标达成找到最优方案；

4. 设计功能整体框架；

5. 基于整体框架，完成具体的设计；

6. 明确默认值、补充异常场景；

7. 模拟用户路径，验证功能设计的可行性；

本文主要讲解功能设计流程里的第二个环节：定设计目标。

放心，这里的内容并没有跑题，听我慢慢讲来。

我听过许多关于产品经理工作的定义：

• 肤浅些的理解：产品经理是做设计的，画原型图的，这样看来好像学会Axure就可以做产品经理了；

• 进阶点的理解：产品经理是研究用户需求、制定产品方向、设计产品方案的。

我最近也在思考产品经理的工作定义，以及产品经理的关键能力。

说需求分析、制定产品方向、设计产品方案是产品经理的核心事务我觉得没有大问题，不过这未必足够精准，因为不同细分方向、不同等级的产品经理做的事情存在一定的差异（例如制定产品方向的工作，初阶的产品经理肯定不会涉及）。

定义产品经理的核心事务，很难用一两句话就直接定义清楚，需要去分方向、分岗位等级去进一步说明。

但是， 产品经理的核心能力，我认为是相对明确的，很关键且重要的一项就是：决策判断能力。

为什么是决策判断能力？

• 在需求分析过程中，哪些需求场景要满足，哪些需求场景不必满足，需要做决策；

• 在产品设计过程中，选择A方案还是B方案，需要做决策；

• 在项目排期过程中，什么阶段完成哪些功能开发，需要做决策；

• 在产品开发过程中，研发、测试、交互反馈了一些影响设计的问题，需要做决策；

优秀产品经理的表现是在关键环节能够做出足够合理的决策。如果做不好决策，那么就会随波逐流或随自己的想法发散，做出一个好像能用，但是又不太好用甚至很难用的产品。

对核心需求进行判断的方法已经讲过，那么当我们进入设计和开发阶段时，决策判断的依据是什么呢？

案例：我们正在做一款产品的部署和注册功能，方案设计完毕后，评审时发现有以下几个问题点：

• 性能测试提出：部署包自带的容器如果从tomcat换成SpringBoot，启动性能会更好；

• 产品运营提出：期望注册这块可以有更丰富的提醒，这样对用户更加友好；

• 研发反馈：设计里的某些功能有可能无法实现。

面对上面的问题，我们该如何进行决策？

做决策不能只靠拍脑袋，脑袋拍大了也未必能够做出好的决策。 做决策时需要有一个标志物，这个标志物就是产品设计的目标。

当有诸多建议输入进来，对齐预先设定的设计目标（除非目标有问题，要去校准目标）去决策，思路会清晰许多：

• 需要加的功能，评估其是不是达成目标所必须的，如果不是必要的，不能轻易加；

• 需要减的功能，评估其是不是达到目标所必要的，如果是必要的，不能轻易减；

• 需要改的功能，评估其调整以后，还能不能达到我们预期的目标。

目标就是我们决策的指南针。

所以，我们有必要提前制定出设计目标，为我们的产品设计旅程定一个可预期的终点。

基于目标做出的设计边界会更加明确，也可以让设计者，在产品开发上线的过程中，面对问题更容易做出合理决策。

目标是为产品预先设定的期望达到的结果。作为预期的结果，它需要有一个服务对象。

在我们评估判断核心需求场景时，已经引入多方面的因素来辅助决策，它们包括：

• 用户价值：满足此需求场景，为客户带来的价值，比如提高了客户的开发效率，节省了成本；

• 市场价值：满足此需求场景，为市场销售带来的价值，比如能够给年销售额带来多少增长；

• 竞争价值：满足此需求场景，为产品竞争带来的价值，比如能够超越核心竞品，提高竞标成功率；

• 内部价值：满足此需求场景，为企业内部带来的价值，比如支撑企业内的其他产品，支撑运营动作等。

在制定设计目标时，我们依然需要回顾这些因素，并且要进一步对预期的价值进一步明确，并最终体现在目标上。

设计目标的制定和常规的目标制定类似，也是要符合SMART原则：

• 具体的（Specific）：面向哪些角色，解决哪些问题，满足哪些需求，要足够具体；

• 可以衡量的（Measurable）：功能上线后，能够带来的价值，要尽可能可衡量；

• 可以达到的（Attainable）：目标是可以达到的，有挑战性，不能过低，但是也不能过高，可达到的目标才有指导意义；

• 与其他目标具有一定的相关性（Relevant）：设计目标应该与团队目标、整体产品的目标、公司目标具有相关性，不应该是单独存在的；

• 具有明确的截止期限（Time-based）：什么时间可以达到此目标，做完哪些任务可以达到此目标，要明确出来。

制定好的目标团队内要达成一致，这样做方案选择时、做功能设计时、开发时，如果遇到问题，就可以对齐这个目标去做判断了。

需要说明的是，目标是提前拟定的，如果发现目标有问题，不能一条道走到黑，过程需要及时校准目标的合理性。

为了支撑产品售卖的需求（内部价值），团队内部决定开发并上线「注册」功能，需要为此制定目标：

• 具体的： 面向管理员用户，满足：1）注册使用产品的需求；2）注册过期提醒的需求；3）具备防破解的能力；

• 可以衡量的： 1）功能上线后，所有采购产品的用户均可使用注册功能；2）注册文件可抵御XX安全公司的破解测试；

• 可以达到的： 产研团队对目标均认可，判断预计可以达成；

• 与其他目标具有一定的相关性： 注册功能是为了支撑团队的销售目标；

• 具有明确的截止期限： 2022.06.06上线一期的注册功能，2022.08.08上线二期的注册提醒功能，两个功能均上线后预计可达成目标。

以上是为了符合原则做的分解，实际制定时需要将其整合成一段易于理解的内容，如下：

设计目标：

为了支撑团队的销售目标达成，预计2022.06.06上线一期的注册功能，2022.08.08上线二期的注册提醒功能，两个功能均上线后预计可达成如下效果：

• 企业的管理员均可正常使用注册功能完成产品授权；

• 有注册过期功能，可以让产品过期信息及时触达给系统管理员；

• 注册功能安全可靠，经过XX安全公司的注册破解测试以验证是否达到标准。

1）所有类型、大小的任务，都要考虑设计目标吗？

对的，产品经理要保证自己的每一个设计都有其目标。不过考虑到任务规模存在差异性，不是所有的任务都能遵照SMART原则定出目标的。所以我们对SMART原则做了星级标记，其中最重要的就是「具体」，这一点一定要达到，其他各项可以基于实际情况去写。

2）基于目标去对一个问题进行决策，是不是还有一套逻辑？

是的，例如我们评估某个增加功能的建议时，除了评估其是否是目标达成所必需的，还要看其成本（实现成本、维护成本、客户理解成本等）和价值，如果实现成本极低，价值比较高，那么即使其不是目标实现所必需的，我们也可以考虑增加。

想要了解B端产品设计流程中后续环节的方法，可以关注我，会持续更新。