結(jié)合「用戶體驗(yàn)五要素」，我也來聊下我對B端產(chǎn)品設(shè)計(jì)五要素的一些看法。

一、角色目標(biāo)

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

系統(tǒng)是為人服務(wù)的，為誰服務(wù)，需要充分識別出涉及的相關(guān)方，搭建整個系統(tǒng)服務(wù)的用戶群體畫像。

梳理相關(guān)方時，需要逐一深入了解各相關(guān)方的崗位職責(zé)（目標(biāo)）、痛點(diǎn)（背景+問題點(diǎn)+當(dāng)前解決方案），最終形成完整的用戶畫像體系，方便管理各相關(guān)方預(yù)期的同時，也更高效地解決用戶的痛點(diǎn)、癢點(diǎn)及各流程事項(xiàng)的卡點(diǎn)。

在進(jìn)行用戶調(diào)研時，需要根據(jù)對方的崗位職責(zé)及工作內(nèi)容代入到對方的視角中，比如跟財(cái)務(wù)聊，財(cái)務(wù)的工作是確?？铐?xiàng)正確入賬，你就不用糾結(jié)合同是否可以簽的業(yè)務(wù)領(lǐng)域問題了。

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

一般來說，優(yōu)先處理后者，因?yàn)榍罢吣壳疤幱诒缓雎缘臓顟B(tài)，而業(yè)務(wù)還能正常運(yùn)轉(zhuǎn)，要么是發(fā)生的概率極低，要么是即使發(fā)生了，對業(yè)務(wù)的運(yùn)轉(zhuǎn)也沒啥影響，屬于重要（或不重要）/不緊急的事情。

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

調(diào)研完所有相關(guān)方，完善好整個用戶畫像體系之后，需要綜合對比考慮，從公司戰(zhàn)略、相關(guān)方話語權(quán)、ROI等角度對所有相關(guān)方的訴求進(jìn)行優(yōu)先級的排序及溝通確定。

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

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

產(chǎn)品經(jīng)理不便于卷入這種“江湖斗爭”，不然做事就會比較被動，所以需要拉齊所有相關(guān)方，就需求優(yōu)先級及階段目標(biāo)達(dá)成共識，這樣就可以與各相關(guān)方做好工作上的協(xié)同，保證整個開發(fā)節(jié)奏的穩(wěn)定性。

產(chǎn)品目標(biāo)

產(chǎn)品的長遠(yuǎn)目標(biāo)及階段性目標(biāo)各是什么？

其實(shí)在第一階段識別角色目標(biāo)進(jìn)行用戶畫像體系構(gòu)建之前，對產(chǎn)品目標(biāo)應(yīng)該已經(jīng)有初步的了解了，但還不是定稿狀態(tài)。

如：CRM（Customer Relationship Management，客戶關(guān)系管理）分好幾種類型：

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

分析型CRM：重在通過數(shù)據(jù)分析洞察客戶，提升客戶的轉(zhuǎn)化率；

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

可能長遠(yuǎn)目標(biāo)，CRM系統(tǒng)會把這些范圍都覆蓋，但有一定的時間周期，需要拆分成多階段目標(biāo)逐步實(shí)現(xiàn)。而各階段目標(biāo)，則是相關(guān)方們battle的結(jié)論。

Battle完之后，確保大家對產(chǎn)品的長遠(yuǎn)目標(biāo)及各階段性目標(biāo)達(dá)成共識，就可以確定產(chǎn)品調(diào)性，明確產(chǎn)品的邊界，更好地達(dá)成各相關(guān)方訴求及產(chǎn)品目標(biāo)。

每個人提的訴求都是一個個碎片化，我們需要根據(jù)達(dá)成共識的階段性目標(biāo)，兼顧長遠(yuǎn)目標(biāo)將這些碎片串起來，從點(diǎn)到線再到面，這樣產(chǎn)品的藍(lán)圖就出來了。

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

