本文作者Rian van der Merwe 2005年到2009年間曾就職于eBay，現在在Jive Software擔任產品設計主管。在這篇文章中，作者提出打造一款成功的產品，必須在產品開發的始終關注著“用戶需求”、“商業需求”以及“技術需求”。

“如果我問人們他們想要什么，他們會說想要一批跑得更快的馬?！边@句話據說是福特汽車創始人亨利?福特的名言。人們經常引用它來支持那些未經用戶測試的所謂的創新。這句話其實價值不大，因為福特可能壓根沒說過這句話，而且按照這種思維方式經營公司很可能會在市場上慘敗。

我們應該認識到，把一個沒有經過驗證和測試的 idea 拿去執行是一件非常危險的事情。我們在理解某個問題之前，不應該直接跳到解決方案部分。而這也將是本文所要討論的。

開發一款產品出發點永遠是需求。我們不能想當然的認為某個產品會很好，只有真正滿足用戶的需求并在商業上獲得回報的產品才能取得成功。我認為開發產品的過程應該在以下幾部分給予更多投入，我們在本文也將詳細討論這 3 方面需求：

用戶需求。我們必須很好地理解市場，理解公司的消費者（包括現有的和潛在的），了解他們的行為和態度。我們在產品目標受眾研究方面不應留有死角。

商業需求。“用戶至上”的口號經常掩蓋了一個事實，那就是產品存在的意義是為了賺錢。但商業方面的需求也不能成為糟糕設計的借口。

技術需求。人們常常過于重視更直接的前端和商業需求，而忽視了技術需求。開發人員知道產品的局限，他們知道有哪些問題需要解決，也知道技術方面什么欠缺需要補上。

產品開發中容易犯的最大一個錯誤就是在完成合理的產品規劃前開始執行。所以，我們需要給規劃環節足夠的重視。首先，我們來談談收集用戶需求。

用戶需求

我們首先要區分清楚兩個概念：需求和功能。人們經常錯將產品功能等同于用戶需求。來看一些家電行業的例子，你就知道為什么我這么說：洗衣機上的預置模式可能有很多種，但是你常用的是不是只有一兩種？用面包機時你需要幾種烤面包的方式？這兩個例子說明產品的功能并不等同于為用戶創造的價值，多并不意味著好。我們不需要更多的模式來洗衣服，但我們可能需要快洗或者更安靜洗衣方式。

當產品設計得過于復雜的時候，我們就得自己想辦法解決問題了。（圖片來自Reddit）

Facebook Home 面世后不久，相關評論和使用統計數據就開始出現，John Gruber 說了一句讓我印象深刻的話：“它的設計精良，但是沒有人想要這個創意?！彼倪@句話有夸張的成分，但是也說明了如果把功能（首頁信息流、朋友充滿屏幕、Chat Heads 功能、app 啟動器???）等同于需求（人們為什么會愿意把他們手機的操作系統換成一個 app）的后果。功能和需求之間的差異是非常重要的，有時又很難發現，這時就應該進行用戶調研。

收集用戶需求的調研主要依靠觀察和分析，而不只是收集一堆預先設置好問題的答案。但是探討優化產品的各種方法之前，我們需要定義一些基本研究內容。

首先，我們需要區分定量研究和定性研究。在定量研究中，數據往往不直接收集自受訪者，而是通過調查問卷或網頁分析收集。定量分析能幫助你理解發生了什么情況，或者在多大程度上出現了這種情況。而定性分析數據直接從參與者處收集，通常以訪談或者可用性測試的方式進行。定性分析可以幫助你理解某些特定的行為會怎樣出現，以及為什么會出現。

其次，我們還需要區分市場調研和用戶調研。二者都非常重要，但他們的目的不同。市場調研是要了解市場上整體的需求，主要關注品牌價值和市場定位等問題。態度調查問卷以及焦點小組訪談是市場調研人員通常使用的基本方法，用于搞清楚如何在市場中定位產品。調查問卷和焦點小組訪談在理解市場趨勢和需求的時非常有用，但在產品設計方面用處不大。

另一方面，用戶調研的關注點則在于用戶如何與你的產品互動，關乎到人們如何使用新技術，以及從他們缺少的，需要的以及感到沮喪的地方我們能了解到什么。在這部分，我們將主要關注用戶調研的方法。

那么，基于上述定義，我們來看一些最常用的用戶調研方法。大體上分成三類：

1. 探索性調研（Exploratory Research）

