产品经理在日常工作中，最常见的场景就是进行功能设计。在进行功能设计时，一般需要用到流程图、线框图，将自己和团队的想法、竞品分析和用户调研的结果进行归纳总结，最终输出成型的文档或交互稿。

好的功能设计，一定是贴合业务场景，并能实现预期结果。预期结果是否达成一般依赖相关数据的监控和用户反馈。

产品经理如何进行功能设计呢？流程如下：

确认所设计的功能，在用户体验路径中所扮演的角色；

根据角色职责确定角色任务；

根据任务确定要呈现给用户的信息和交互方式；

将信息和交互方式融入到整体的用户体验路径；

在大体的设计流程上，不同的业务场景都大同小异。但功能设计的核心，却需要依据具体情况进行判断。尽管如此，在进行功能设计时，有一些 *** 论仍是通用的。

之一个核心的 *** 论是穷尽原则

在有约束条件的封闭系统下，对于某类问题，往往会存在更优解。但在大多数情况下，更优解很难找到。产品经理在进行功能设计时，往往依据自己对用户的了解，过往的经验，和逻辑进行设计方案的更优解判断。

这种判断一般只存在于设计者的脑袋中，而并未以白纸黑字昭示。当进行功能评审时，团队中的其他成员如果有好的 idea 或对现存方案提出质疑，也许会促进产品经理重新思考方案的可行性。

事实上，会议阶段的评审只是在点的层面上进行拓展，即使这些点在后续进行优化，但也只是零散化而已。这种会议式的灵光一闪或许会提高方案的质量，但仍未到达更优解的状态。

实际上，产品经理在设计方案时，应该尽可能地罗列出多的解决方案。这些解决方案或许有明显的优劣之分，但直接在脑海中将其否定并不恰当。人脑非机器，在进行判断时更好依靠工具。

第二个核心的 *** 论是比较原则

不同的方案，有各自的优劣之分。在判断优劣点时，可以将解决方案列在左右，将优缺点分别分点叙述。需要注意的是，所谓的优缺点只是方便的称呼，它实际上是产品经理的一种假设。

假设，即未经证实之事物，一般为产品经理基于逻辑判断得出的主观结论。而逻辑推演出的结论，有赖于产品经理的逻辑能力。由 A 推出 B，由 B 推出 C，但并不代表由 A 能推出 C。常见的逻辑谬误如归因错误等，经常出现在产品的论述中。

逻辑的修炼，依赖于实战和不断分析。在实战中，可能面临着大量出错的环节。为了尽量避免这种情况发生，最容易的方式是进行团队讨论，向团队的其他成员传达你的方案，以及你对方案的优劣点假设。

如果团队对你的假设基本同意，那在一定程度上验证了你的逻辑性。如果没有，那么就请对方指出缺乏说服力的地方。这个时候你可以记录下来，与对方进行交流，阐述你的看法。在交流结束后，重新审核你的逻辑链，思考是否存在逻辑断裂的情况。

在讨论假设时，最重要的是弄清对方为什么这样想，自己为什么那么想。搞清楚双方的出发点，从源头思考逻辑的正确性。通过团队讨论，产品经理可以在更大程度上保证假设的正确性。

正确性是对比的前提，在此后，就可以进行优劣点的逐条对比分析了。不同的解决方案，优劣点的维度往往不同。譬如 A 方案的优点是 a，缺点是 b，而 B 方案的优点是 f，缺点是 h。无论是 a  f 还是 b h，都分属于不同的维度，没有办法进行比较。

这个时候产品经理就得结合具体的场景，确定该功能最想要实现的目标，并基于目标找到最有帮助的优点，剔除最有影响的缺点，寻找到最合适的解决方案。

实在遇到不同解决方案，都很有可能性的情况，也可以视实现的难度和成本进行选择。

第三个核心的 *** 论是实验原则

如前文所述，优劣点只是一种假设，而假设则需要验证。当产品经理选定解决方案后，就可以将方案进行验证。常见的验证 *** 有两种：内测和 A/B 测试。内测的优点胜在跟真实用户进行深入交流，但样本量小；A/B 测试的优点胜在样本量大，但依赖于数据正确的埋点和分析。

数据由人来解释，也同样依赖于逻辑的严谨性。

当内测或 A/B 测试的结果反馈后，产品经理根据结果确定解决方案的可行性。可行性的确定取决于解决方案的逻辑与结果适合文档。数据结果优秀，不代表方案可行。重要的是方案背后的推导过程，结果是由逻辑链推导而来，是检验逻辑链是否正确的可信凭证。