細節是魔鬼。
這句話有兩種解釋，一種是細節有魔鬼般的魅力，所謂魔鬼身材便是；另一種解釋是細節煩死人了，比鬼還煩人。
最近恰好有兩件瑣事，令我印象深刻。
2009年，我被邀請旁聽博客新消息系統的策劃討論。有人提到，在消息中心內回復評論的時候，如果僅僅彈窗告知“回復成功”，很不友好，用戶可能還要去日志下面確認是否回復成功。最好能和開心一樣，回復內容直接掛在消息中心裡邊，和評論區塊的樣式一致。當時我也支持此觀點。
這個想法被工程師從技術層面否決了，細節略過。最後達成的妥協方案是，回復內容可以掛在消息中心，但樣式和評論區塊（多級回復）不一致，只懸掛一級，相當於重新生成一條靜態化的提示，方便你確認“回復已成功”。當然，這會耗用額外的研發時間。
那一年，新浪微博崛起，逐漸改變了整個中國互聯網的生態。在微博消息中心回復評論，或在微博列表頁轉發內容，都只是彈窗提示成功。是否不夠友好呢？是的，我自己經常多點擊一次確認回復或轉發結果。然而這丁點體驗損失對新浪微博雄霸天下造成的影響是……零。既然如此，為什麼博客當年要花費額外的研發時間去糾結這點細節呢？
第二件瑣事關於Piictu，這款創新APP自5月發布以來，關注度不斷提升，我試用幾天後卻出故障了，無論怎麼發圖都不能刷新。當時還譏笑Piictu對網絡環境要求太高，忽然回過神來，難道是我測試“搗亂行為”時被系統拖黑了？注冊新號一看，擦！新號果然正常。像這樣對拖黑用戶無任何提示，相信是大多數交互、用研、PM無法容忍之事，然而Piictu就這麼理直氣壯地干了。去咬它啊，Who care？
對此有如下幾種常見诠釋：
★細節派
-即便是微小的細節愉悅，也能給用戶帶來驚喜，並提升對產品的信賴感
-在激烈競爭中，核心體驗容易同質化，這時細節就成為決定用戶傾向度的天平
★大條派
-核心功能需要摳細節，非核心功能無此必要
-主干流程，頻發應用情景需要摳細節，分支流程與偶發情景無此必要
表面看上去，這算是細節與大條的兩黨之爭，其實不然。我們常常贊美“細節決定成敗”，同時也常常咒罵別人摳細節太無聊，然而這兩個極端常常從同一人的嘴巴裡講出來，僅時區不同，讓你覺得他簡直就是個神經病！換句話說，是否注重細節並不取決於個人偏好，關鍵是情景判斷。不少業內人士在我的微博上對此評論道：
“產品是做給用戶使用的，當然要以用戶的需求為標准。以自以為是的標准做一款產品，無異於閉門造車。做產品，最起碼要讀懂人性。”
“產品首先應該是有用、能用的，然後才是易用、想用，現在很多人直接跳到最後2步甚至1步上了。尼瑪都不想想這東西有沒有用能不能用，搞個P的用戶體驗。”
“做產品調研時要發散再發散，想到各種可能的方向；做產品設計時要收縮再收縮，重點做最能吸引用戶的功能。 ”
“產品體驗往往會變成幾個人埋頭追求完美，用戶都感覺不到。在大方向上把握用戶真的需要的才比較關鍵。”
“細節決定成敗，是在已經把基礎做好的情況下。大面上都過不去，談何細節。更何況，不是所有的細節都值得去反復推敲。”
這些話是不是都很有道理？
很可惜，所有糖水大道理並不能幫助我們解決實際的問題。在發生爭執的時候，每個人都會認為，自己的觀點最能夠代表用戶需求。即便對於何謂“核心功能、主干流程”達成共識，這部分哪些細節該摳，哪些不該摳，也會吵個熱火朝天。什麼才是“用戶真的需要”？什麼才是“值得反復推敲的細節”？兩邊恨不得拿起火箭炮豪快地轟殺對方。畢竟細節判斷中的主觀個性多於客觀共識，如果每份爭議都去做用戶調研、數據挖掘、AB測試來解決，就會把產品設計變成一場漫長的，氣呼呼的拉鋸戰。
如我發微博所說：“產品摳細節這種事情，如果是自己做呢，會自得於無微不至與用戶關懷；如果是別人要求自己做呢，又會咒罵他無聊透頂，吹毛求疵。”
在此再一次回顧國外某科技大公司高管的經驗之談。他說“產品項目的效率很低的話，我就從小組中抽走一個人。還低？那就再抽走一個人。眼看著效率biubiu就提上來了。”是啊，都沒人跟你吵架，掰腕子，對摳細節了，效率當然大有提升。
這則經驗之談的本意是，其實沒有太多辦法去解決細節中的“個性之爭”，只好在保證主干正確的基礎上，把細節決定權賦予意見統一的個人或派別。轉化到產品項目管理中，參與制定細節的人越少，則進度越快；人越多，則意見越雜。兩種截然不同的處理方法可能都是正確的，即便有對有錯，效果差別往往也不大。但多種個性的沖突會導致決斷效率低下，多種個性疊加又會導致產品需求過載——其中大部分對最終成敗的影響為零。它們的存在意義僅在於，讓設計者覺得這是融入了我的個性，我的風格，我的產品觀的個人作品。僅此而已。
這多無聊啊……
換個角度來看，如果項目需要充分調動設計者的熱情，讓其全身心地投入，當然就得尊重他的個性。比如說喬老爺子一定要在mac電路板上刻個精美的logo，又看Google APP的Logo色階頗不順眼；又比如卡梅隆拍《泰坦尼克號》的時候，堅持購買昂貴的歐洲瓷器作為道具（摔碎），說這樣才氣場和諧。顯而易見，這些想法都很有點偏執在裡邊，但你如果限制了天才的偏執，也就無法發揮出他們偉大的創造力。對於凡人，亦是如此。
二季度以來，我一直在帶隊做相冊APP。這是部門第一款移動應用，又涉及復雜的跨部門合作。謹慎起見，參與產品設計的除了我之外，還包括iOS與Android版本的PM各一，臨時支援的交互與視覺設計師各一，再加上工程師也會提供意見。整個項目過程中充滿了吵吵鬧鬧，各種產品觀混戰一團，雖然最後由我來拍板，但觀點被否定的人往往不悅。
有一次，我對兩個版本的PM說，其實我很少同時反對你們兩位的想法。我反對M君的時候，W君多半支持我；我反對W君的時候，M君多半支持我。其中的對與錯無關成敗，大部分是體驗細節上的個性判斷罷了。但因為拍板的人是我，所以靶子也是我，給你們留下的共同印象就是，我是個壓制你們發揮的(傻逼)(混蛋)(大反派)上司。槍口一致對外。
這二位偷笑。
我又歎了口氣說，我級別比你們高，經驗也比你們豐富，既然這個項目由我在一線帶隊，當然是我話事。大是大非的問題我們放開了爭論無妨，細節分歧暫且全聽我的，否則誰想做什麼效果都往裡邊加，或者吵不出共識就拖著不動彈，這進度會像鉛塊一樣沉。直到年底站穩腳跟，進入相對安全的發展階段，再由你們各自獨當一面，我退居二線。這豈不是很合理？
合理歸合理，因為細節上的個性活躍，又常遭否決，85後年輕人的熱情依然大受打擊。其中一位跟我說，這就是份工作，哈，一份工作而已。
於是沉默，面無表情，內心有點後悔當初把攤子搞這麼大。尤其在大家都沒做過APP的時候，項目並不會因為人多而變得更安全，只會因為人多而意見混亂，進而執行力下降得厲害。在每一個產品面上（如APP設計），不僅只有一位決策者，最好也只有一兩位參與者。保證產品執行力的前提不是人多打老虎，而是默契的團隊構成。由於“默契”本身是一件非常難的事情，“精簡人數”就成了保持默契最有效的方法。
要知道，產品設計中加入一些並非絕對必要的細節追求，這幾乎是不可避免的；即便細節“絕對必要”，尺度把控也因人而異。誰沒有一點點個性呢？為了避免個性不一致導致的效率損失與細節過載，通常只能靠精簡團隊來實現，規避爭執，用快速的行動力抵消潛在的失誤率。互相信賴的創業小隊，在這一點上往往比權力分配盤根錯節的大公司大團隊更有優勢。
還有同行說，“產品經理應該更關注邏輯，沒有必要在頁面、交互上面鑽牛角尖。”相當於將細節決定權完全賦予了交互設計師。這麼做倒也不錯，但要吻合幾個先決條件：
1、交互設計師長期研究此產品，對用戶群特征有較深了解
2、交互設計師長期參與此項目，能及時響應需求
3、交互設計師與產品經理有一定的磨合經歷，配合上比較默契
4、交互設計師的才能可信賴
據我所知，符合以上四點的產品項目環境，在業內不足10%。信任感這種東西不是天上掉下來的，而是在適當的土壤中生長出來的。“土壤”本身多半取決於“體制”，個人的力量很難去改變。所以，更務實的方法還是精簡團隊，加強個人責任感並減少分歧。多多咨詢聽取意見沒錯，但在具體參與、決策的產品面上只安排少而精的人。產品設計的“群策群力”演變成“人多嘴雜”，屢見不鮮，又是何必喃？
正如我的一條微博所說：最好的合作方式是，在大局上想法互補，細節上各逞其能。最差的合作方式是，大局思路一致，結果盲點重合，然後在細節上吵得不可開交，各自都氣呼呼地堅持“細節決定成敗”。