>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

作者：朝陽陸（微信：yak1982）
來源：人人都是產品經理
鏈接：http://www.woshipm.com/pmd/137349.html

這種情況在產品經理來到一個新公司后時有發生。原因有二，一方面可能是極度想通過這件事努力證明自己，另一方面或許是他對原有的產品看不過眼，就像很多公司的開發工程師在接手別人代碼后經常說“寫的真爛還不如自己重新編碼”。

問起改版的原因，產品經理的回答很可能是界面太難看了——要是我來重新弄一遍，保管又漂亮又好用。這里又不禁想到布棉老師提到的Craigslist，如下圖所示。

我相信論長相而言，我們國內大多數產品也不至于丑過這個網站吧？對，就是這樣一個創建于1995年、沒有1張圖片、土的掉渣、只有30左右名工作人員的產品卻在全球50多個國家設有分站，創造了超過谷歌排名第1的人均產出、年營收超過3億美元的成績。所以，產品本身的定位與價值內涵沒有搞清楚的時候，不要輕易去否定任何事——此時美丑根本不是任何問題。

曾經和一名產品經理討論一個界面條目展示模式問題，他設計了列表模式，我問道“塊狀模式也不是挺合適的嗎？”他回答“那就再加一個模式切換就OK”。我追問“瀑布流也很好啊，”他緊接著說“那模式切換中再加一個選項就解決了”。

我接著問：“那默認顯示什么模式呢”？他想了想說“那就做一個用戶行為調研，或者我們系統中記錄用戶的行為數據，看看用戶更喜歡哪個模式就不行了？而且我們系統再加上一個偏好設置功能，讓用戶自己可以設置默認顯示的模式不是更簡單嗎”？他好像受到了很多的啟發：“反正用戶想到的想要的，我設計上是都能支持的！”

這樣做似乎很恰當——用戶自己有了很大的主動權，我們也“似乎”讓用戶有了更多的主動權。但問題是，會有多少用戶來進行這個設置，他們在使用這個功能時會不會產生選擇恐懼? 這一個產品的功能越多，就意味著用戶的選擇準確性和疑惑性增加——會更迷糊而無從選擇。

我相信在很多產品的實際設計過程中，大多數人都會遇到這樣的問題，我們不妨想象，本來只需要1個門的大廈，我們在1面墻上安裝上10道門，第一次來訪問的客人是否會發蒙？

張小龍在討論談移動互聯網產品設計原則時提到“不要讓用戶選擇”就是這樣的一個考慮。比如“同一個頁面之內，有多個入口；同一個功能，有多個實現方式;同一個界面，有多個展示方式。

這對于用戶來說是一種痛苦而非享受，因為他們只會因此而感覺到困惑和恐懼。用戶寧可采取重復操作漫長而固定的操作路徑，也不愿意使用多變的快捷方式。”

銷售和市場經常會找到產品經理，說用戶有一個很簡單的需求要求盡快加上去，甚至有時候產品經理憑空想到了一個點子，覺得加上去產品會馬上性感很多。于是迫不及待的找到開發說就這么簡單功能，而且用戶又非常著急，分分鐘開發就搞定了——如此想非常危險！

產品是一個有機的綜合體，每一個功能模塊都是其中的組成部分，彼此之間關系復雜，有可能單純加一個功能會導致整個系統的邏輯變更以及系統底層的技術風險，這就像冰山一樣，我們看到的永遠是表面的一點點，增加一個功能，牽扯到的是產品設計、交互設計、視覺設計、開發、測試等一群人的后續支持，僅僅就工作量而言就有可能超出計劃節點，更別說由此帶來的用戶使用風險及技術實現風險。

有效的控制方式是做好完善的需求變更管理，將一切納入到正常的開發計劃中，團隊彼此做好充分的溝通與討論，確保這事靠譜。

信息化如今高度發達，從產品設計的資源角度給了我們極大的便利性，但純粹的創新設計畢竟少之又少，設計啟動后一般是先去找國內外同類產品之后“山寨”。

從競爭和公司發展角度，除去外人“鄙視”的眼光問題，山寨不失為一種快速實現的模式，畢竟沒有必要都重復制作輪子。

