“戰略規劃+需求挖掘”，講完“滿足什麼需求？”，本篇講講產品經理的“靈魂拷問”：需求如何滿足？
我把拷問二的解答過程抽象為兩大模組：產品設計和迭代規劃，本篇先講產品設計。
前面提到：“需求挖掘”過程中，產品經理需要對來自四面八方的需求進行分析、討論，有時還需要結合相關的調研與實驗結果，以確定需要在產品中滿足的需求，輸出相應的使用者故事（作為一個<角色>, 我想要<活動>, 以便於<價值>）。
在該過程中，重點在於明確具體場景中存在的問題，或者說使用者期望獲得的價值（即使用者故事中的<價值>），而相應的問題解決方案（即使用者故事中的<活動>），則往往僅作概述性定義，因而需要在“產品設計”過程中進一步明確、細化。
例如一個知識付費產品，為了提高使用者查詢意向內容的成功率與效率，計劃最佳化內容搜尋功能，支援正文內容的搜尋，並讓搜尋結果根據內容匹配度與熱度排序……
像這樣的需求描述，似乎已經很具體了？這對於使用者來說確實已足夠明確，因為使用者最關心的是從產品功能中獲得的價值，略關心獲得價值的方式，至於具體的實現細節，則毫不在意也沒有必要在意。
但對於企業團隊來說，這樣的描述就像一篇文章的標題而已，具體的實現細節才是“正文”，決定著該需求的使用者期望與企業期望是否達成，也影響著運營與開發等團隊成員對需求的理解與執行。
如果你把這“一句話需求”甩給研發同事，你會看到他們滿頭問號：正文內容的搜尋匹配規則如何定義與管理？搜尋結果排序邏輯如何定義與管理？搜尋結果是否需要分頁？是否需要考慮敏感詞？還有樣式、互動，甚至效能等要求……（實際上，對於較大規模體量的產品，該需求甚至意味著一個“推薦搜尋團隊”的成立）。
我們可以把產品設計過程視為對使用者故事中<活動>的具象化，以輸出具體的、能“友好”達成需求價值目標的功能設計方案。該階段具體產出物需支援需求方、研發團隊、運營團隊等相關方進行高效溝通與業務執行。
明確了產品設計的具體目標，相應的產品設計過程自然也基於目標展開。因業務類別、產品階段或企業資源等差異，產品設計過程並沒有所謂“最正確”的“套路”，只有基於具體需求與團隊自身情況的“相對正確”。
估計有一定專案經驗的產品經理也大都會熟能生巧地形成自己的產品設計方法，我也試圖抽象出產品設計階段的具體過程與過程輸出，把整個過程分解為四個部分：流程設計、功能架構、資訊架構、原型設計。
在“需求挖掘”過程中，我們定義了使用者需求，對透過產品帶給使用者的<活動>作了概述。而要讓<活動>具象化，必然需要對<活動>的具體流程或所在流程作梳理。
實際上，在“需求挖掘”階段，對需求活動流程的思考就已經開始了，但更多隻是對使用者流程的分析，也即我們常說的使用者路徑或使用者體驗地圖，純粹關注使用者視角，且往往僅是“一句話描述”。而在輸出具體的產品設計方案過程中，則需要考慮使用者與系統間、系統與系統間的具體互動過程。
這一方面要求產品經理在設計使用者的功能使用路徑時，準確把握使用者情緒的變化，產品上每個服務觸點都可能影響使用者對產品的感覺。另一方面也要求產品經理結合業務與企業背景及系統實現原理，以更高效能的關聯需求流程與系統流程來支援使用者體驗流程的運作。
比如一個“線上商城”新增派發“支付抵現紅包”，你除了得設計一個能讓使用者紅包領得爽、用得爽，邀請機制也爽的使用者使用流程，還得考慮運營管理端的紅包派發管理流程，以及功能具體實現的系統流程，如系統的互動時序，解答類似於使用者支付時的紅包扣減訊息該同步還是非同步這樣的問題。
流程設計方案的輸出可以用UML（統一建模語言）規範的多種圖來呈現，比如比較常用的活動圖、狀態機圖、順序（序列）圖等，相較於傳統的“流程圖”，UML建模更規範、全面，很適合對複雜業務流程的梳理與表達（關於UML建模，可自行查閱相關資料或圖書學習，如Joseph Schmuller的《UML基礎、案例與應用》等，建模工具可用Astah、ProcessOn等完成）。
當然最終以什麼方式來表達還得視具體場景而定，假設是面向C端產品使用者的客戶訪談，可能以傳統的流程圖、甚至是帶互動效果的原型圖來表達會更便於客戶理解。但如果是面向研發團隊的需求文件，則建議PM們在資源允許下，儘可能規範、完整地用UML來建模說明流程方案，並作為流程驗收的標準，減少因文字或口頭表達的偏差導致需求理解偏差，進而影響研發進度。
每個<活動>都意味著在產品中新增功能或調整某些原有功能，而除了具體功能流程的設計外，功能的劃分以及功能之間的從屬關係也影響著使用者對產品服務的感知與使用。可以說，產品的功能本身決定“產品能不能用”，產品的功能架構影響“產品好不好用”。
比如微信的影片號如果哪天跳脫出“發現”模組，而出現在了“底導”上，可能部分完全無“公廣或檢視短內容”需求的使用者就不開心了，因為你把一個他們不需要的功能放在了最明顯的位置上，帶來了不必要的干擾。
而如果影片號變成了微信幾百萬個小程式之一，不再是獨立功能、也無常駐入口，儘管具體功能體驗完全一致，但“影片號”對於使用者的感知，馬上從會“短內容公眾分享平臺”變成“某第三方在微信折騰的‘小抖音’”……
你會發現，功能架構帶給使用者的影響主要還是是因為改變了使用者的功能使用路徑，跟流程設計是有所耦合的。但視角不一樣，流程設計更多是聚焦在具體的某個“流程”。而功能架構則是基於功能模組或整個產品、產品線，甚至是企業的整個“大產品”，重點關注功能間的關係。除了影響當前使用者需求的滿足，“更科學”的功能架構也能讓產品後續的功能延展及迭代更順暢一些。
比如還是上面“線上商城”的例子，現在又要新增一種“紅包”，如果新增的紅包除了多了“可用商品品類”的使用條件差異之外，其他功能需求與前者完全一致。那這就只是“紅包”類里加個屬性，沒有必要新增一個與前者並列的紅包功能。
但如果新增的“紅包”不再是“支付抵現”，而是直接給使用者發現金，具體紅包配置資訊也有很大差異，那一個獨立的“現金紅包”功能在此則顯得更恰當一些。而如果某天企業意識到，像這樣相似或不相似的、複雜或簡單的營銷活動將成為運營團隊長期持續的需要，這時相較於一次次地定製開發獨立的功能模組，一個有更強擴充套件性的統一營銷管理平臺就顯得更有長遠價值，當然這也意味著需要更全面地探討潛在的營銷活動模式。
所以功能架構並不是簡單地根據功能的相關性進行聚合或拆解，而需要兼顧使用者的功能使用路徑，兼顧企業的系統迭代需要。功能架構過程與流程設計過程沒有絕對的先後，更多是協同推進。
至於過程輸出，功能結構圖是表達功能架構方案的主要形式。
使用者對產品功能服務的理解與使用，非常依仗於產品所承載的資訊（包括：文字、圖片、影片、音訊等所有能透過產品讓使用者感知的內容）。資訊架構的目標是透過架構出準確的資訊內容與合理的資訊呈現形式，建立產品與使用者間的高效溝通，讓使用者最低思考成本與操作成本地完成我們希望Ta做的事情。
關於“準確的資訊內容”，我們往往會藉助結構化輸出的資訊架構圖，遍歷所有需求功能及相應介面中會涉及的資訊。除了基於實際需要來羅列資訊內容，還需對資訊資料作進一步的詳細描述（如資料型別、欄位長度、是否必填、預設值、資料來源……），輸出類似於“資料字典”但又更易於與業務溝通的表格（我暫且喊ta為資訊說明表）。當然有的PM會習慣於輸出用例圖與類圖來表達。
關於“合理的資訊呈現形式”，這實際是視覺化產品設計的專屬，可以理解為對頁面資訊元素的規劃佈局，例如介面導航的型別選擇與佈局等。
目前行業內也形成了一些具體的介面資訊架構的方法或原則，例如：合理地安排介面資訊層級，突出有限的（最好就一個）關鍵資訊；資訊相關度聚合原則；如果是手機端的產品還會考慮最佳手勢操作區域等。這些“套路”的背後都是對使用者心理的把握，這一點在產品設計過程裡可謂貫穿始終。
可能部分讀者在看到“資訊架構”的最後一段時會困惑：“這不就是原型設計麼？”
實際這得看你怎麼定義原型設計咯。如果你把原型設計定義為“線框圖設計”，那倒確實是對的。但個人本篇所描述的“原型設計”過程，涵蓋範圍則會更廣一些：介面資訊結構、互動流程（包括具體的介面操作邏輯與介面流轉規則）、互動效果、視覺效果等，都是“原型”這個詞所覆蓋的。原型設計就是對需求流程、功能結構與資訊結構的最直觀化表達。
當然，在實際工作中，產品與設計團隊很可能不會如此周全地輸出高保真原型圖，更不會待如此高保真的原型輸出後，再與需求方等確認需求方案。實際情況可能是帶關鍵功能說明的低保真原型圖，附加關鍵的業務流程圖整合到文件裡，再配上若干句需求背景描述或資料，即呈上那爭分奪秒的需求計劃會的討論之中。
這有些時候是合理的，但也需注意適時適度地完善設計方案。如果盲目為了追求快速迭代而過份壓縮產品設計過程，而後因考慮不周而有所疏漏，後續再改需求，實際效益自然不增反降，這就是我常說的“偽敏捷”現象。
另外，原型設計階段還是要求產品經理對互動設計、視覺設計有較深認識的，尤其是C端產品設計。相信經常玩弄各種網際網路產品的你，也沒少被各種反人類的互動體驗鬧得砸手機（儘管功能本身可能是你需要的、能解決你問題的，比如某些銀行App），下次砸完記得想想：“讓你難受的點是什麼？如果讓你著手改進，你會怎麼做？如何專業地表達這麼做的緣由？”
尤其最後一個問題，正是讓你平時能遊刃有餘說服設計獅、程式猿們的理據，多積累點專業知識，“撕”起來也有勁點、高效點吧？
“產品設計”真不是簡單對著競品畫畫原型圖的事。
基於戰略與使用者需求，兼顧創新與可用資源，從使用者流程到系統流程，從功能結構到資訊結構，從互動到視覺，這才算是解答“需求如何滿足？”的正確姿勢，把“使用者需求”轉化成“產品需求”。而原型和文件只是產品設計過程的產物，讓你與需求方、企業團隊等更高效溝通而已。
比如說，用於溝通迭代計劃，下篇“迭代規劃”篇就會分享相關內容。
本文由 @RuizLin24 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議