“用戶體驗五要素”相信大家都很熟悉，本文將結合「用戶體驗五要素」，聊聊作者對B端產品設計五要素的一些看法，希望對你有所啟發。

結合「用戶體驗五要素」，我也來聊下我對B端產品設計五要素的一些看法。

一、角色目標

用戶是誰，他/她的崗位職責是什么，在履行職責時遇到了什么問題，為什么會有這些問題，沒系統賦能之前，他/她是怎么解決這些問題的。

系統是為人服務的，為誰服務，需要充分識別出涉及的相關方，搭建整個系統服務的用戶群體畫像。

梳理相關方時，需要逐一深入了解各相關方的崗位職責（目標）、痛點（背景+問題點+當前解決方案），最終形成完整的用戶畫像體系，方便管理各相關方預期的同時，也更高效地解決用戶的痛點、癢點及各流程事項的卡點。

在進行用戶調研時，需要根據對方的崗位職責及工作內容代入到對方的視角中，比如跟財務聊，財務的工作是確?？铐椪_入賬，你就不用糾結合同是否可以簽的業務領域問題了。

在了解用戶的痛點時，需要進一步了解目前沒有系統支撐時，他是怎么解決這些問題的，是忽略這些問題，還是用效率較低的方式支撐著解決這些問題。

一般來說，優先處理后者，因為前者目前處于被忽略的狀態，而業務還能正常運轉，要么是發生的概率極低，要么是即使發生了，對業務的運轉也沒啥影響，屬于重要（或不重要）/不緊急的事情。

完善好用戶畫像之后，需要讓用戶自行確定優先級，以確保能管理好用戶的預期。

調研完所有相關方，完善好整個用戶畫像體系之后，需要綜合對比考慮，從公司戰略、相關方話語權、ROI等角度對所有相關方的訴求進行優先級的排序及溝通確定。

資源總是有限的，需求總是做不完的，而B端產品涉及的相關方又太多，有人的地方就有江湖，常見的如下：

1. 相關方之間的訴求是沖突的，如銷售管理型的CRM，銷售總是希望“自由點”，而管理者總是希望了解銷售的一舉一動，以便做好人員的管理。
2. 相關方的訴求是一致的，但優先級可能會有沖突，如：技術部分不甘于淪為成本部門，就希望做的CRM系統可以通過一系列營銷工具帶來更多的營收，而業務部門卻認為只需要管好銷售及內部流程即可，營銷的事情不需要操心。其實站在公司的角度，兩者的訴求都是合理的訴求，而且也肯定會朝著這些目標前進，只是需要分階段實現，而先實現哪個，則需要進行充分的溝通討論及協調。

產品經理不便于卷入這種“江湖斗爭”，不然做事就會比較被動，所以需要拉齊所有相關方，就需求優先級及階段目標達成共識，這樣就可以與各相關方做好工作上的協同，保證整個開發節奏的穩定性。

二、產品目標

產品的長遠目標及階段性目標各是什么？

其實在第一階段識別角色目標進行用戶畫像體系構建之前，對產品目標應該已經有初步的了解了，但還不是定稿狀態。

如：CRM（Customer?Relationship?Management，客戶關系管理）分好幾種類型：

營銷型CRM：重在通過更多的營銷活動來帶更多的客戶；

分析型CRM：重在通過數據分析洞察客戶，提升客戶的轉化率；

銷售管理型CRM：重在對銷售的管理，提升人效，降低成本；

可能長遠目標，CRM系統會把這些范圍都覆蓋，但有一定的時間周期，需要拆分成多階段目標逐步實現。而各階段目標，則是相關方們battle的結論。

Battle完之后，確保大家對產品的長遠目標及各階段性目標達成共識，就可以確定產品調性，明確產品的邊界，更好地達成各相關方訴求及產品目標。

每個人提的訴求都是一個個碎片化，我們需要根據達成共識的階段性目標，兼顧長遠目標將這些碎片串起來，從點到線再到面，這樣產品的藍圖就出來了。

藍圖的繪制是很有必要的，代表了對產品的想象力，平時做需求也會考慮到后續的拓展性，方案更加系統化，也可以跟大家同步產品的迭代方向及迭代節奏，管理好各方預期。

藍圖沒有定稿一說，產品是迭代出來的，不是規劃出來的，所以不用因為迭代方向跟藍圖的差異有點大而感到沮喪，及時根據各方因素更新藍圖即可。