當我們的目標是發現用戶使用產品最重要（通常是未被滿足的）的需求時，探索性調研非常有效的。探索性調研包括情境訪談（也叫做“民族志研究法”或“實地訪問”）、參與式設計會議以及產品概念測試（concept testing）。這么做的目的是發現現有產品在解決用戶需求時所出現的不足。新產品或功能的創意常常出自這些會議。

不要搞錯，這種方法并不是問人們是不是想要“更快的馬”，而是觀察人們，發現他們在哪些方面需要比現在做得更好。

舉個例子，我們曾對世界各地許多 eBay 賣家做過實地訪問。通過走進人們的家中，觀察他們如何管理銷售，我們發現了一個通過網頁分析或問卷調查絕對不可能發現的問題。每個賣家管理店鋪的方式都不同，有些人在顯示器周邊貼滿便利貼，還有些人使用帶有復雜公式的 Excel 表格。賣家不得不自己完成一些本該由 eBay 做的事：如何記錄銷售過程并做出分析得到結論。通過實地走訪，我們發現了一些還沒有滿足的用戶需求，并通過多種方式解決了這些問題。而需求是這一切的出發點。

2. 設計研究（Design Research）

設計研究幫助開發者利用需求分析得出的結論進一步改進產品創意。具體方法包括傳統的可用性測試、RITE 測試（rapid iterative testing and evaluation，快速迭代測試與評估），甚至包括眼動記錄等定量的方法。這類研究在設計產品，解決用戶需求過程中作用十分明顯。舉個例子，我們可以先開發一個交互式的原型機，然后把人們帶到可用性測試實驗室，給他們一些任務讓他們在原型機上完成，通過這種方式我們可以在進入代價高昂的開發環節之前發現一些可用性方面的問題。通過深入的一對一訪談，我們有很多機會深入了解自己是否很好地滿足了在探索性調研中發現用戶需求。

3. 評估研究（Assessment Research）

評估研究幫助我們驗證對產品所做的改變是真正提升了產品，還是只做了無用功。這類研究常常被忽視，但它是產品開發過程中非常重要的一環。我們可以通過調查問卷和網頁分析了解隨著時間推進產品的表現如何。這里需要關注的不僅是一些硬指標上的變化，還要看用戶態度上的轉變。只有將評估研究和設計研究深入地結合起來，才能更好地理解我們為什么會看到產品發生的變化。比如說，表格分析可以看出人們在哪里放棄填寫一份表格。每當我們改進一次表格的可用性，就需要了解這些改變對表格的完成度有什么影響。沒有評估研究，我們就沒辦法知道產品是否對了方向。

商業需求

在互聯網行業，我們見過很多充分滿足用戶需求但沒法賺錢、沒法持續發展的公司。在過去幾年，很多優秀的網絡服務關停就是因為缺少收入。比如 Editorially 是一款出色的協同寫作和編輯工具，但它的創始人卻發現：“即使所有的用戶都付費也不夠。

在 Editorially 之前，照片管理服務Everpix也關門大吉了。部分原因就在于他們無力支付云儲存費用。雖然 Everpix 平臺上有大量付費用戶，但仍然入不敷出。創始人后來承認，雖然公司開發出了人們真正喜愛的產品，但是團隊在產品上花費得時間過多，沒有留出足夠的時間去關注公司的發展和產品的推廣。

現在很多互聯網產品都希望先獲得盡可能多的用戶，然后再考慮賺錢的事情。但是在我看來，這種并不是做生意的方式。我并不是說一款新產品需要從第一天開始就盈利（當然能做到更好），但是至少你要規劃好能夠帶來穩定收入的業務模式，在做商業計劃時明確公司未來的收入來源。

那么，公司應該如何獲得收入呢？大多數情況下，我們需要依賴消費者。在“用戶需求”的部分，我們討論過一些調研方法可以幫助你判斷用戶是否愿意付費，以及愿意支付多少費用。開發產品的過程中，需要聯合公司內的業務拓展團隊、銷售團隊、營銷團隊以及工程團隊，做好兩方面工作：放棄不良收入，追求優質收入。

放棄不良收入

一位古希臘作家曾說過：“收益總是甜美的，即使它來自與欺騙?！保≒rofit is sweet, even if it comes from deception.）這句話揭露了我們在金錢面前是多么的脆弱。通過欺騙的手段賺錢有時看起來很誘人，但這種短視行為在長期來看會帶來巨大的問題，而且會讓你背負沉重的道德包袱。

在界面設計中，我們把一些欺騙性的技術手段稱作“黑暗模式”（Dark Patterns），也就是通過誘導性的界面，讓用戶做一些正常情況下不會做的事情。在darkpatterns.org這個網站上，我們可以看到這樣的案例：

