“如果我問人們他們想要什麼，他們會說想要一批跑得更快的馬。”這句話據說是福特汽車創始人亨利·福特的名言。人們經常引用它來支援那些未經使用者測試的所謂的創新。這句話其實價值不大，因為福特可能壓根沒說過這句話，而且按照這種思維方式經營公司很可能會在市場上慘敗。
我們應該認識到，把一個沒有經過驗證和測試的 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 平臺上有大量付費使用者，但仍然入不敷出。創始人後來承認，雖然公司開發出了人們真正喜愛的產品，但是團隊在產品上花費得時間過多，沒有留出足夠的時間去關注公司的發展和產品的推廣。
現在很多網際網路產品都希望先獲得儘可能多的使用者，然後再考慮賺錢的事情。但是在我看來，這種並不是做生意的方式。我並不是說一款新產品需要從第一天開始就盈利（當然能做到更好），但是至少你要規劃好能夠帶來穩定收入的業務模式，在做商業計劃時明確公司未來的收入來源。
那麼，公司應該如何獲得收入呢？大多數情況下，我們需要依賴消費者。在“使用者需求”的部分，我們討論過一些調研方法可以幫助你判斷使用者是否願意付費，以及願意支付多少費用。開發產品的過程中，需要聯合公司內的業務擴充團隊、銷售團隊、營銷團隊以及工程團隊，做好兩方面工作：放棄不良收入，追求優質收入。
放棄不良收入
一位古希臘作家曾說過：“收益總是甜美的，即使它來自與欺騙。”（Profit 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)是指公司明知道某種情況並不理想，但是出於種種原因還是做出了妥協（通常是由於預算或時間限制）。儘管這類技術負債也並不是件好事，但是對任何組織來
說，它都是不可避免的，我們需要做的就是將其影響最小化。
對於技術負債來說，我們需要儘可能地減少負面影響，不然就會遇到我們常說的“破窗效應”。
“破窗效應”是犯罪心理學中的術語。用來解釋城市中秩序混亂和破壞公物的行為，其含義是：
城市管理中需要保持各種設施處於良好的狀態，並隨時監控，這樣才能阻止進一步的公物破壞甚至升級成更嚴重的暴力犯罪。
我們可以把軟體比作城市的環境。如果有幾扇窗戶破了（軟體中出現一些糟糕的程式碼），而破窗又沒有儘快修好，那麼很有可能會出現更多破碎的窗戶（人們變得不再關心優質程式碼），繼而環境進一步惡化：垃圾到處出現，擅自佔用空房的人越來越多（程式碼標準普遍下降）。不久之後，所有的窗戶都會破碎。
如果負債擴大到一定程度，公司最終花費在彌補這些漏洞上精力會比用在創造新價值上的還要多。常見的情況就是遺留的程式碼庫往往需要耗費大量的精力去維護（也就是“還債”），留給開發系統新功能的時間就變少了。——Steve McConnell
在產品開發時需要竭盡全力去避免此類技術負債。如果遇到了，找時間來處理這些欠賬的過程會非常艱難，經常看不到任何改變，團隊內會有一些人不理解這麼做的原因，很多人懶得去清理程式碼中的這些垃圾。然而，在開發過程中清理這些技術負債恰恰是一項非常重要的工作，如果做不好很可能會摧毀整個體系。
當然，需要注意的是，技術負債並不一定都是壞事，有時技術負債會催生一些強大的功能。總得來說，新出現的負債是沒問題的，但是長期累積起來的舊賬就不好了。Henrik Kniberg 在他所寫的《Good and Bad Technical Debt》 一文中曾提出一個避免技術負債失控的好方法，那就是引入了債務上限的概念，當你的負債達到一定限額時需要採取措施以避免進一步失控：
當債務達到上限時，我們就宣佈進入“負債緊急狀態”，停止開發新專案，所有人都將注意力放在清理舊程式碼中的問題，直到迴歸到基準線。
理論上在每個開發週期中你都會遇到技術負債，但是當負債達到上限時，就需要及時調整，以免事態惡化。
權衡三方面需求
收集使用者需求、商業需求和技術需求只是產品開發中一部分工作，更重要的是如何處理這些資訊，平衡三方面需求。這時我們應該主要考慮以下三個要素：
- 產品在生命週期中所處的階段。這是一款全新的產品，還是已經問世一段時間的產品？
- 使用者獲取情況。你們在努力吸引使用者的階段，還是使用者會自己找上門來使用你們的產品？
- 公司的財務狀況。你們是在想方設法掙錢的階段，還是已經有了穩定的收入？
這三個要素的組合不同，你關注的重點應該也不一樣。如果是一款正在努力獲取使用者的新產品，那麼你就需要十分關注使用者需求；如果公司在尋求大規模良性的增長，那你就需要把重點放在盈利上。
最後，需要強調的是：如果不理解產品的核心使用者的需求以及商業上、技術上的需求，那你的產品就是建立在虛無之上的。一款產品可能在一段時間如日中天，但最終肯定會有新的產品出現。所以不要把你的產品建立在危險的假設之上，開發產品時做到深思熟慮，努力開發出可持續的產品。
來自：36kr
相關閱讀
評論(1)