为了提高大家看文章的效率，我决定还是先把观点抛出来：
在产品开发过程中，一方找另一方沟通时，往往会直接替对方提出一个Solution，而这个Solution背后的Question 往往在争论中被忽略了。导致问题不能被很好解决。
首先，场景还原：
场景1.
程序：针对需求R，你这个设计A不好，你这里不如加个弹窗B。你看如果有了弹窗B会多爽多爽。【先提出一个自认为很好的解决方案】
交互：我不觉得B的体验更好，因为1. 用户心理balabala 2. 用户路径balabala 3. 我们设计组已经讨论过了balabala【急于反驳新方案】
程序：可我觉得。。。
交互：我不觉得。。。
（二人度过了不愉快的一个上午）
其实，程序的真实想法是：你这样设计，我有一处代码会十分麻烦，兼容性也会变差。交互的真实想法是：在用户体验方面，你懂得又不多，还要我解释这么多。于是，我们发现，两个人开始就新方案是否是好方案进行了激烈地辩论。事实上，沟通重点已完全跑偏。
我们来理一下思路，一个需求可能有多个解决方案，而一个解决方案在实施过程中会遇到多个问题，结构如下：
场景1中，程序员往往由于方案A的某个question，直接向上游提出方案B。而场景中的Designer，又急于反驳方案B。于是讨论的重点跑到该不该采用方案B 上。
事实上，一个需求可能有无数种Solution，而一个Solution下，也可能会出现很多个Question。每一个Solution的得出，多少会经历一些推导过程，而由于某个Question 的出现就急于转向另一个方案，显然是欠考虑的。我们应该做的是定位这些Question，解决他们，使得方案更完美。
于是，在业务上下游撕X过程中，更有效率的故事情节应该是这样的：
场景2.
程序：你对需求R设计的方案A，可能在代码上出现某种问题，想想看能不能改进。【提出Question】
交互：这个问题是怎么出现的呢？【进一步了解问题】
程序：是因为。。。出现的，是否可以借鉴方案B的思路？【描述问题，提出可能的解决方案】
交互：那可以这样调整一下，采用方案A’ ，如何？【调整到最好的解决方案】
程序：Perfect！
正好找到一句slogan 作结尾，共勉！
转载请注明作者
作者的知乎专栏：https://zhuanlan.zhihu.com/FishDesign
网友评论