會說話的湯姆貓等一些針對兒童的 iOS 應用中會隨機彈出一些頁面，誘導兒童購買一些內購項目。

登陸 PayPal 時經常會看到全屏廣告，只在右上角有一個小小的按鈕能關閉廣告繼續賬戶操作。

Zynga 出品的農場類游戲 FarmVille 在開發時只有一個目標，那就是迫使用戶盡可能長時間的照料他們的虛擬土地。

Ryanair 把取消購買保險的選項放在一個無關的下拉菜單中，所以很多人根本沒有意識到自己買了保險。

Ryanair網站上如何取消購買保險。（來源：Dark Patterns）

很明顯，有一些收入是不道德的，因此也不值得追求。問題在于，這些方法常常是能賺到錢的（至少在短期內）。但是其長期的效應也不容忽視，一旦用戶搞明白發生了什么，他們就會開始抱怨。這些不光彩的手段會直接影響到公司的聲譽，同時也會增加客服費用。Ryanair 那樣保險銷售的陰謀已經成為“黑暗模式”的典型反面教材。

當然，大多數人內心深處并不想通過欺騙的手段掙錢，但是“黑暗模式”可能會潛移默化地侵蝕了我們原本正常的想法，直到徹底改變它們。

對于“黑暗模式”，我們不需要花費太多心思去斗爭，只需要提醒自己：小心，不要掉進這個陷阱。每當遇到能增加收入的機會時就問問自己：“如果一個產品讓我這么操作或者讓我付費時我會接受嗎？”如果答案是否定的，那就放棄這個念頭，還會有更好的方法。雖然有時找到合適的盈利模式比較困難，但是犧牲短期利益來換取用戶的長期忠誠才更有價值，你也會過得更加問心無愧。

還有另外一種情況，一條收入線在起初是良性的，但是隨著外部環境的變化逐漸變成了一筆不良收入。如果這筆收入已經成為你的一項重要收入來源，那你就需要十分小心謹慎了。

這方面的一個案例就是 eBay 搜索結果中的圖片。1995 年 eBay 創辦時，存儲是非常昂貴的。所以當用戶在商品列表中上傳圖片時收取一定的費用是合理的。10 年過后，到了 2005 年，存儲已經變得非常便宜，上傳照片要收費這種做法看起來十分荒謬。但是圖片上傳已經成為 eBay 的一筆可觀的收入，要放棄這筆錢，把圖片上傳免費，著實是一個非常艱難的決定。

我們的用戶體驗團隊和分析團隊通過研究發現，在搜索結果中默認顯示圖片不僅能增加銷量，而且對于搜索結果有用性的評分也有積極作用。最終，eBay 決定放棄這筆不良收入，把圖片上傳免費（最多 8 張），而且后來也沒有再改回去過。

眼動追蹤數據顯示出圖片展示對于搜索結果的重要性

在產品開發過程中如果涉及到一些不良收入時，最好的做法就是進行調研，理解用戶的需求和動機，結合 A/B 測試來衡量不良收入對優質收入所帶來的影響。

追求優質收入

優質收入可以來自許多不同的渠道。對于消費者來說，只要產品的價值是顯而易見的，他們就有付費的意愿。因此，在整個產品管理的過程中，需要首先明確產品的價值，然后再開發產品并開展相關的業務，不能先開發出產品再附加給它價值，用戶需求研究永遠是產品盈利的第一步。

對于一些已經存在的收入，有一些標準的增長方式，比如拓展到新地區，建立新渠道，延伸到更廣闊的市場，為已經現有市場開發新產品等。在 Brandon Schauer 所寫的《Adaptive Path》一書，還提出了一種新的收入增長理念，稱為 Long Wow。原書中對 Long Wow 的定義如下：

Long Wow 意味著通過一次又一次地滿足顧客來獲得他們長期的忠誠。Long Wow 不僅僅是衡量忠誠度標準，更是通過以用戶體驗為核心的方式來培養和創造忠誠度。

Long wow 由以下四個步驟組成：

1. 了解與用戶溝通的平臺。明確線上和線下與用戶接觸的不同方式。

2. 滿足用戶尚未被滿足的需求。在用戶需求研究的基礎上，認清哪些重要的用戶需求還沒有被你的產品或者任何一款現有產品所滿足。

3. 創造并發展一套可重復的流程。將公司現有的優勢和新的創意結合起來，不斷滿足消費者需求，取悅用戶。

4. 做好計劃，呈現驚艷的用戶體驗。隨著時間的推進，改進你的 idea。在產品整個生命周期中不引入新的、更好的用戶體驗。

