不知你是否已经厌倦了设计会议中的无休止争论？我在工作中经历了很多观点争论，终于研究出一套可行策略，它可以减少无谓的摩擦，推动团队作出科学决策。
为了让该策略更容易理解，下面我将从当时情况开始讲述：
一个三人评审会上，设计观点上存在一点小分歧。这是电商后台配置物流承诺的场景中，一个时间区间的组件。这个组件的本质逻辑，是通过最小值和最大值来限定一个1-15之间范围，后者要比前者大。
产品："为什么不用两个简单的下拉框呢？需求急迫，这样的限制显得有些多余吧？"他的质疑是合情合理，毕竟每一个设计背后都应该有价值支撑。
我说："设想你在陌生的街头寻路，面前是三岔路口，任何一条路都可能是对的，也可能是错的。而这个设计，就相当于是告诉你正确的方向，避免走错。它的存在，是为了减少用户的选择错误，提高他们的操作效率，进而激发他们对平台的好感和信任。"我的答案是从设计出发，逐步迈向用户体验，最终引向企业价值的旅程。
正如预料中的那样，一个问题的解答常常只是引出另一个问题的开始。
产品："但如果用户并不常用这个功能，只需设置一次，真的有必要这样设计吗？"
我说："体验设计往往不像一些直接需求那样能量化价值。它更像是一种全面的概念，微妙的交互在细节中解耦目标，却也构筑了整体体验的框架。"
随后，开发加入讨论，虽然我们最终决定采用这个带有限制的方案，但如果开发团队提出强烈的反对意见，这个决定很可能就会被推翻。这也让评审会时间拉长了一倍。在这个案例中谁对谁错呢？最佳选择又是什么呢？答案在后面揭晓。
这样的情况，我在工作中已经不是第一次见了。类似的争论在工作中几乎无处不在，我们常听到的问题有："别的设计师也没做这个，为什么我们要做？"或者开发可能会说："你这设计太麻烦了，我们不做了好吗？"最棘手的问题往往是那些似是而非的，这些问题没有实证支持，每个人都有自己的逻辑，难以说服对方。
管理学有句话说得好，如果一个问题在工作中经常出现，那么就有必要着手优化。大概就这意思，德鲁克具体怎么说的我已经忘了。
面对这些问题，我找到了一套行之有效的策略，并且依旧以前面提到的组件案例来阐释：
设计不是为了设计本身，也不仅仅是为了业务，而是为了产品，为了企业的整体利益。从实际出发，我们才能逐步了解企业到底需要什么样的产品。
其次，我们要对设计到最终目的之间的关系有清晰的认识。
这意味着我们需要深入理解整个模型，从组件的选择到企业价值之间的每一个环节，这需要设计者对设计与企业之间关系有深刻的理解和沉淀。
如果，选择不尝试，我们便失去了获取用户信息的机会，产品体验也不如尝试时的丰富。这会使团队趋向于保守，这种趋势可能蔓延至核心场景的设计决策中。
如果，选择尝试，我们将有机会深入了解问题，尽管可能需要付出更多成本。通过这种尝试与探索，产品整体质量将得到提升，长远来看，我们对这些决策会有更深的理解，并可以根据实际信息进行调整。
这时会发现，事实上很多决策的观点冲突僵持不下都是浪费时间。这里的选择共识也适合不同类型的企业发展需要。
分析到这里，就理解了为什么讨论会僵持不下。案例中价值和成本之间的关系难以权衡时，我们仍然难以做出决策。之所以争论是因为没有绝对的证据，所以谁也说不服谁。
从决策论的角度看，遇到僵持不下的情况就是因为进入到了模糊的未知领域。而未知领域，就只能通过一条核心思路，比如上面分析中的做与不做，以及会产生的价值风险点中选取一种倾向在一定时间内固化下来。
在工作中，不同的观点常常导致长时间的僵局。这时就需要考虑团队决策的价值共识。也就是我们处于特定场景下定义一种思路，达成共识，以后遇到类似的情况就依据分析的结论规定一个路子走一段时间就行了。
遇到这种问题我们可以通过分享会，制定产品的基本标准、决策标准作为原则，定义决策共识，就能既适应企业需要，又减少这类情况下的矛盾冲突从而达到提升工作效率聚焦企业目标的目的。
需要注意的是，该策略并不是让我们立即获得一个正确的答案，而是通过一个指导方针让我们走在正确的路上。而共识就是为了降低走在这条路上的摆动，作无谓的消耗。
最后，我想说的是，沟通的结果不应该以妥协告终，而应该基于各方观点作出一个客观的结论。妥协只会让问题延续，好似房屋出现了裂缝而不修补，而我们却无法预知它何时会坍塌。
