[[87488]]

大部分產品團隊的通病在于，他們往往按照自己臆想中用戶意愿開發產品，而置目標用戶的實際需求于不顧。基于上世紀 90 年代設計 Windows 和 OS2 機器的親身經驗，我總結出這樣一條產品哲學，“設計服務于菜鳥，高級設置留給技術大牛。“

很多的技術專家往往以自己為中心搞產品設計，而產品發布數月后又在非目標用戶中對其測試——如果有測試這回事兒的話。如果你從沒組織過貨真價實的用戶測試——在不加任何說明的情況下讓用戶完成一些簡單的任務，你會對測試結果大吃一驚，本以為稀松平常的任務新用戶卻極難上手。

這種情況我深有體會。

當電腦由“綠色屏幕”切換至 Windows 時，我們，一群年輕、有學識的技術發燒友們很快就領會了其中要領。但這對客戶服務代表們就沒有那么樂觀了，他們往往對鍵盤快捷鍵熟稔于心，卻顯然不愿意接受新事物。我們花費了不知多少個晚上和周末為公務員們講解新系統的操作方法，目的就是為了讓他們告別那個老掉牙的綠屏電腦。

最早的用戶測試結果十分糟糕。那些客服代表們根本不想接受拖放、點擊鼠標這種操控方式。電腦簡直成了他們工作上的魔鬼，而他們只想通過敲入鍵盤指令高效完成工作，五花八門的鼠標操作于他們而言可說害人不淺。

我們生活在一個充滿選擇的世界中，但矛盾的是，我們往往討厭豐富的選擇，人們大多受不了復雜的事物。

想想你去飯店吃飯的經歷吧，老板的出發點在于盡可能地讓你選擇中意的菜肴，“拜托，不能提供一些精品選項么？”越是不常上門的顧客越會這樣想。你既不了解菜單上到底有哪些菜品，也沒有時間細細琢摸。所以一般你會問服務員，“有什么推薦的？”或者直接點特色菜作罷。對菜單熟稔于心的老板、主廚和服務員也在犯嘀咕，" 多大點事兒，點自己喜歡的就可以了！”

這個比喻只是為說明新顧客只是想在一個盡可能簡化的菜單上吃到***的東西，并在不勞神的情況下獲得快樂的體驗，僅此而已。

十多年來，Windows 系統中應用的設計一日不比不日，技術專家們總是被告知在產品中塞進盡可能多的功能。 我們都能造出迷你型芝士工廠了。

“設計服務的是菜鳥們，高級配置的樂趣留給技術大牛。“

我的產品哲學很簡單。設計服務的對象是非技術專家群體——“菜鳥們”。盡可能少的選項，以縮小用戶選擇的范圍，把產品最精髓的功能呈現給他們。像為自己的母親設計產品那樣去思考。

看看數據你就會明白，絕大多數人并不是產品的活躍用戶，因此你不能假設他們能輕易就上手，如果他們不知所以，可能再也不會用這個產品了。

我理解你想開發出功能強大產品的苦心，希望在產品中看到你覺得好的產品。坦白講呢，這個工作應該放在新品發布后，然后根據超級用戶的反饋進行新功能擴充。

還有一件事情須說明。據說，超級用戶總是能夠把產品的功能摸得一清二楚，即便它們隱藏地很深。不妨預留一個按鈕給他們手動操作的空間，以體驗產品更復雜、更牛的功能。

但一定要確保高級功能的隱蔽，免得某個菜鳥不小心碰上搞得一頭霧水。還有不要對我言聽計從。實實在在地做用戶測試，確保參與測試的用戶不是你從自己生活圈里隨便拉來的。你主觀臆斷的所謂“基礎功能”很可能還是有些難為人。

在 2005 年我們在 Koral 開發新產品時就是帶著這種產品思維操作的。當時我們剛被 Salesforce 收購，他們請我們設計一些方案做用戶測試， 我們把討論會攝錄了下來，并設定了一些基本的測試辦法：

• 上傳文件到我們的系統
• 創建一個新的文件夾
• 將文件移動至新的文件夾
• 將文件發送給朋友
• 等等

結果十分沮喪，我們認為原本自然、簡單、傻瓜式的任務基礎用戶還是不明就里，所以，除非是在為舊金山的技術大牛們開發產品，我們都要三思而后行。

我合作過的有些團隊全力支持“精益創業運動”中提到的用戶測試模式，他們往往通過階段性的用戶反饋一步步更新迭代產品。

所以當你做新產品預估時，確保盡可能地考慮到所有的假設。在加入新的功能時，問問自己是否應該放棄一些東西。

切記很多時候“少即是多”。

不要以自己為中心開發產品，也不要盲從某個朋友的看法，“要是你怎樣怎樣就好了…”

當然也不要被你的 VC 牽著鼻子走，他們往往沒有任何設計經驗。

我的意思是說，基礎設計當以基礎新用戶為中心。

不管我怎樣向合作團隊提類似以上的建議，我還是會得到一個反饋，“不過，我們只是需要…”，這幾乎成了他們增加新功能的借口。

認真做用戶測試。找到真正的用戶需求。在移動互聯網的世界，我想你更明白MVP（最簡可行產品）的重要性，人們都喜歡簡潔易用的產品。