然后，根據情況不斷重復這個過程。通過這種方式，你可以衡量產品是否帶來了優質的收入，而且能確保為用戶持續提供價值，培養更多愿意付費的忠誠客戶。

技術需求

在討論技術需求之前，需要先明確兩個概念：“技術資產”和”技術負債“。所謂“技術資產”就是產品所依賴的底層技術以及一些日常辦公所用的系統（采購、財務、后勤）。相反，“技術負債”指的是限制產品開發的系統和代碼（經常以 bug 的形式出現），技術負債如果長期得不到緩解會帶來更加嚴重的問題。Construx 公司的首席軟件工程師 Steve McConnell 認為，技術負債主要可以分為兩類：

無意的負債(unintentional debt)會出現在錯誤設計被實施時或者程序員寫出了差勁的代碼時。這種負債并不是刻意的，當然越少越好。

有意的負債(intentional debt)是指公司明知道某種情況并不理想，但是出于種種原因還是做出了妥協（通常是由于預算或時間限制）。盡管這類技術負債也并不是件好事，但是對任何組織來說，它都是不可避免的，我們需要做的就是將其影響最小化。

對于技術負債來說，我們需要盡可能地減少負面影響，不然就會遇到我們常說的“破窗效應”。

“破窗效應”是犯罪心理學中的術語。用來解釋城市中秩序混亂和破壞公物的行為，其含義是：城市管理中需要保持各種設施處于良好的狀態，并隨時監控，這樣才能阻止進一步的公物破壞甚至升級成更嚴重的暴力犯罪。

我們可以把軟件比作城市的環境。如果有幾扇窗戶破了（軟件中出現一些糟糕的代碼），而破窗又沒有盡快修好，那么很有可能會出現更多破碎的窗戶（人們變得不再關心優質代碼），繼而環境進一步惡化：垃圾到處出現，擅自占用空房的人越來越多（代碼標準普遍下降）。不久之后，所有的窗戶都會破碎。

如果負債擴大到一定程度，公司最終花費在彌補這些漏洞上精力會比用在創造新價值上的還要多。常見的情況就是遺留的代碼庫往往需要耗費大量的精力去維護（也就是“還債”），留給開發系統新功能的時間就變少了?！猄teve McConnell

在產品開發時需要竭盡全力去避免此類技術負債。如果遇到了，找時間來處理這些欠賬的過程會非常艱難，經?？床坏饺魏胃淖儯瑘F隊內會有一些人不理解這么做的原因，很多人懶得去清理代碼中的這些垃圾。然而，在開發過程中清理這些技術負債恰恰是一項非常重要的工作，如果做不好很可能會摧毀整個體系。

當然，需要注意的是，技術負債并不一定都是壞事，有時技術負債會催生一些強大的功能?？偟脕碚f，新出現的負債是沒問題的，但是長期累積起來的舊賬就不好了。Henrik Kniberg 在他所寫的《Good and Bad Technical Debt》 一文中曾提出一個避免技術負債失控的好方法，那就是引入了債務上限的概念，當你的負債達到一定限額時需要采取措施以避免進一步失控：

當債務達到上限時，我們就宣布進入“負債緊急狀態”，停止開發新項目，所有人都將注意力放在清理舊代碼中的問題，直到回歸到基準線。

理論上在每個開發周期中你都會遇到技術負債，但是當負債達到上限時，就需要及時調整，以免事態惡化。

權衡三方面需求

收集用戶需求、商業需求和技術需求只是產品開發中一部分工作，更重要的是如何處理這些信息，平衡三方面需求。這時我們應該主要考慮以下三個要素：

產品在生命周期中所處的階段。這是一款全新的產品，還是已經問世一段時間的產品？

用戶獲取情況。你們在努力吸引用戶的階段，還是用戶會自己找上門來使用你們的產品？

公司的財務狀況。你們是在想方設法掙錢的階段，還是已經有了穩定的收入？

這三個要素的組合不同，你關注的重點應該也不一樣。如果是一款正在努力獲取用戶的新產品，那么你就需要十分關注用戶需求；如果公司在尋求大規模良性的增長，那你就需要把重點放在盈利上。

最后，需要強調的是：如果不理解產品的核心用戶的需求以及商業上、技術上的需求，那你的產品就是建立在虛無之上的。一款產品可能在一段時間如日中天，但最終肯定會有新的產品出現。所以不要把你的產品建立在危險的假設之上，開發產品時做到深思熟慮，努力開發出可持續的產品。