起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以美容院數字化轉型為例，總結B端產品設計
之前寫過一篇B端產品總結，后來思考了下，覺得很多業務不便公開，因此在此基礎上進行脫敏處理。
為什么想要轉行去做B端
我個人履歷實際上入行以來換過3家公司。對此雖然是劣勢，但是我認為在剛入行對自己職業生涯規劃比較欠缺，所以兩三年內跳槽可能屬于普遍現象。在積累了一定行業經驗之后，對整個行業有了認知，此時就該對自己有明確的定位和發展方向。
我選擇的是to B領域。
原因如下：
- B端重業務，我本身理科出身，之前做C端的用戶體驗方法論個人理解更多是用戶研究和洞察，但B端能更好的以數據、業務為導向去做產品。做了一個tms外包和上家公司的數字化轉型產品，也讓我加深了對這方面的堅持。
- 做了很多2C的產品，發現C端產品對運營要求非常高，但大部分公司投資有限。
- 西安的C端產品不多，發展空間有限。
B端和C端做產品設計的異同
首先來說相同點，B端、C端產品都是要兼顧體驗和業務之間的平衡，我們不能說因為做B端就完全不顧產品的用戶體驗。
再來講差異，個人理解最大的差異主要為兩點：需求來源、對用戶體驗標準不同。
- 需求來源：C端的用戶體驗方法論更多是用戶研究和洞察，通過拉新、促活、留存、轉化率等帶來流量的運營達到營收目的。所以細分領域下有用戶增長、行為數據分析等等來成為需求來源；而B端偏重業務邏輯的實現，更注重效率。所以需求來源基本上來自于業務；
- 對用戶體驗的標準不同：C端針對不同目標用戶、不同場景體驗可能存在不同偏向的差異。B端的用戶由于比較單一，基本是企業用戶，且使用場景為工作，所以用戶體驗核心則是易用、易理解即可。
B端產品設計思路
1. 產品背景調研
（1）了解客戶訴求，與客戶溝通產品期望
和C端產品一樣，在接手B端項目時，第一步都是對產品的背景調研。不同的是，B端的項目第一個要接觸的是客戶。
首先我們需要了解客戶的訴求，他是基于什么樣的想法需要做一個產品，他想要為誰而做等等。其次我們需要引導客戶讓他描述出對產品的期望，在這里注意不能直接問客戶“你想要一個什么樣的產品”。因為這樣做，我們往往不會得到一個全面的答案。
在這個階段，我們訪談的客戶一般都不會是業務需求方而是高層，所以我們不需要得到太細的業務需求。
必須要明確問題有：
- 目標用戶：這個產品為誰而做？
- 出發點：客戶為什么需要做這樣的產品？
- 核心價值：競品為何不可以？
- 需求：產品能夠解決什么樣的需求？
- 目的：希望產品能夠達到什么樣的效果？
做數字化轉型的項目，通過訪談客戶公司的最高領導人了解到，一般是因為公司是一個集團化管控的公司，下屬有門店進行業務營收?？蛻魰硎疽驗楝F在集團旗下分公司都是用傳統的紙質辦公，數據也都是由員工進行上報，對于集團化的監管都不標準并且不規范。所以希望通過數字化平臺解決信息互通、管理規范、數據透明的問題，為門店提升服務質量、業務效率從而為集團帶來更大的收益。
為方便描述，在這里以美容院作為案例進行梳理。
用上面5個問題進行整理則是：
- 目標用戶：這個產品為美容院門店顧客、門店管理人員、集團管理人員；
- 出發點：目前的方式對于集團化的監管都不標準并且不規范；
- 核心價值：競品不夠美觀、在費用計算上不能完全貼合集團的標準化業務；
- 需求：希望通過數字化平臺解決信息互通、管理規范、數據透明的問題；
- 目的：為門店提升服務質量、業務效率從而為集團帶來更大的收益。
（2）行業背景、競品調研
在了解的客戶的訴求后，我們就需要盡快了解對方的行業背景，調研當前市面上的解決方案。
對于美容院使用的數字化管理系統，目前業內較為知名且成熟的養老管理平臺是：美咖、蒼鳥美業等。
對于B端的競品調研的目的主要是讓我們能夠在短時間內迅速掌握競品對于產品的理解、行業內主要的業務模塊有哪些。
（3）利益者相關地圖
在做了行業背景及競品的調研后，下一步是要著手準備客戶公司各崗位的訪談，來了解其職責和業務。
在此之前，我們首先需要對客戶組織架構和管理關系做以了解，以便于站在宏觀角度理解業務，并且能夠為之后排優先級時作為依據。
美容院項目的利益者相關地圖如下：
（4）向部門負責人調研業務期望
梳理完成客戶的組織架構及管理層級關系后，接下來需要對應去找部門負責人進行訪談，在這一階段去了解其部門是負責哪些業務，業務之間存在哪些關系。部門負責人對于產品的愿景如何，他們期望解決自己部門什么樣的問題。
訪談了門店店長、門店經理、美容師后，獲得的信息分別是：
- 店長：可以通過產品了解門店經營狀況，如財務收支、顧客數量、美容護理項目等。
- 經理：產品可以實現顧客預約、發布活動、查看顧客信息、會員營銷跟蹤維護等。
- 美容師：產品能夠查看顧客護理情況，查看預約護理時間，定期維護顧客關系，上傳下達，實現辦公自動化。
- 總部區域經理：能夠對區域內員工進行管理。
- 總部財務：進銷存情況、與財務之間的往來可以在產品中看到。
- 總部總經理：能夠看到各門店的數據，可以查到門店內任何顧客信息。
2. 業務流程調研
（1）崗位角色用戶畫像
了解完項目背景之后，這一階段就需要我們去做業務分析。去和客戶的公司各崗位角色進行訪談，了解對方的崗位職責，越詳細越好。為接下來我們梳理主要業務流程做支撐。
與C端不同，在做B端的用戶畫像時，更偏重該崗位職責。每個訪談時間長度控制在30-50分鐘。
以下以門店角色為例展示用戶畫像：
（2）主要流程分析（跨職責流程圖）
做完用戶畫像后，我們基本能夠明白客戶公司的主要業務是什么，存在哪些重要的流程，在我們做系統設計的時候不能出錯。當我們畫出流程圖后，再去和業務方確認，是否如此，有無需要修改的地方，最終定稿。
以客戶預約護理為例，在此展示流程圖。
3. 產品結構設計
（1）與客戶溝通需求清單并確定優先級
通過各崗位訪談，了解了角色在什么場景有哪些職責，我們已經能夠列出了一個業務需求清單。再加上之前從競品調研中得到的啟示、我們模擬用戶在某幾個場景中的旅程得到的體驗性需求最終建立我們的需求清單。
再把需求清單中的需求與客戶一起逐一對照?KANO 模型進行分級，那么「基本需求」則是我們在MVP中要做的。
在對需求進行簡單的分級之后，我們將「基本需求」、「期望需求」拿給開發，讓他們估一個技術實現成本的點，再呈現給客戶，看他們是否需要修改優先級。
（2）產品結構及業務設計
在客戶確定完MVP的需求清單后，我們就可以針對這些需求開始梳理產品功能架構，以及業務邏輯的設計。這兩項工作是在同期進行的，原因是在考慮某需求時，它需要哪些模塊支撐，這些模塊的關系是什么。
比如在做顧客預約護理時，顧客的需求是查看自己的美容師在某時間段內是否被預約，如果被預約可提供其他空閑的美容師做護理。那么此時我們需要為顧客展示他們不熟悉的美容師的信息，如果顧客預約了這位美容師，我們就需要把該顧客的護理提成轉給被預約的美容師，同時顧客的專屬美容師也會獲取到小部分提成。
對此預約業務，我們在后臺的邏輯設計時則需要建立顧客與美容師的綁定關系、選擇其他美容師部分提成轉移、服務評分轉移、回看提成工資條詳情記錄。
（3）書寫用戶故事
《用戶故事與敏捷方法》對于”用戶故事“的定義如下：
用戶故事描述了對用戶、系統或購買者有價值的功能，用戶故事由以下組成。
- 一份書面的故事描述，用作計劃和作為提示。
- 有關故事的對話，用于具體化故事細節。
- 測試，用于表達和編檔故事細節且可用于確定故事何時完成。
用戶故事的描述信息以傳統的手寫方式寫在紙質卡片上，所以Ron Jeffries(2001)對這三個方面稱為3C：卡片(Card)、對話(Conversation)和確認(Confirmation)。
卡片可能是用戶故事最明顯的表現，但它并不是最重要的。Rachel Davies（2001）說過“卡片代表客戶需求而不是記錄需求”。這是對用戶故事的最佳詮釋：卡片包含故事的文字描述，然而需求細節要在”對話“中獲得，并且在”確認“部分得以記錄。
而一般的，我們把用戶故事的正面格式定為：作為…通過…的操作，以便于達到…的目的。
卡片背面則書寫驗收標準（Acceptance Criteria）。
《用戶故事與敏捷方法》還對于合格故事的定義為：
好的用戶故事除了格式規范，要素完整外，還應該遵循INVEST原則：Idependent（獨立的）；Negotiable（可協商的）；Valuable（有價值的）；Estimatable（可評估）；Small（小的）；Testable（可測試的）。
在這里我舉1個我們在編寫用戶故事的例子：
US-001：作為顧客 ，通過輸入手機號及驗證碼登錄，以便于達到用戶能夠使用登錄后的的服務目的。
AC：
- 新用戶下載APP使用無特殊說明功能無需登錄，使用需要登錄的功能時跳轉登錄頁面；
- 該頁面可進行關閉；
- 使用手機號、密碼進行登錄；
- 手機號不進行位數驗證，手動獲取，向手機發送4位驗證碼；
- 防止重復發送，同一手機號驗證碼重發間隔為60s；
- 驗證碼有時效限制；
- 未輸入手機號、loading超時、驗證碼錯誤，驗證碼超時等需明確提示錯誤原因；
- 錯誤輸入清除后，錯誤提示隱藏；
- 判斷該用戶是否為新用戶，新用戶則跳轉至【喜好】頁；
- 老用戶則登錄成功進入【首頁】。
4. 前后臺交互設計并書寫交互說明
在編寫完用戶故事后，就可以進行交互原型的設計了。我的個人習慣是畫完一個模塊的原型圖后再進行交互說明的書寫。
示例：
前端交互設計完畢后需與客戶進行確認，確認無誤后設計后臺信息架構。如開發需要，根據后臺信息架構進行后臺原型設計。
此處示例后臺信息架構：
五、對開發進行需求講解，測試驗收
到了這個階段，實際上產品設計的工作已經完成了。接下來就是向開發講需求，開發進行開發的工作，直至這張卡完成，他們會找我們來show case，之后我們再拿到這張卡進行測試驗收。
測試這里要具體看團隊的設置，如果團隊中沒有測試，那么測試的工作依然由我們產品部門來做。
一般的，我們會進行3輪左右的測試，第一輪測試后會產生很多的問題，提給開發后他們改一輪。第二次是我們回驗一輪，他們再進行修改。第三輪就是到后面所有的卡已經完成，我們在測試環境及線上環境都跑一遍，如果還有問題，開發再進行集中修復。
本文是我的B端項目進行的思路總結，希望能夠給大家帶來一些幫助，可能會有些不準確的地方，歡迎交流。
作者：babykoala，公眾號：babykoala與產品設計（id：babykoala_fun）
本文由 @babykoala 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
?? 寫的很棒啊，學習了
結合項目經驗完成的B端產品實操手冊（敏捷開發）