本人也看過不少的互聯網產品直接山寨國外的成熟系統，連界面都屬于像素級Copy（logo還算小改了一下）——或許無可厚非吧，但是還是建議這些產品經理，在拿別人東西設計的同時要有自己的思考和發揮才是更重要的事情，直接原封不動的山寨意味著是順著別人的想法走，自己本身沒有核心競爭力——不管是設計還是技術都如此，或許在產品發布的第一版能賺取眼球但一定是后繼乏力。

在這個點上本人對特別某六零公司的做法深有感觸甚至推崇，大都是搶食其它小公司的創意和想法，但又揚長避短，發揮設計，加之本身的流量優勢，于是每擊必勝。所以山寨也好，抄襲也罷，都不可恥也不可怕，怕的是不消化。核心需求是自己的主線不能缺失，解決方案層次可以參考別人的做法，但一定要有自己的思路和想法，如此才能山寨的更好，把前輩拍在沙灘上。

和上章節提到山寨很有關系的是，很多產品經理不主動且善于學習，在很多設計點上沿用自己很老范疇里的知識點，遇到過一個產品經理設計登錄頁面，還是用了N年前那種論壇注冊的三步向導方式，如下圖所示。

建議隨便去網上搜搜別人的做法，大多都不會是這種設計（除非產品有特殊需求），實際上如此做法帶來的并單純是用戶交互繁瑣的問題，折射出來的是不去參考借鑒與學習，對于產品經理而言，這更可怕一些。另外一個故事，2014年面試過一個90后的產品經理，我問你手機上安裝的自己喜歡的App是什么？他回答說是Tom貓，就是會說話變聲的那個——拜托！這個軟件在幾年前就已經風靡全球了，你現在才剛剛知道。

所以作為產品經理或者準產品經理，應該每天給自己留出足夠的時間來不斷充實自己，實時刷新自己的知識體系。微信公眾號和網站都是很好的渠道（比如人人都是產品經理、優設網、CEO來信……非常多），另外豌豆莢每周會推薦非常實用、創意、或經典的App，可以安裝試試，相信能有不少的收獲。

我們做原型、做產品的邏輯設計，經常考慮的是在合理的理想情況下的界面布局、跳轉規則，但是有時會忽略其它狀態；比如一個列表頁面，在沒有任何數據的狀態、理想數據條目狀態、數據量特別多的狀態，可能會更多考慮是理想數據條目狀態。我在另一篇文章《優雅的初始頁》中曾經提到，所謂初始狀態頁，實際上是極限狀態頁面設計中的一種，極限狀態頁面包括初始頁面與極多狀態頁面，如下圖所示：

初始狀態就是剛剛開始使用的界面，極多頁面我們可以理解為當數據量非常大的時候，整個界面的效果，這里不闡述具體的解決辦法，只是要提醒忽略的同學，這些不同狀態都很重要。另外提醒一下，伴隨著用戶操作以及我們定義實體對象屬性不同，在不同的場景下的相關界面與規則定義也是如此，比較好的辦法就是繪制比較詳細的邏輯流程圖，把每種不同判斷場景下的規則明晰定義。

實際上控制產品迭代是開發經理的職責，但是最初的產品迭代計劃是產品經理共同參與制定的，互聯網產品都講求極簡與精致，在研發進度管理都在做最小化可行產品（MVP， Minimum Viable Product），通過MVP前期主要走通技術環節、實現產品設計初步目標以及試探市場反饋，后期要依賴于快速的產品迭代進行完善和修正。

道理大家都懂，但是在迭代的劃分角度，從實際操作的角度來講，真正做到或者最好的少之又少。這其中的原因很多，比如趕進度、老板的死命令等等，但是其中一個是產品經理的患得患失心理，總覺得缺失了功能產品就不完整，覺得若干小功能放到前一個迭代也不會影響太多，最后導致產品計劃的臃腫和開發風險的加劇。

所以在定制迭代計劃時，最最可怕的就是追求所謂的完美，從產品的生命周期來講，不會有一個完美的產品存在，永遠也不會有，我們能做的是讓產品盡量滿足一個時期的核心需求，用20%的精力解決80%的問題，如此而已。

互聯網er的早讀課 2015-08-23 08:46:13