藍(lán)圖沒有定稿一說，產(chǎn)品是迭代出來的，不是規(guī)劃出來的，所以不用因?yàn)榈较蚋{(lán)圖的差異有點(diǎn)大而感到沮喪，及時根據(jù)各方因素更新藍(lán)圖即可。

ER建模

確定了產(chǎn)品邊界之后，就可以進(jìn)行ER建模。

什么是ER建模呢？

其實(shí)我們B端產(chǎn)品，更多地是需要遵循物理世界的運(yùn)行規(guī)律，將物理世界抽象為計(jì)算機(jī)可以識別的模型，來支撐物理世界中所發(fā)生業(yè)務(wù)的運(yùn)轉(zhuǎn)，抽象的這個過程就叫ER建模，ER建模的產(chǎn)物就是ER圖。

ER圖的組成部分有實(shí)體、實(shí)體屬性、實(shí)體間的關(guān)系：

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

示例如下：

1個客戶下面可以創(chuàng)建N個聯(lián)系人，一個聯(lián)系人可以有多條跟進(jìn)記錄，即客戶的跟進(jìn)記錄掛在聯(lián)系人下面，而不是客戶下面。建完模之后，整個業(yè)務(wù)場景就比較清晰了。

準(zhǔn)確的ER圖，可以提升自己對業(yè)務(wù)的認(rèn)識，提高與用戶及研發(fā)的溝通效率，也可以指導(dǎo)研發(fā)的數(shù)據(jù)建模：研發(fā)的數(shù)據(jù)庫就是一張張excel表，通過“ID”將多個表關(guān)聯(lián)起來做各種邏輯計(jì)算，從而滿足系統(tǒng)中的各種數(shù)據(jù)運(yùn)算，滿足用戶的需求。

事項(xiàng)流程及節(jié)點(diǎn)目標(biāo)

B端產(chǎn)品很大一部分內(nèi)容就是對各個實(shí)體進(jìn)行各種邏輯判斷、算術(shù)運(yùn)算及增刪改查等操作，對1個或N個實(shí)體進(jìn)行流程審批、知會，從而支持發(fā)生在物理世界的業(yè)務(wù)運(yùn)轉(zhuǎn)。

幾乎所有的B端產(chǎn)品都有一個特點(diǎn)：審批事項(xiàng)多、審批流程冗長。

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

1. 審批者的安全感：不履行自己審批的職責(zé)，迫于公司規(guī)定的管理職責(zé)，又不能把審批節(jié)點(diǎn)去掉，故在自己審批節(jié)點(diǎn)前面加上自己的下屬，讓下屬做事項(xiàng)的審批工作，有了下屬的認(rèn)真審批，自己就可以“盲審”。
2. 因?yàn)槟承┑透怕适录陌l(fā)生而開設(shè)的審批流，比如外勤打卡審批，就因?yàn)槌霈F(xiàn)部分人躺在家里打卡，而設(shè)立的外勤打卡審批流程，讓其上級進(jìn)行管理監(jiān)督。其實(shí)大可不必為了部分人的作惡而一棒子打死所有人，可以讓系統(tǒng)判斷，一段時間內(nèi)在同個地點(diǎn)打卡多次就給相關(guān)人員預(yù)警提醒，人為判別是否為正常的商務(wù)活動即可。
3. 領(lǐng)導(dǎo)變動或者管理重點(diǎn)變動：隨著業(yè)務(wù)的發(fā)展，領(lǐng)導(dǎo)的人事調(diào)動或者管理重點(diǎn)也會隨著變動，以支撐業(yè)務(wù)的運(yùn)轉(zhuǎn)。兩者的共同點(diǎn)基本都是只會增加流程，不會刪減原有的流程。因?yàn)樵谒麄兛磥?，目前的流程制度支撐了業(yè)務(wù)的正常運(yùn)轉(zhuǎn)，刪減現(xiàn)有流程還得去排查是否會帶來其他影響，刪減了之后不出事還好，出事了就是自己的問題了，反正又不需要自己干活，權(quán)衡之下，就會在現(xiàn)在的流程上，疊加自己想要的流程，導(dǎo)致流程越來越多。

基于以上背景，我們需要對每個流程及流程上的每個節(jié)點(diǎn)都了解清楚，能用系統(tǒng)判斷的，則無需人為核驗(yàn)，“如非必要，勿上流程，勿增節(jié)點(diǎn)”。

