產品經理職責剖析：產品設計

1、“戰(zhàn)略規(guī)劃 +需求挖掘 ” ，講完 “滿足什么需求？” ，本篇講講產品經理的“靈魂拷問” ：需求如何滿足？我把拷問二的解答過程抽象為兩大模塊：產品設計和迭代規(guī)劃，本篇先講產品設計。前面提到： “需求挖掘 ”過程中，產品經理需要對來自四面八方的需求進行分析、討論，有時還需要結合相關的調研與實驗結果，以確定需要在產品中滿足的需求，輸出相應的用戶故事（作為一個角色 , 我想要 活動 , 以便于 價值）。在該過程中，重點在于明確具體場景中存在的問題，或者說用戶期望獲得的價值（即用戶故事中的價值 ），而相應的問題解決方案（即用戶故事中的活動），則往往僅作概述性定義，因而需要在“產品設計 ”過程中進一步明

2、確、細化。例如一個知識付費產品，為了提高用戶查找意向內容的成功率與效率，計劃優(yōu)化內容搜索功能，支持正文內容的搜索，并讓搜索結果根據(jù)內容匹配度與熱度排序像這樣的需求描述，似乎已經很具體了？這對于用戶來說確實已足夠明確，因為用戶最關心的是從產品功能中獲得的價值，略關心獲得價值的方式，至于具體的實現(xiàn)細節(jié)，則毫不在意也沒有必要在意。但對于企業(yè)團隊來說，這樣的描述就像一篇文章的標題而已，具體的實現(xiàn)細節(jié)才是 “正文” ，決定著該需求的用戶期望與企業(yè)期望是否達成，也影響著運營與開發(fā)等團隊成員對需求的理解與執(zhí)行。如果你把這 “一句話需求”甩給研發(fā)同事，你會看到他們滿頭問號：正文內容的搜索匹配規(guī)則如何定義與管理

3、？搜索結果排序邏輯如何定義與管理？搜索結果是否需要分頁？是否需要考慮敏感詞？還有樣式、交互，甚至性能等要求（實際上，對于較大規(guī)模體量的產品，該需求甚至意味著一個推薦搜索團隊” 的成立）。我們可以把產品設計過程視為對用戶故事中 活動 的具象化，以輸出具體的、能 “友好 ”達成需求價值目標的功能設計方案。該階段具體產出物需支持需求方、研發(fā)團隊、運營團隊等相關方進行高效溝通與業(yè)務執(zhí)行。明確了產品設計的具體目標，相應的產品設計過程自然也基于目標展開。因業(yè)務類別、產品階段或企業(yè)資源等差異，產品設計過程并沒有所謂 “最正確 ”的 “套路 ” ，只有基于具體需求與團隊自身情況的 “相對正確 ”。估計有一定項

4、目經驗的產品經理也大都會熟能生巧地形成自己的產品設計方法，我也試圖抽象出產品設計階段的具體過程與過程輸出，把整個過程分解為四個部分：流程設計、功能架構、信息架構、原型設計。在 “需求挖掘 ”過程中，我們定義了用戶需求，對通過產品帶給用戶的 活動 作了概述。而要讓活動 具象化，必然需要對活動 的具體流程或所在流程作梳理。實際上，在 “需求挖掘 ” 階段，對需求活動流程的思考就已經開始了，但更多只是對用戶流程的分析，也即我們常說的用戶路徑或用戶體驗地圖，純粹關注用戶視角，且往往僅是 “一句話描述” 。而在輸出具體的產品設計方案過程中，則需要考慮用戶與系統(tǒng)間、系統(tǒng)與系統(tǒng)間的具體交互過程。這一方面要求

5、產品經理在設計用戶的功能使用路徑時，準確把握用戶情緒的變化，產品上每個服務觸點都可能影響用戶對產品的感覺。另一方面也要求產品經理結合業(yè)務與企業(yè)背景及系統(tǒng)實現(xiàn)原理，以更高效能的關聯(lián)需求流程與系統(tǒng)流程來支持用戶體驗流程的運作。比如一個 “線上商城 ”新增派發(fā) “支付抵現(xiàn)紅包” ，你除了得設計一個能讓用戶紅包領得爽、用得爽，邀請機制也爽的用戶使用流程，還得考慮運營管理端的紅包派發(fā)管理流程，以及功能具體實現(xiàn)的系統(tǒng)流程，如系統(tǒng)的交互時序，解答類似于用戶支付時的紅包扣減消息該同步還是異步這樣的問題。流程設計方案的輸出可以用 UML （統(tǒng)一建模語言）規(guī)范的多種圖來呈現(xiàn)，比如比較常用的活動圖、狀態(tài)機圖、順序（

6、序列）圖等，相較于傳統(tǒng)的 “流程圖 ” ， UML 建模更規(guī)范、全面，很適合對復雜業(yè)務流程的梳理與表達（關于UML建模，可自行查閱相關資料或圖書學習，如 Joseph Schmulle的UML基礎、案例與應用等，建模工具可用 Astah、ProcessOn完成）。當然最終以什么方式來表達還得視具體場景而定，假設是面向 C 端產品用戶的客戶訪談，可能以傳統(tǒng)的流程圖、甚至是帶交互效果的原型圖來表達會更便于客戶理解。但如果是面向研發(fā)團隊的需求文檔，則建議PM 們在資源允許下，盡可能規(guī)范、完整地用 UML 來建模說明流程方案，并作為流程驗收的標準，減少因文字或口頭表達的偏差導致需求理解偏差，進而影響研