三、ER建模

確定了產品邊界之后，就可以進行ER建模。

什么是ER建模呢？

其實我們B端產品，更多地是需要遵循物理世界的運行規律，將物理世界抽象為計算機可以識別的模型，來支撐物理世界中所發生業務的運轉，抽象的這個過程就叫ER建模，ER建模的產物就是ER圖。

ER圖的組成部分有實體、實體屬性、實體間的關系：

• 實體：我們要管理的對象，如：客戶、聯系人、跟進記錄等等，抽象實體時有個小技巧：數據有唯一的ID，后續可能會通過ID查找該數據的，就可以定義為實體。
• 實體屬性：該實體所具備的一些重要特性，豐富一下實體的畫像，對實體有更清晰的定義。如客戶，有客戶名稱、納稅人識別號等等屬性，這樣就可以明確該客戶是一個公司，而不是C端個體。
  不同實體可能會有相同的屬性，如：線索跟客戶都有聯系人姓名，都是記錄該實體的聯系方式，不必太過于避諱，只要確保實體的畫像足夠豐滿、清晰即可。
• 實體關系：為了表示實體之間的關聯關系，如跟進記錄，是要跟客戶關聯還是跟聯系人關聯，完全是兩種不同的業務模式。怎樣的關聯，1對1，還是1對N，即1個客戶關聯1條跟進記錄還是N條，也是兩種不同的業務模式。

示例如下：

1個客戶下面可以創建N個聯系人，一個聯系人可以有多條跟進記錄，即客戶的跟進記錄掛在聯系人下面，而不是客戶下面。建完模之后，整個業務場景就比較清晰了。

準確的ER圖，可以提升自己對業務的認識，提高與用戶及研發的溝通效率，也可以指導研發的數據建模：研發的數據庫就是一張張excel表，通過“ID”將多個表關聯起來做各種邏輯計算，從而滿足系統中的各種數據運算，滿足用戶的需求。

四、事項流程及節點目標

B端產品很大一部分內容就是對各個實體進行各種邏輯判斷、算術運算及增刪改查等操作，對1個或N個實體進行流程審批、知會，從而支持發生在物理世界的業務運轉。

幾乎所有的B端產品都有一個特點：審批事項多、審批流程冗長。

審批流程本意是為了規范管理，但基本都會被層層加碼：

1. 審批者的安全感：不履行自己審批的職責，迫于公司規定的管理職責，又不能把審批節點去掉，故在自己審批節點前面加上自己的下屬，讓下屬做事項的審批工作，有了下屬的認真審批，自己就可以“盲審”。
2. 因為某些低概率事件的發生而開設的審批流，比如外勤打卡審批，就因為出現部分人躺在家里打卡，而設立的外勤打卡審批流程，讓其上級進行管理監督。其實大可不必為了部分人的作惡而一棒子打死所有人，可以讓系統判斷，一段時間內在同個地點打卡多次就給相關人員預警提醒，人為判別是否為正常的商務活動即可。
3. 領導變動或者管理重點變動：隨著業務的發展，領導的人事調動或者管理重點也會隨著變動，以支撐業務的運轉。兩者的共同點基本都是只會增加流程，不會刪減原有的流程。因為在他們看來，目前的流程制度支撐了業務的正常運轉，刪減現有流程還得去排查是否會帶來其他影響，刪減了之后不出事還好，出事了就是自己的問題了，反正又不需要自己干活，權衡之下，就會在現在的流程上，疊加自己想要的流程，導致流程越來越多。

基于以上背景，我們需要對每個流程及流程上的每個節點都了解清楚，能用系統判斷的，則無需人為核驗，“如非必要，勿上流程，勿增節點”。

順便提一下B端產品的價值，C端產品可以有用戶量、活躍度等明確地指標體現產品及各迭代的價值，但B端產品是支撐業務發展及運轉的，價值往往難以估量，導致B端產品經理的價值無法得到認可，比較枯燥。

冗長的內部流程往往是企業內部常見且頭疼的現象，如果我們可以統計各流程所花時間及駁回率，通過技術手段及邏輯方案降低流程時長及駁回率，就可以大大提升企業內部的流程效率，這就是B端產品最好的價值體現。

五、故事地圖及方案設計

經過了前面四個步驟的摸索之后，我們對用戶體系及業務基本盤也基本摸清了，原則上可以開始設計方案了。