順便提一下B端產(chǎn)品的價值，C端產(chǎn)品可以有用戶量、活躍度等明確地指標(biāo)體現(xiàn)產(chǎn)品及各迭代的價值，但B端產(chǎn)品是支撐業(yè)務(wù)發(fā)展及運(yùn)轉(zhuǎn)的，價值往往難以估量，導(dǎo)致B端產(chǎn)品經(jīng)理的價值無法得到認(rèn)可，比較枯燥。

冗長的內(nèi)部流程往往是企業(yè)內(nèi)部常見且頭疼的現(xiàn)象，如果我們可以統(tǒng)計(jì)各流程所花時間及駁回率，通過技術(shù)手段及邏輯方案降低流程時長及駁回率，就可以大大提升企業(yè)內(nèi)部的流程效率，這就是B端產(chǎn)品最好的價值體現(xiàn)。

五、故事地圖及方案設(shè)計(jì)

經(jīng)過了前面四個步驟的摸索之后，我們對用戶體系及業(yè)務(wù)基本盤也基本摸清了，原則上可以開始設(shè)計(jì)方案了。

但因?yàn)橹笆崂淼亩际侵Ω?，很多?xì)節(jié)會有所遺漏。而細(xì)節(jié)，往往是最影響用戶體驗(yàn)及使用效率的，所以在設(shè)計(jì)方案之前，需要梳理一下故事地圖，進(jìn)一步挖掘用戶痛點(diǎn)、癢點(diǎn)及卡點(diǎn)。梳理故事地圖時，踩過幾個坑：

• 把它放在第一個環(huán)節(jié)，那時候?qū)τ脩簟I(yè)務(wù)都不熟悉，導(dǎo)致溝通效率比較低下，用戶也會質(zhì)疑你的專業(yè)能力。
• 把故事地圖跟業(yè)務(wù)流程圖混在一起，導(dǎo)致整個故事地圖比較混亂，達(dá)不到了解用戶痛點(diǎn)、癢點(diǎn)、卡點(diǎn)的目的。
• 將多個用戶的故事雜糅在一起，整個故事線比較割裂。

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

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

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

故事地圖重在梳理整個事項(xiàng)閉環(huán)中用戶的情緒變動，所以應(yīng)該從用戶兼顧事項(xiàng)閉環(huán)的角度繪制故事地圖。

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

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

梳理完故事地圖，對用戶的細(xì)節(jié)更加清楚之后，就可以來設(shè)計(jì)原型方案了。

設(shè)計(jì)原型時，可以按照“用戶體驗(yàn)五要素”的思路逐步完成：

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

范圍及結(jié)構(gòu)層：用思維導(dǎo)圖梳理需求涉及的改動點(diǎn)，思維導(dǎo)圖的層級就可以表現(xiàn)出結(jié)構(gòu)層。

框架層：設(shè)計(jì)原型方案及PRD文檔。

B端產(chǎn)品的特點(diǎn)是頁面也比較多，實(shí)體與實(shí)體之間的邏輯檢驗(yàn)比較復(fù)雜，與其他系統(tǒng)交互也比較多，且復(fù)雜度是個增量的事情，經(jīng)常需要回顧歷史邏輯，維護(hù)起來工程量不小。

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

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

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

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

一級目錄：版本號，二級目錄：需求，三級才是每個需求的戰(zhàn)略層、范圍及結(jié)構(gòu)層、框架層，這樣如果要找到對應(yīng)頁面的原型，直接查詢即可：

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

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

產(chǎn)品經(jīng)理的核心能力不是原型畫的好不好，但原型質(zhì)量就跟人的外貌一樣，是一個產(chǎn)品經(jīng)理的門面，太潦草也不好~

總結(jié)

綜上所述，我把B端產(chǎn)品設(shè)計(jì)的思路劃分成了5層：角色目標(biāo)、產(chǎn)品目標(biāo)、ER建模、事項(xiàng)流程及節(jié)點(diǎn)目標(biāo) 、故事地圖及方案設(shè)計(jì)。

每一層的搭建都會影響后續(xù)上層的質(zhì)量，而在搭建上層時，可能也會發(fā)現(xiàn)底層的遺漏，可以進(jìn)行查漏補(bǔ)缺，從而確保整個B端產(chǎn)品的方向正確。