7、發(fā)進度。每個 活動都意味著在產品中新增功能或調整某些原有功能，而除了具體功能流程的設計外，功能的劃分以及功能之間的從屬關系也影響著用戶對產品服務的感知與使用?？梢哉f，產品的功能本身決定 “產品能不能用 ”，產品的功能架構影響 “產品好不好用 ” 。比如微信的視頻號如果哪天跳脫出 “發(fā)現(xiàn) ”模塊，而出現(xiàn)在了 “底導 ”上，可能部分完全無 “公廣或查看短內容”需求的用戶就不開心了，因為你把一個他們不需要的功能放在了最明顯的位置上，帶來了不必要的干擾。而如果視頻號變成了微信幾百萬個小程序之一，不再是獨立功能、也無常駐入口，盡管具體功能體驗完全一致，但 “視頻號 ”對于用戶的感知，馬上從會短內容公眾分

8、享平臺”變成某第三方在微信折騰的 小抖音”你會發(fā)現(xiàn)，功能架構帶給用戶的影響主要還是是因為改變了用戶的功能使用路徑，跟流程設計是有所耦合的。但視角不一樣，流程設計更多是聚焦在具體的某個 “流程” 。而功能架構則是基于功能模塊或整個產品、產品線，甚至是企業(yè)的整個 “大產品 ” ，重點關注功能間的關系。除了影響當前用戶需求的滿足， “更科學 ”的功能架構也能讓產品后續(xù)的功能延展及迭代更順暢一些。比如還是上面 “線上商城 ”的例子，現(xiàn)在又要新增一種 “紅包 ” ，如果新增的紅包除了多了 “可用商品品類”的使用條件差異之外，其他功能需求與前者完全一致。那這就只是 “紅包”類里加個屬性，沒有必要新增一個與

9、前者并列的紅包功能。但如果新增的 “紅包”不再是“支付抵現(xiàn) ” ，而是直接給用戶發(fā)現(xiàn)金，具體紅包配置信息也有很大差異，那一個獨立的 “現(xiàn)金紅包 ”功能在此則顯得更恰當一些。而如果某天企業(yè)意識到，像這樣相似或不相似的、復雜或簡單的營銷活動將成為運營團隊長期持續(xù)的需要，這時相較于一次次地定制開發(fā)獨立的功能模塊，一個有更強擴展性的統(tǒng)一營銷管理平臺就顯得更有長遠價值，當然這也意味著需要更全面地探討潛在的營銷活動模式。所以功能架構并不是簡單地根據(jù)功能的相關性進行聚合或拆解，而需要兼顧用戶的功能使用路徑，兼顧企業(yè)的系統(tǒng)迭代需要。功能架構過程與流程設計過程沒有絕對的先后，更多是協(xié)同推進。至于過程輸出，功能結

10、構圖是表達功能架構方案的主要形式。用戶對產品功能服務的理解與使用，非常依仗于產品所承載的信息（包括：文字、圖片、視頻、音頻等所有能通過產品讓用戶感知的內容）。信息架構的目標是通過架構出準確的信息內容與合理的信息呈現(xiàn)形式，建立產品與用戶間的高效溝通，讓用戶最低思考成本與操作成本地完成我們希望Ta做的事情。關于 “準確的信息內容” ，我們往往會借助結構化輸出的信息架構圖，遍歷所有需求功能及相應界面中會涉及的信息。除了基于實際需要來羅列信息內容，還需對信息數(shù)據(jù)作進一步的詳細描述（如數(shù)據(jù)類型、字段長度、是否必填、默認值、數(shù)據(jù)來源），輸出類似于數(shù)據(jù)字典”但又更易于與業(yè)務溝通的表格（我暫且喊ta 為信息說

11、明表）。當然有的 PM 會習慣于輸出用例圖與類圖來表達。關于 “合理的信息呈現(xiàn)形式” ，這實際是可視化產品設計的專屬，可以理解為對頁面信息元素的規(guī)劃布局，例如界面導航的類型選擇與布局等。目前行業(yè)內也形成了一些具體的界面信息架構的方法或原則，例如：合理地安排界面信息層級，突出有限的（最好就一個）關鍵信息；信息相關度聚合原則；如果是手機端的產品還會考慮最佳手勢操作區(qū)域等。這些 “套路 ”的背后都是對用戶心理的把握，這一點在產品設計過程里可謂貫穿始終?？赡懿糠肿x者在看到 “信息架構 ”的最后一段時會困惑： “這不就是原型設計么？ ”實際這得看你怎么定義原型設計咯。如果你把原型設計定義為 “線框圖設計

12、 ” ，那倒確實是對的。但個人本篇所描述的“原型設計 ”過程，涵蓋范圍則會更廣一些：界面信息結構、交互流程（包括具體的界面操作邏輯與界面流轉規(guī)則）、交互效果、視覺效果等，都是 “原型 ”這個詞所覆蓋的。原型設計就是對需求流程、功能結構與信息結構的最直觀化表達。當然，在實際工作中，產品與設計團隊很可能不會如此周全地輸出高保真原型圖，更不會待如此高保真的原型輸出后，再與需求方等確認需求方案。實際情況可能是帶關鍵功能說明的低保真原型圖，附加關鍵的業(yè)務流程圖整合到文檔里，再配上若干句需求背景描述或數(shù)據(jù)，即呈上那爭分奪秒的需求計劃會的討論之中。這有些時候是合理的，但也需注意適時適度地完善設計方案。如果盲目為了追求快速迭代而過份壓縮產品設計過程，而后因考慮不周而有所疏漏，后續(xù)再改需求，實際效益自然不增反降，這就是我常說的 “偽敏捷 ”現(xiàn)象。另外，原型設計階段還是要求產品經理對交互設計、視覺設計有較深認識的，尤其是C 端產品設計。相信經常玩弄各種互聯(lián)