為了提高大家看文章的效率，我決定還是先把觀點拋出來：

在產品開發過程中，一方找另一方溝通時，往往會直接替對方提出一個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，可能在代碼上出現某種問題，想想看能不能改進?！咎岢鯭uestion】

交互：這個問題是怎么出現的呢？【進一步了解問題】

程序：是因為。。。出現的，是否可以借鑒方案B的思路？【描述問題，提出可能的解決方案】

交互：那可以這樣調整一下，采用方案A’ ，如何？【調整到最好的解決方案】

程序：Perfect！

正好找到一句slogan 作結尾，共勉！

轉載請注明作者

作者的知乎專欄：https://zhuanlan.zhihu.com/FishDesign