起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品設計 | 如何寫好一份詳細方案設計？
編輯導語：B端產品設計階段分為產品策劃設計階段和產品開發設計階段。本篇文章圍繞產品開發階段中的詳細設計階段進行講解，詳細方案設計是最終產出PRD文檔確保產品落地的重要一項。一起來看看吧。
在B端產品設計階段我們可以拆分成兩個步驟分別是產品策劃設計階段和產品開發設計階段，在以往的文章中我們講述了在產品策劃階段我們通過行業調研與分析確定我們產品的靈魂-產品定位，在產品開發階段我們通過對業務調研與分析去完成產品的骨架設計-產品架構。
接下來我們這篇文章我們圍繞產品開發階段中的詳細設計階段。詳細方案設計解決了具體功能是什么樣的問題，詳細方案設計解決了從業務到技術如何落地的問題，詳細方案設計也解決了客戶如何操作的問題。產品的定位與產品架構設計分別對應了產品的靈魂與骨架，詳細方案設計則對應了產品的血肉，最終產出PRD文檔，確保產品落地。
一、詳細方案設計的流程
詳細方案設計本質是功能模塊設計，是距離產品方案落地的最近的一步。
對于從0到1的產品的功能模塊設計來說，一般我們可以有兩個維度：
第一個是以模塊為單位，匯聚該功能模塊的功能點，所以模塊為單位的設計是一個功能點全集；
第二個是以需求為單位，按照要完成整個需求所需要的功能，再把整個模塊串聯起來，因此以需求為單位是將不同功能模塊的子集或者全集進行聚合。這兩者只是不同的聚合方式本質沒有特別大的區別。
在進行功能模塊設計時的路徑可以分為五步，分別是需求的背景及價值分析、多方需求的均衡、解決方案功能模塊設計、功能模塊的原型及邏輯設計、功能模塊間交互設計。
1. 求的背景及價值分析
在進行產品功能模塊設計時，核心第一步需要對需求進行篩選分析和價值判斷。對需求的提出者/使用者的目標及期望進行分析，不斷清晰要做什么，為什么做，給誰做，明確產品的核心價值。
那如何去分析需求的背景及價值，分析需求背景及價值主要考慮清楚幾個關鍵的問題：
- 這個需求要達成的目標是什么？
- 這個需求的提出者是誰，使用者是誰，這個需求是個誰做的？
- 需求的提出者，使用者，對這個需求的期望是什么？
- 這個需求做了，解決他們什么痛點？
- 這個需求不做，他們如何處理當前的痛點？
- 這個需求是在什么條件下提出來的，有哪些依賴條件？
2. 多方需求的均衡
第二步則需要對多方角色提出的需求進行均衡，需要從商業價值和需求的合理性進行判斷，判斷角色提出的需求是否合理，識別出偽需求進行剔除，并對真需求進行優先級排序，最終明確做哪些功能，先做什么，后做什么，在這個階段我們對應產出物包含了功能模塊設計思路和需求的MVP。
而多方需求的均衡我們主要會從兩個維度去考慮一個是企業角度，另一個則是客戶的角度，在企業的維度主要考慮需求的商業價值，因為企業是需要賺錢的，而賺錢的方式就是需要去從成就我們的客戶，節約我的成本。
成就客戶體現在幫助客戶解決問題，越是客戶需要的問題，在進行過合理性判斷之后，越是我需要去做的事情。而節約成本主要是考慮企業的投入產出比，綜合考慮產品落地成本、開發成本、實施成本、人力成本、時間成本等等。
當然企業所處的階段不同對于成就客戶和節約成本的考慮點也就不同，有時候為了搶占市場，也是可以做一些投入產出比沒那么高的需求，但有時需要考慮落地的成本。這里很大程度會取決于企業所處的局勢來決定和判斷的。
而客戶維度，我們主要考慮客戶訴求的合理性?？蛻舻脑V求是否合理的，能夠給客戶帶來業績的提升、效率的提升、成本的降低、管理的便捷，這樣的需求我們覺得都是合理的，但是合理并不代表我就應該立馬去做，我們還需要考慮這個訴求應該放在哪個模塊，而這個模塊我們放在哪個階段去落地。
只有當客戶的訴求納入到實現這個訴求的模塊，我們才認為這個訴求是一個需求。所以多方需求的均衡是為了明確做哪些功能，先做什么，后做什么。
在客戶角度這里我們還需要深入，因為TOB產品的客戶是企業，而企業有不同的角色比如我們按照職能進行劃分，有業務人員、管理人員、銷售人員、運營人員、財務人員等等。
不同角色對服務該角色的產品訴求都是不一樣的，我們設計SaaS產品的時候，需要考慮不同角色的訴求，考慮不同角色所占的角度，在根據這些角度去考慮合理性：
- 業務角度：是否解決了業務痛點、是否遵從業務流程、是否匹配業務職能劃分、為業務帶來哪些提升；
- 數據角度：沉淀了哪些業務數據、沉淀了哪些主數據；
- 管理角度：客戶使用此功能滿足的管理訴求。
每家企業都是不一樣的，所以觀察問題和深入問題的角度都是不一樣的，這方面沒有百分百的標準，與此同時我們不單單只考慮訴求合理性，我們還需要考慮最佳的實現路徑，因為客戶不同角色對系統的認知都是不一樣的，在調研中我們都知道被調研人往往想一個功能模塊能夠解決他們的所有問題。
所以產品經理需要考慮一個最佳實現的路徑，在考慮最佳實現路徑時，需要考慮功能點的劃分，到底哪個模塊為客戶實現比較合適，要考慮功能一旦實現對其他模塊或者其他客戶角色的影響，要考慮不同角色之間的矛盾點如何調和，要考慮是否有被發現的漏洞。
只有我們產品設計本身需要充分考慮，才能實現真正意義上的需求均衡。
在企業角度我們說過，企業是要賺錢的，我們的產品需要適配更多的客戶，我們要盡量節約研發、運營的成本，企業都想快速的把產品推向市場。
所以在產品設計中我們不可能去極致的追求客戶滿意的，而是在滿足企業商業角度基礎上去追求客戶滿意的，解決客戶最痛的點，而不是完全滿足客戶所有的訴求了，如果全設想滿足了，那產品也演變成定制化了，所以在產品設計時我們站在企業角度需要去考慮：
培養客戶心智：設計是否符合使用心智、是否可以滿足保留客戶對產品粘性、功能點是否滿足客戶付費心智、是否可作為向客戶收費盈利點；
保持合理的適應性：在客戶定制化訴求與產品的抽象能力和擴展性之間尋找平衡點。節約落地成本：是否可以快速落地、研發交付成本是否較低；
但整體均衡時我們優先考慮的是核心痛點的業務閉環，只有產品有了整個基礎才會有客戶使用，之后我們再考慮落地成本及商業訴求最后在考慮客戶滿意度。我們再進行需求梳理時，我們可以借助四象限法和kano模型，最后我們產出功能模塊的設計思路和MVP版本的功能清單。
3. 解決方案的功能模塊設計
第三步對多方需求進行抽象，首先需要拉通多需求方認知，然后基于場景及訴求給出解決方案，最后確定解決方案設計模型所屬領域，通過抽象多方需求，我們將產出關鍵場景的流程圖，狀態流轉圖，頁面跳轉圖，核心數據結構。
在第二步我們均衡了多方的訴求，我們輸出了功能模塊的設計思路和MVP功能清單，知道了我們先做什么后做什么，那么接下來我們根據設計思路和具體的場景結合多需求方的訴求進行產品方案的設計與抽象。
產品方案的抽象是基于具體場景和訴求的，屬于戰術層面的策略抽象。通俗來講就是實現方式，是在完成產品背景與價值分析，多方需求均衡之后啟動的。
在進行多方需求的抽象時，首先我們需要拉通需求方的認知，明確概念和名稱，比如SaaS產品中的租戶與客戶概念。
在拉通認知之后我們就需要基于場景及訴求給出解決方案了，需要有明確的輸入輸出邊界，之后根據我們的解決方案歸屬到對應的領域中，核心是該解決方案需要遵循該領域的規則。最終在這個階段我們產出關鍵場景的流程圖、狀態流轉圖、頁面跳轉圖、核心數據結構圖。
4. 功能模塊的原型及邏輯設計
第四步則是進行原型及邏輯設計了，這個階段基本就是把客戶如何操作講述清楚，也就是我們畫原型的階段了，原型設計又涉及到另外一個比較大的知識板塊，在這里也不做具體闡述了。
以SaaS產品舉例，SaaS產品在原型與邏輯設計中紀要考慮租戶角度，也要考慮企業角度，租戶的角度要考慮方案的差異性，因為租戶業務訴求是多種多樣的，哪怕我們抽象了大部分相同的能力，也會有一定的個性化定制在里面，而在企業角度我們需要考慮我們提供的能力或服務具備通用性，租戶可以在云平臺上完成服務的定制、續訂、退訂等功能。
5. 功能模塊間交互設計
第五步也是最后一步這時候更多考慮的是功能模塊間的交互，他包含了對內交互以及對外交互。同時我們也要考慮到多個系統的耦合，既需要通過API提供對外服務，也需要考慮外部系統獲取相關信息，多系統間的交互，需要考慮信任機制和全新啊；對內交互需要考慮期抽象能力和擴展能力。
同樣我們以SaaS產品跟大家舉例，SaaS產品對外交互我們主要考慮我的客戶的信息化系統現狀，客戶肯定不會只使用其中一家的信息化產品，對于企業客戶來說他們需要一個能夠支撐起管理運營大而全的產品，但這類系統往往是屬于企業的PaaS層產品。
但實際現狀是現有企業都會存在多個業務系統交互去滿足他的業務支撐，所以這類情況SaaS產品既要考慮對外通過API提供服務，也需要考慮從外部系統獲取相關信息。所以我們需要考慮多系統之間的交互，需要考慮信任機制和權限；
二、結尾
通過上述五個步驟之后，我們詳細設計階段就基本算完成了百分之八十了，最終我們需要整理輸出我們這個階段需要輸出的核心產出物PRD文檔。
而如何去寫好一份PRD在這里就不拆開講了，相關性的文章或資料都有很多，PRD并非是完全統一的，可能每家公司寫的都不一樣，但是PRD核心需要包含的一些信息或內容，在這里跟大家分享一份概要，如下圖所示：
本文由 @張二十三 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
文章寫得太好了，很實用
我覺得這個文章寫得不錯，落地性強，確實是可以在實踐中參考的文章
通用性產品怎樣才能快速實現個性化的設計，達到使用者客戶需求！