但因為之前梳理的都是枝干，很多細節會有所遺漏。而細節，往往是最影響用戶體驗及使用效率的，所以在設計方案之前，需要梳理一下故事地圖，進一步挖掘用戶痛點、癢點及卡點。梳理故事地圖時，踩過幾個坑：

• 把它放在第一個環節，那時候對用戶、對業務都不熟悉，導致溝通效率比較低下，用戶也會質疑你的專業能力。
• 把故事地圖跟業務流程圖混在一起，導致整個故事地圖比較混亂，達不到了解用戶痛點、癢點、卡點的目的。
• 將多個用戶的故事雜糅在一起，整個故事線比較割裂。

截取部分反例：多用戶的故事雜糅在一起及太偏向于業務流程。

脫敏之后，截取部分正確的例子：一個用戶角色、一個故事梳理出一張故事地圖。

用戶故事地圖主要是為了更直觀地了解用戶目標、為了達成目標做出的一系列動作，做動作時接觸到的點及整個過程的情緒波動，以便與用戶達成共識，更好地站在用戶的角度解決問題。

故事地圖重在梳理整個事項閉環中用戶的情緒變動，所以應該從用戶兼顧事項閉環的角度繪制故事地圖。

如果用戶有多個故事，可以用多個故事地圖表示，如：銷售的售前->售中->售后是一個完整的故事閉環，寫周報是一個完整故事閉環。這樣就可以用兩個故事地圖來記錄，甚至售中可能涉及多個流程，也可以將一些復雜的流程單獨作為一個故事地圖。

總而言之，B端產品是一個多事項流程、多用戶參與的“混亂性”系統，不需要強硬地雜糅到一張故事地圖里面，能直觀記錄及表達用戶情緒即可。

梳理完故事地圖，對用戶的細節更加清楚之后，就可以來設計原型方案了。

設計原型時，可以按照“用戶體驗五要素”的思路逐步完成：

1. 戰略層：講清楚需求的背景及目標，讓研發團隊更加了解業務，提升溝通效率。
2. 在講目標時，如果是一個稍微復雜的方案，最好是用流程圖表達整個方案的邏輯判斷點，“千言萬語不如一張圖”，先讓研發小伙伴腦海里有個大致印象：要做什么、怎么做。

范圍及結構層：用思維導圖梳理需求涉及的改動點，思維導圖的層級就可以表現出結構層。

框架層：設計原型方案及PRD文檔。

B端產品的特點是頁面也比較多，實體與實體之間的邏輯檢驗比較復雜，與其他系統交互也比較多，且復雜度是個增量的事情，經常需要回顧歷史邏輯，維護起來工程量不小。

之前我是一個版本一個.rp文件，且該.rp文件中的原型及PRD只會保留本次版本要做的內容，把整個.rp文件托管到Axure?Cloud或藍湖等原型托管工具，再分享鏈接給研發即可，研發也就很清楚地知道本次版本的工作內容。

這樣做有個弊端就是我要找到某個頁面的原型，在原有基礎上修改，就會非常難找，需要查找歷史版本記錄，判斷最近哪個版本有改到這個頁面的原型，比較費精力。

有時候找到的并不是最新的原型，如：1.10就有改到這個頁面的原型，但我沒留意，找到了1.5版本的原型，改動起來就比較麻煩，效率比較低。

后面找到了比較高效管理原型的方法，將多個版本的原型集中在一個.rp文件里面：

一級目錄：版本號，二級目錄：需求，三級才是每個需求的戰略層、范圍及結構層、框架層，這樣如果要找到對應頁面的原型，直接查詢即可：

每個需求作為一個目錄維護，顆粒度也比較清晰。開發時，為了避免非當前版本的內容干擾到研發，可以通過項目配置，只托管當前版本的原型到托管平臺中。

以上，就是高效管理Axure原型文件的方式。

產品經理的核心能力不是原型畫的好不好，但原型質量就跟人的外貌一樣，是一個產品經理的門面，太潦草也不好~

總結

綜上所述，我把B端產品設計的思路劃分成了5層：角色目標、產品目標、ER建模、事項流程及節點目標 、故事地圖及方案設計。

每一層的搭建都會影響后續上層的質量，而在搭建上層時，可能也會發現底層的遺漏，可以進行查漏補缺，從而確保整個B端產品的方向正確。