有一句話叫做，“因為你好看，所以看好你”。我們無法停止對表象的熱愛，除非我們開始思考一些本質，只有這個時候，本質才能取得語義和熱情的雙重關注。
聊兩件工作中形式和本質有明顯差別的情況。
第一件事，在做的過程中討論，在討論中推進，是小團隊作戰的一個優選策略。小團隊做的事情常常具有探索性，成員常常十分聰明很有斗志但是明顯經驗不足，做事速度十分快，這幾個方面的原因必然導致的情況是，設計還不全面計劃還不充分的情況下就已經開始動工了。好在小團隊的溝通路徑十分短，所以在工作中的討論會非常多。比如產品出來的圖只是滿足功能點的需求，在交互和數據方面留有一些不清楚的地方。這種情況下，前端工程師和數據工程師在寫程序的時候會發現問題，于是一起討論，在這個過程中定下規則，再繼續前進。
舉個例子，原型圖只是列出了功能點。
UI同學會給一個相對規整一點的，如下。
這個時候就會存在一個問題，每一項由checkbox來管，radio有默認選項，第三列為空。就目前的用戶使用習慣來說，首先，不能區分c和r，勾選就代表選擇？用戶會有困擾。第二，先點c然后再點r，一件事有兩個步驟。第三，右側的空，不合適。前端工程師和產品商量后決定，第一，不給默認選項。第二，選擇了c才能選r。第三，取消了c就取消了r。這樣很好地解決了用戶困擾問題。
第二件事，沒有不談及對象的簡單，只有照顧到對象的選擇。我們常常會說simplicity is beauty，這確實也是一個崇尚簡潔美的時代。然而，簡潔的背后一定需要有支撐。拿病歷模版來說，這里涉及到至少三個主體對象。一個是開發團隊，二個是模版使用者，三是模版創建者。為什么開發團隊要拿出來？因為在不了解整個產品的設計邏輯的情況下，開發團隊就會低估整件事情的難度。
設計者一開始低估了設計邏輯的復雜度，并沒有做激勵體系的整體考慮。創建者的權限比較好確定，增、刪、改、查，當然還有共享，而恰恰就是這個共享，讓事情的復雜度升高了一個維度。對于使用者來說，如果收藏了共享的模版，那還能不能編輯？編輯了之后創建者的名字改為誰的？還能繼續共享么？這些規則定下來了。但是開發團隊對于“收藏”這個名字的理解是只能保存為自己的，如果說可以改的話，就應該是“復制”。發生很大的分歧，開發團隊第一次的意見是定為收藏，創建者如果編輯共享的模版也發生變化。這件事明顯不尊重使用者，因此開發團隊第二次的意見是增加一個提醒給創建者，讓創建者決定是否讓共享的模版也隨之發生變化。最終，開發團隊的第三次意見是將“收藏”改為“復制”，這樣創建者更新就不會打擾到使用者。
回顧整件事情，開發團隊有自己固定的思維，但是最大的問題還是在設計者，沒有一個明確的方案。同時在討論時偏離了方向，由于不認同“收藏”，進而變了激勵體系，再進而變了規則，最終還是維持了原來的規則。
當然，要讓一個產品成功面世，贏得開發工程師的理解是第一步，而這一步要求邏輯嚴謹。沒有形式上的簡單，前提是設計者的思維已經能夠駕馭這份簡單。與其說簡單，不如說清晰。
