從“用戶體驗五要素”推導為“B端產品設計五要素”
“用戶體驗五要素”相信大家都很熟悉,本文將結合「用戶體驗五要素」,聊聊作者對B端產品設計五要素的一些看法,希望對你有所啟發。
結合「用戶體驗五要素」,我也來聊下我對B端產品設計五要素的一些看法。
一、角色目標
用戶是誰,他/她的崗位職責是什么,在履行職責時遇到了什么問題,為什么會有這些問題,沒系統賦能之前,他/她是怎么解決這些問題的。
系統是為人服務的,為誰服務,需要充分識別出涉及的相關方,搭建整個系統服務的用戶群體畫像。
梳理相關方時,需要逐一深入了解各相關方的崗位職責(目標)、痛點(背景+問題點+當前解決方案),最終形成完整的用戶畫像體系,方便管理各相關方預期的同時,也更高效地解決用戶的痛點、癢點及各流程事項的卡點。
在進行用戶調研時,需要根據對方的崗位職責及工作內容代入到對方的視角中,比如跟財務聊,財務的工作是確保款項正確入賬,你就不用糾結合同是否可以簽的業務領域問題了。
在了解用戶的痛點時,需要進一步了解目前沒有系統支撐時,他是怎么解決這些問題的,是忽略這些問題,還是用效率較低的方式支撐著解決這些問題。
一般來說,優先處理后者,因為前者目前處于被忽略的狀態,而業務還能正常運轉,要么是發生的概率極低,要么是即使發生了,對業務的運轉也沒啥影響,屬于重要(或不重要)/不緊急的事情。
完善好用戶畫像之后,需要讓用戶自行確定優先級,以確保能管理好用戶的預期。
調研完所有相關方,完善好整個用戶畫像體系之后,需要綜合對比考慮,從公司戰略、相關方話語權、ROI等角度對所有相關方的訴求進行優先級的排序及溝通確定。
資源總是有限的,需求總是做不完的,而B端產品涉及的相關方又太多,有人的地方就有江湖,常見的如下:
- 相關方之間的訴求是沖突的,如銷售管理型的CRM,銷售總是希望“自由點”,而管理者總是希望了解銷售的一舉一動,以便做好人員的管理。
- 相關方的訴求是一致的,但優先級可能會有沖突,如:技術部分不甘于淪為成本部門,就希望做的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端產品都有一個特點:審批事項多、審批流程冗長。
審批流程本意是為了規范管理,但基本都會被層層加碼:
- 審批者的安全感:不履行自己審批的職責,迫于公司規定的管理職責,又不能把審批節點去掉,故在自己審批節點前面加上自己的下屬,讓下屬做事項的審批工作,有了下屬的認真審批,自己就可以“盲審”。
- 因為某些低概率事件的發生而開設的審批流,比如外勤打卡審批,就因為出現部分人躺在家里打卡,而設立的外勤打卡審批流程,讓其上級進行管理監督。其實大可不必為了部分人的作惡而一棒子打死所有人,可以讓系統判斷,一段時間內在同個地點打卡多次就給相關人員預警提醒,人為判別是否為正常的商務活動即可。
- 領導變動或者管理重點變動:隨著業務的發展,領導的人事調動或者管理重點也會隨著變動,以支撐業務的運轉。兩者的共同點基本都是只會增加流程,不會刪減原有的流程。因為在他們看來,目前的流程制度支撐了業務的正常運轉,刪減現有流程還得去排查是否會帶來其他影響,刪減了之后不出事還好,出事了就是自己的問題了,反正又不需要自己干活,權衡之下,就會在現在的流程上,疊加自己想要的流程,導致流程越來越多。
基于以上背景,我們需要對每個流程及流程上的每個節點都了解清楚,能用系統判斷的,則無需人為核驗,“如非必要,勿上流程,勿增節點”。
順便提一下B端產品的價值,C端產品可以有用戶量、活躍度等明確地指標體現產品及各迭代的價值,但B端產品是支撐業務發展及運轉的,價值往往難以估量,導致B端產品經理的價值無法得到認可,比較枯燥。
冗長的內部流程往往是企業內部常見且頭疼的現象,如果我們可以統計各流程所花時間及駁回率,通過技術手段及邏輯方案降低流程時長及駁回率,就可以大大提升企業內部的流程效率,這就是B端產品最好的價值體現。
五、故事地圖及方案設計
經過了前面四個步驟的摸索之后,我們對用戶體系及業務基本盤也基本摸清了,原則上可以開始設計方案了。
但因為之前梳理的都是枝干,很多細節會有所遺漏。而細節,往往是最影響用戶體驗及使用效率的,所以在設計方案之前,需要梳理一下故事地圖,進一步挖掘用戶痛點、癢點及卡點。梳理故事地圖時,踩過幾個坑:
- 把它放在第一個環節,那時候對用戶、對業務都不熟悉,導致溝通效率比較低下,用戶也會質疑你的專業能力。
- 把故事地圖跟業務流程圖混在一起,導致整個故事地圖比較混亂,達不到了解用戶痛點、癢點、卡點的目的。
- 將多個用戶的故事雜糅在一起,整個故事線比較割裂。
截取部分反例:多用戶的故事雜糅在一起及太偏向于業務流程。
脫敏之后,截取部分正確的例子:一個用戶角色、一個故事梳理出一張故事地圖。
用戶故事地圖主要是為了更直觀地了解用戶目標、為了達成目標做出的一系列動作,做動作時接觸到的點及整個過程的情緒波動,以便與用戶達成共識,更好地站在用戶的角度解決問題。
故事地圖重在梳理整個事項閉環中用戶的情緒變動,所以應該從用戶兼顧事項閉環的角度繪制故事地圖。
如果用戶有多個故事,可以用多個故事地圖表示,如:銷售的售前->售中->售后是一個完整的故事閉環,寫周報是一個完整故事閉環。這樣就可以用兩個故事地圖來記錄,甚至售中可能涉及多個流程,也可以將一些復雜的流程單獨作為一個故事地圖。
總而言之,B端產品是一個多事項流程、多用戶參與的“混亂性”系統,不需要強硬地雜糅到一張故事地圖里面,能直觀記錄及表達用戶情緒即可。
梳理完故事地圖,對用戶的細節更加清楚之后,就可以來設計原型方案了。
設計原型時,可以按照“用戶體驗五要素”的思路逐步完成:
- 戰略層:講清楚需求的背景及目標,讓研發團隊更加了解業務,提升溝通效率。
- 在講目標時,如果是一個稍微復雜的方案,最好是用流程圖表達整個方案的邏輯判斷點,“千言萬語不如一張圖”,先讓研發小伙伴腦海里有個大致印象:要做什么、怎么做。
范圍及結構層:用思維導圖梳理需求涉及的改動點,思維導圖的層級就可以表現出結構層。
框架層:設計原型方案及PRD文檔。
B端產品的特點是頁面也比較多,實體與實體之間的邏輯檢驗比較復雜,與其他系統交互也比較多,且復雜度是個增量的事情,經常需要回顧歷史邏輯,維護起來工程量不小。
之前我是一個版本一個.rp文件,且該.rp文件中的原型及PRD只會保留本次版本要做的內容,把整個.rp文件托管到Axure?Cloud或藍湖等原型托管工具,再分享鏈接給研發即可,研發也就很清楚地知道本次版本的工作內容。
這樣做有個弊端就是我要找到某個頁面的原型,在原有基礎上修改,就會非常難找,需要查找歷史版本記錄,判斷最近哪個版本有改到這個頁面的原型,比較費精力。
有時候找到的并不是最新的原型,如:1.10就有改到這個頁面的原型,但我沒留意,找到了1.5版本的原型,改動起來就比較麻煩,效率比較低。
后面找到了比較高效管理原型的方法,將多個版本的原型集中在一個.rp文件里面:
一級目錄:版本號,二級目錄:需求,三級才是每個需求的戰略層、范圍及結構層、框架層,這樣如果要找到對應頁面的原型,直接查詢即可:
每個需求作為一個目錄維護,顆粒度也比較清晰。開發時,為了避免非當前版本的內容干擾到研發,可以通過項目配置,只托管當前版本的原型到托管平臺中。
以上,就是高效管理Axure原型文件的方式。
產品經理的核心能力不是原型畫的好不好,但原型質量就跟人的外貌一樣,是一個產品經理的門面,太潦草也不好~
總結
綜上所述,我把B端產品設計的思路劃分成了5層:角色目標、產品目標、ER建模、事項流程及節點目標 、故事地圖及方案設計。
每一層的搭建都會影響后續上層的質量,而在搭建上層時,可能也會發現底層的遺漏,可以進行查漏補缺,從而確保整個B端產品的方向正確。
本文由 @銘創優品 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
不直接使用“用戶五要素”的原因是什么?我的理解是例如角色目標,產品目標本身也可以屬于范圍層,但tob由于人員流程復雜,故把這幾點往前提,單獨作為topic去研究?
感覺產品目標和角色目標得換一下
理論上是這樣的,不同公司不同老板對產品的定位不同,就會影響到產品的話語權~
學習
學習了