起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識萬字長文，詳解B端產品設計指南
本文介紹了B端產品設計的全過程，包括了產品背景分析、需求梳理、需求分析、系統建設等環節。
很多人都說，做B端產品最重的是搞清楚業務邏輯，只要搞清楚業務是怎么運作的，就能做出滿足業務需求的產品。
但是B端產品所處復雜的業務需求環境，如同茂密的森林一樣，產品經理一不小心就會迷失在業務細節中，做出一款停留在業務表面的產品。
導致這種情況的根本原因在于：一個行業花費了幾年甚至幾十年時間建立起來的業務流程與規范，我們很難用一兩個星期完全消化。
面對這樣一個錯綜復雜的場景，產品經理最好的做法是循序漸進，從最粗略的業務目標開始，然后分析業務流程，到各職位的工作內容，最后才是數據、報表的細節。
正如蓋爾定律所言，一個切實可行的復雜系統勢必是從一個切實可行的簡單系統發展而來的，從頭開始設計的復雜系統根本不切實可行，無法修修補補讓它切實可行，你必須由一個切實可行的簡單系統重新開始。
這個由粗到細的過程，就像我們在考察一座古遺址時，首先在外圍繞一圈，通過無人機鳥瞰整個建筑的全貌，對整體輪廓有一個大致的了解；再進入到建筑物內部，將主通道走一遍，將內部結構搞清楚；最后再細致研究每一個區域。
一、產品背景分析
知己知彼，方能百戰不殆。
無論是設計C端產品還是B端產品，首先我們都要對“使用者”進行深入的分析：C端產品直接看用戶特征，為用戶做畫像做分群；B端產品則需需要剖析企業的經營過程，再去看不同使用者的需要。
第一階段的任務是對產品所服務的業務領域有一個概括性的了解。我們可以從行業背景、業務目標與訴求、組織架構、崗位劃分等方面開展研究。雖然第一層次并不足以讓人了解業務具體運轉的邏輯，但是通過業務架構描繪出的一幅業務全景，對于進一步了解需求幫助巨大，這樣就不會迷失在茂密的需求森林中。
1. 目標客群分析
每個產品都有特定的用戶群體，B端產品也不例外。背景分析的第一步，首先我們要搞清楚，產品到底是賣給誰？
做C端產品時，我們習慣用“用戶故事”幫助我們定義用戶類型，做B端產品，同樣我們可以用一個“企業故事”幫助我們理清目標群體的需要。
“目標客群是一家____公司，沒有我們產品之前，他們是這樣工作的：____，當前的工作方式出現了____的問題，因此想要借助我們的產品解決____需要，期望達到____的效果。”
假設我們現在要做一款針對二三線城市房產中介的CRM產品，企業故事可以這樣寫：
產品的目標客戶是二三線城市、中小型的房產中介公司，沒有我們的產品之前，他們主要是采用市面上常見的CRM工具實現客戶管理，但是目前使用的工具沒有針對房產中介的流程做適應，導致流程不規范、有些環節在線上有些環節在線下進行，數據監管不到位，業務員管理混亂等問題，因此想要借助我們的產品規范流程，以達到提升業務質量、提高標準化效率的目的。
通過這個企業故事，我們可以定位到產品針對什么行業、什么規模的企業，然后明確這類公司的核心訴求，將來在做功能與設計的時候可以圍繞著這個核心訴求展開，也是產品不斷更新迭代的方向。
2. 業務目標分析
短短一個企業故事，為我們后續的需求分析有很大的幫助。接下來我們還要做一道選擇題幫助我們理解產品的定位。
我們的產品對企業的重要性如何？
- 生存需要：這個產品關系到公司的生存問題；
- 核心發展需要：這個產品有利于公司提高核心生產力與競爭力；
- 次要發展需要：這個產品對公司的生產或發展不產生重大影響，但有利于公司解決一些具體的問題，幫助公司改善非核心領域的工作，或改善核心領域的工作；
- 錦上添花需要：有這個產品更好，沒有也沒太大關系，可以有其他替代解決方案；
任何一個B端產品，一定是在某個特定的階段滿足企業的某種價值。如果我們的產品直接影響企業的核心業務流程，對企業的生產與銷售有很大的幫助，那么這類產品比較受企業的歡迎，在企業經營的全階段都比較受歡迎，例如各類業務流程系統、部分垂直行業的ERP、CRM等；如果我們的產品是改善企業經營管理類型的，只有當企業成長到一定規模，出現管理需求時才比較受歡迎，例如常見的CMS、OA、HRM等。
這道題相信不難回答，但是能夠幫助我們準確理解產品自身的定位，很多時候對產品的定位越清晰，越容易站在客戶的角度考慮，理解客戶的想法。
戰略分析讓我們對產品做到“心中有數”，接下來的需求分析是我們產品設計的重點。
二、業務分類，需求梳理
在做C端產品時，最重要的步驟是需求分析，也就是思考什么類型的用戶在什么場景下遇到了什么問題。那么在做B端產品時，什么是B端產品的需求分析呢？
這個看似簡單的問題并不那么好回答，很多人認為的B端需求就是幫助用戶完成業務流程所需要做的事情。但這樣的理解并不完整，筆者認為B端的需求包含三種：
- 業務需求：即解決企業運作過程中遇到的問題，業務需求同樣是產品建設的目標；
- 用戶需求：描述的是使用者需要完成什么任務，完成這個任務的過程中遇到的問題；值得注意的是，用戶需求通常是零散且存在矛盾的，用戶會從不同角度、不同層面提出需求，通常都是一句話需求，而且由于用戶處于企業的不同層級，不同部門，難免會出現“盲人摸象”的現象，從而導致需求的片面性；
- 軟件需求：是產品經理對業務需求、用戶需求經過分析、提煉與整理后生成指導開發的需求，是需求分析最終的產物；
需求分析的主要目的是獲得為系統開發提供指導的軟件需求。在此之前，首先我們要做的事情是挖掘業務需求與用戶需求。主要任務是梳理清楚目標客戶群體所有的業務類型，為不同的業務類型劃分清晰的界限，并且梳理出每個業務類型中所有的業務需求與用戶需求。這個過程同時也就是需求澄清的過程。
業務流程分析
業務流程分析就是針對每一項業務事件，分析業務活動的特點，并確定業務活動之間的關系。具體要做的事情是：
- 記錄這些業務活動需要接收哪些信息；
- 記錄這些業務活動將產生哪些數據（報表），并確定數據傳輸的路線；
- 標識出這些業務活動是由哪些部門、崗位在負責；
一個企業的核心價值就是對外部客戶的訴求進行處理，在為客戶創造價值的同時，為企業創造價值。因此由業務事件觸發的流程是分析需求時的核心線索。
在進行流程分析的時候有幾個關鍵要點，一是理解流程的層次性，二是了解流程的類型，三是掌握以業務事件尋找流程的技巧。
（1）流程的層次性
流程有組織級、部門級與崗位級三個層次關系。
- 組織級：是指經過抽象、提煉后的業務事件，是指大方向的業務流向，例如一個產品可能包含生產、銷售、售后服務等組織級的流程；
- 部門級：是指具體每個崗位負責什么活動，以及這些活動之間的關系。例如一個產品在生產階段可能需要原材料部門和加工部門的配合。它是需求分析的主線索，也是流程分析的主要輸出；
- 崗位級：是指每個業務活動具體的操作步驟，可能由某個崗位的一個人或多個人操作，屬于需求細節。
如果我們現在設計一款專門給房產中介的CRM產品，那么在調研業務流程的時候，買賣二手房就是兩個不同的組織級流程，買二手房房會涉及到看房、查檔、簽合同、公證、贖樓過戶等等一系列的流程屬于部門級流程，而在看房時，又涉及到買賣雙方初步洽談價格、付款方式、交房日期等事項確認等步驟，這種屬于崗位級流程。
（2）流程的類型
在一個企業中，根據業務流程的目標可以將其分成不同的類型，一般我們可以分為生產流程、管理流程以及支撐流程三類。
- 生產流程是流程中最重要的部分，也是體現企業價值的業務環節，通常最容易識別；
- 管理流程是對生產流程的管控，通常是對流程效率與質量的監督控制；
- 支持流程是對生產流程的補充，通常是對主流程起支撐作用的環節，非必須但容易忽略。
在這款房產中介的CRM產品中，看房、查檔、簽合同、贖樓過戶這類環節都屬于生產流程。在這個主流程以外，每一個環節都有相應的審核操作，這種流程屬于管理流程。
（3）流程分析的輸出：跨職責流程圖
其實從不同角度來看一個業務流的時候，可能會有很多不同的流程。流程會有大小之分，主流程中可能會有子流程等，因此流程分析是一項龐大的工程，僅僅通過文字講流程描述清楚是很困難的，我們需要系統化地分析，因此可以借助“跨職責流程圖”幫助我們梳理脈絡。
跨職責流程圖是商業分析的標準工具，它定義了一套標準的建模元素與分析方法，下圖展示了房產中介賣房時的流程。
看到這張圖，也許很多讀者會很疑惑：這張圖也太簡單了吧。談判議價以及辦理過戶手續都涉及許多業務性的判斷，為什么在圖中都不體現呢？
這是因為它們屬于細節層次，在本階段判斷的原則是：不會影響其他泳道的流程，在這個階段都不需要表現出來。在這個場景中，談判議價雖然復雜，但是它的判斷流程并不會對其他泳道產生影響，因此我們可以暫時不看。
三、角色與使用場景分析
不少讀者會有這樣的疑惑，我做B端的產品，把流程梳理完了就能知道需要設計什么功能點來描述需求了，為什么還要去分析角色與使用場景呢？對于一個B端產品來說，用戶在使用的過程中應該是無差別的，我們硬是把這些用戶分成不同的角色那不是多此一舉嗎？
確實，我剛開始接觸B端產品時也是相同的想法。
直到有一次，一位朋友給我描述他們的產品。
“我們這款產品是一個征收系統，給政府人員管理征收流程用的。這個產品包含填寫測算表、選擇安置房、選擇賠償標準、查看簽訂合約人數等等功能，填寫測算表里又分為了…模塊…”
當時確實是把我聽懵逼了。隨后我問了他兩個問題。
- 這個系統到底有誰在用？
- 這個系統幫助這些人解決什么問題，怎么解決？
問完之后我馬上意識到，這兩個問題不就是典型的用例分析方法嗎？
用戶故事是指某種類型的用戶為了完成某特定目標所執行的一系列操作。在描述層面我們可以暫時忽略業務目標，因此一條用戶故事包含兩個元素：
1. 參與者
參與者是指在系統之外，這個流程中與系統進行有意義交互的任何事物。參與者不僅可以由人來承擔，也可以是其他系統或者是硬件設備。
例如在看房的過程中，業務員從后臺系統調取房屋的平面圖以及詳細信息，這時候后臺系統就是其中一個參與者。如果我們的新房還沒有裝修好，用VR眼鏡讓客戶看到裝修后的效果時，VR眼鏡也是流程中的參與者。參與者是一種角色，而不是一個特定的人，在某些場景中甚至一個人能夠充當多個角色。
2. 做什么事情（用例）
用例是指用戶在系統中執行的一系列動作，通常用“動詞+名詞”的方式表達。值得注意的是，用例是有目標的，它能夠為參與者帶來有意義的結果，例如“填寫搜索房屋條件”顯然對于參與者來說沒有任何意義，就不是一個合適的用例。
另外用例是對一組使用場景的抽象。用例與場景之間的關系像是計算機概念中，類與對象之間的關系。一個場景是一個具體的行為，一個用例是對一類相關行為的抽象。
例如我們在系統上找房源的時候，可能會遇到很多場景：使用搜索框直接搜索心儀房源、根據篩選條件挑選房源、根據推薦的新盤挑選房源、拉取兩三個房源對比后挑選等等，不管有多少種情況，只要是在做挑選房源這件事，那么這些場景在系統中，都可以概括為一個“挑選房源”的用例。
在傳統的結構化分析與設計方法中，對事物的分析視角都是站在解決方案層面思考的，即這個系統需要有什么，從系統的角度出發做功能規劃。這樣做出來的產品，常常有用戶抱怨太難用，很難理解系統的意思，也不知道從哪里去找需要的功能。
而以“用戶故事”驅動的需求分析方法，是一種更側重于“從用戶的角度出發，將系統當做一個黑盒子”的視角，這種方法能夠有效解決上述問題。
從另外一個角度來說，用戶故事的關鍵點在于發現使用系統的用戶，了解并梳理這些用戶如何使用系統，從而達到“以人為本”的需求分析。
B端產品怎么找用例？又如何把用例找“全”呢？這是一個經常困擾產品經理的問題。
實際上，我們可以從針對各個業務事件處理過程的流程圖中得到用例。正如前文所述，流程圖是我們與企業中層管理人員溝通后得到的產物。只要有針對各個業務事件處理過程的流程圖，我們就可以從中導出相應的用例。
跨職能流程圖對應的不同崗位是可能產生用例的參與者，再加上他們所負責的事情，就是完整的業務用例。也就是我們的客戶完成一項業務需要做的所有事情。但是我們做一款產品，很多時候不能滿足客戶的所有業務環節，只能挑選與我們產品相匹配的核心場景的業務鏈條深入分析。
因此，對于我們來說，本階段挑選的業務用例實際上就是系統用例。而系統用例的判斷要點在于該用例“是否屬于系統范圍”，以及他們所做的這個事情能否產生業務價值，只要滿足這兩個條件的所有用例都必須記錄下來。這樣一來，我們就能夠得到完整的系統用例。
有的讀者可能會問：用例分析要分析到什么地步才能結束？
筆者的建議是不要追求完美，只要感覺已經把客戶的業務都弄清楚就可以考慮結束，而不必等到事無巨細的每件事都梳理完整。
面對一個陌生的領域，一個經歷了多年發展變化的業務流程，要在短時間內弄清楚的確是一個不小的挑戰。用例分析的意義在于幫助產品經理在短時間內從結構、整體上了解業務構成。用例是比較高層次的業務抽象，更容易被人們理解和接受。所以進行這一項工作，只需要感覺到業務的整體信息已經可以掌握，就可以考慮停止更廣泛的用例獲取。以現有的用例作為基線，進行接下來的工作。產品不斷迭代的前提就是建立在用例不斷優化、不斷調整的過程中。
四、獲取用戶需求
在客戶調研的時候，經?？吹疆a品經理傻里傻氣地問客戶：你對這個產品有什么需求或者有想法嗎？但不管用戶怎么回答，似乎都很難讓我們滿意?？蛻籼岵怀鲂枨?，你會覺得我們的客戶對這事好像也沒那么上心；更多的時候是客戶提的需求都是不痛不癢，或者你感覺極具個性化，讓你感覺做也不也是不做也不是；
和C端場景一樣，B端場景中的用戶需求也像是一個冰山，有很大一部分信息是埋藏在海平面之下，這就對需求調研工作帶來很大的困擾。主要的需求分為三種：
1. 意識到的需求
這是在海平面以上的需求，通常是一些困擾用戶的問題，或者是用戶自己能想到的功能。大部分產品經理在調研過程中獲取到的都是這一類需求；
2. 無意識的需求
它是用戶在實際工作場景中“沒有意識到是問題”的問題，這種問題需要產品經理對業務有一定的理解才能夠發現。如果對這些場景能做到“感同身受”的話，相信在產品規劃的過程中能夠設計出更合理、高效的方案；
3. 進一步的需求
調研的用戶畢竟不是技術專家，只是普通的業務人員，因此他們沒有辦法對其工作提出產生變革的解決方案。因此需要產品經理對問題充分理解的前提下，選擇合適的實現方式以創造出用戶未想到的功能；
在設計這款針對房產中介的CRM產品時，業務員反饋他們在客戶選房的時候，需要將不同房源的信息發送給客戶。于是產品經理聽完后，在房源列表中，每一條房源的操作按鈕區域增加了一個分享按鈕。
滿心歡喜地給到業務員時，業務員說這功能不實用，因為沒辦法把多個房源的信息合并在一起發給客戶。但是產品經理認為，你可以一條一條發給客戶呀，所以產品的設計還是能滿足業務需要的，但業務員希望得到的是多個房源信息合并后摘出關鍵信息發給客戶比對，而不僅僅是展示每個房源的信息。
這個場景就是只發現意識到的需求，而沒有深究以及進一步分析的后果。
實際上B端產品的需求獲取并不難，難的是與用戶交流溝通的過程。因為我們的用戶僅僅作為一個使用者，他只是站在自身使用的視角，想讓自己的工作方便一些或是在利益分配上對自己更有利，很難站在系統規劃的角度考慮全面整體的東西。
遇到這種情況，最有效的應對策略是需求分析從流程入手，搞清楚業務活動在平時是如何開展的，再逐步過渡到存在什么樣的障礙，有什么困難等等。在這個過程中，多問幾個為什么，多思考客戶訴求背后代表的心里狀態與利益沖突。
所以這一階段，我們主要做的工作是收集針對業務活動的問題點、需求點。這時候我們獲取到的是原始的用戶需求。
實際上，在整個業務分類、需求梳理的大環節中，業務流程分析、角色與使用場景分析、以及獲取用戶需求都是伴隨著用戶調研進行的。用戶調研是一個有計劃、循序漸進的過程。具體來說，在針對不用的訪談對象時，訪談的要點也不盡相同，具體的要點參考以下表格：
除了用戶訪談和問卷調查以外，有機會到業務工作中實際現場觀摩也是一種很好的需求獲取手段，有助于產品經理對業務場景建立更加感性的認識。在對關鍵任務理解不清晰、很多東西用文字沒辦法表述時，現場觀摩都是一種很好的方式。
到了這一步，我們已經收集到足夠多的業務信息供我們進行后續的需求分析工作。
五、確定需求細節
1. 完善用例
本階段的任務是對用例的細節進行填充。上一階段的用戶故事已經說明業務怎么執行，但缺少表達如何“實現”的機制。
例如房產交易后對合同歸檔，有一部分合同可以由業務員直接歸檔，有一部分則需要經過部門經理審核后才能歸檔。另外歸檔需要什么前置條件，歸檔后會引發這項業務發生什么樣的變化，這些都是本階段需要考慮的問題。
因此在完善用例階段，我們需要做的事情主要有：
- （1）將用例與需求相對應；
- （2）表述用例的事件流；
- （3）補充用例的前置條件與后置條件；
- （4）確定用例的規則與約束條件；
（1）用例與需求相對應
以用例作為需求的最小單位，是按照業務流的角度將需求分類管理的方法。在這個階段，首先我們要做的事情是將用戶調研階段獲取到的用戶原始需求整理到相應的用例中，以此建立用戶原始需求與軟件需求（用例）之間的映射。
在具體操作時，我們可以用以下表格管理需求追蹤。前三列描述了用戶原始需求的編號、描述與提出者，接下來兩列則是相應的用例編號及用例名稱。這些用戶的原始需求來源于用戶調研、用戶提供的需求說明以及在使用系統過程中獲得的反饋。
有這樣一張表，我們對用戶的需求管理更顯得張弛有度，同時也更容易發現需求沖突的地方。
（2）表述事件流
對于用例而言，最常見的事件流包括3種：
- 基本事件流：是對用例的預期路徑的描述。是大部分時間遇到的場景，也是符合用戶預期與業務初衷的核心路徑；
- 拓展事件流：也稱為分支事件流，主要用來描述用戶的不同選擇以及對異常情況的表示；
- 子事件流：用于對事件流中多次重復的部分進行概括，類似代碼中的“循環結構”；
在買房這個例子中，按預定路線雙方完成交易就是基本事件流，雙方對價錢的商議過程就是子事件流，而買賣雙方的交易過程穿插著比較多的交易情況，屬于拓展事件流。
（3）補充前置條件與后置條件
所謂前置條件是指在用例啟動時，參與者與系統應處于什么狀態。這個狀態是系統能夠檢測并且是有意義的。而后置條件是指在用例結束時，系統應處于什么狀態。同樣這個狀態也是系統能檢測到并且有意義的。通過以下例子加深理解：
客戶有購房意向：這不是一個前置條件，因為這是系統無法檢測的；
客戶登錄系統查看房源圖片：這也不是一個好的前置條件，雖然系統可以檢測，但是這個事情所表現出來的意義不大，對我們來說沒有幫助；
審核通過，完成合同：這是一個好的后置條件，系統可以檢測并且事件對流程有影響；
一般來說，前置條件通常是一種狀態，后置條件可能是一種狀態，也可能是一種后續行為。并非所有的用例都存在前置條件與后置條件。
（4）規則與設計約束
規則是在實現階段應該考慮的東西，而約束是對技術手段起限制作用的各種條件。在這個階段補充規則與設計約束是我們對用例整理的最后一件事情。
從需求的角度來看，用例涉及的規則大致可以分為：業務規則與數據規則兩類。
業務規則：它是指和業務邏輯、業務流程相關的規則。例如業務系統中，一個業務員接觸了買方之后系統不會把這個客戶再分給別的業務員；業務員釋放了某個客戶之后，其他業務員可以聯系這個客戶等等；
數據規則：它是和業務屬性相關的規則。例如業務員給客戶發送的營銷短信最大長度是200個漢字；業務員的當月有效業績是當月已付款的所有訂單的總金額合計等等；
而用例的約束則比較簡單，通常指的是性能指標等非功能要求，或是軟硬件、用戶使用環境以及技術選擇的限制。這些限制也并非每個用例都會有，但關鍵業務活動的設計約束比較要充分考慮才不會發生因規劃產生的設計缺陷。
2. 需求整理與分析
需求分析是需求工程中最重要的活動之一。需求分析并不是在分析系統如何實現用戶的需求，而是選擇一種業務導向的指引將零散的需求串聯起來，形成一個體系完整、內容清晰的框架，為下一階段的產品設計工作做準備。
在這個階段，我們要做兩件事情：整理需求并消除需求間的矛盾。
（1）整理需求
將用戶需求轉化成系統需求后，我們要根據業務流向，整理每一個環節，每一種類型的需求。如下圖所示：
這種結構是以業務流程為整理的主線索，也就是按“事”的角度進行分解。這種方法對于工作流系統以及信息管理系統來說都是非常適用的方法。
首先將我們的產品劃分成不同的業務板塊，在這個層面看哪些系統需求是針對業務事件，確保業務流程正常進行的；哪些系統需求是針對報表的要求，確保流轉過程中的數據傳遞；
接下來再往更細顆粒的維度整理，梳理哪些系統需求是支持業務步驟的，基于這些業務步驟需要設計什么樣的功能點。這樣一來所有的系統需求都按照清晰的脈絡，層層遞進展現在我們面前。
（2）消除需求間的矛盾
以上整理需求的方式，是按照業務流程進行整理的。在這個分析過程中，因為我們的需求來自不同的部門不同的崗位，難免會發現有些需求是互相矛盾、互相沖突的。因此我們在整理后的列表中需要將這些矛盾的需求全部圈出來，然后快速地找到相關人員，通過進一步的溝通協調來消除矛盾的需求。
很多時候，需求沖突的真正原因是使用者與管理者之間的沖突。作為使用者，他的核心訴求是方便高效、省事，最好還能在某些方面獲得一定的利益；作為管理者，他的訴求是流程規范、過程可追蹤，杜絕損害公司利益的事情發生。
例如中介公司的業務員，經常需要帶客戶去樓盤看房，他們自然希望在考勤方面能夠更彈性，有一些自由度。但是作為管理人員，他們也沒有辦法盯著業務員時刻在做什么，只能通過一些定位打卡等手段管理業務員，不讓他偷懶。
從這個例子可以看出來，不同角色由于崗位不同，核心訴求也不一樣。在發生沖突的時候，筆者的建議是以企業的生產經營為核心，首先確保經營活動的規范化、流程化進行，在這個基礎上增加為普通使用者考慮的易用性設計與情感化設計，讓他們感受到產品不單單是一個反感排斥的工作系統，而是真正幫助他們提高工作效率的產品。
完成這一步后，才算是將整個產品的系統需求全部整理出來。以后每次迭代就是在業務需求與用戶需求的基礎上，創建新的系統需求，不斷完善、豐富產品。
六、系統建設
終于，我們進入到系統建設環節，真正開始設計一款產品的形狀了。在這之前，我們先探討一個問題：B端產品和C端產品在產品設計上有什么差異性？
筆者認為，絕大多數C端產品的設計邏輯會把用戶體驗與效率放在首位。最求極致的簡單好用于高效。在整個產品設計上比較側重用戶的感受，精心打磨頁面與交互，盡量少讓用戶做選擇，保持產品的易用性與流暢性，都是做C端產品設計的不二法門。
但是做B端產品時，所有的產品設計都是為“流程”服務的。體驗和效率未必是設計的重心。
很簡單的一個例子就能明白：企業買一款中介CRM產品，不是為了讓業務員更輕松，做業務的時候更“省事”，而是為了將整個賣房的流程管理起來，做標準化的經營，為經營決策提供更準確科學的決策。
B端產品更多是通過計算機技術實現企業的信息化管理，對企業流程進行優化升級，從而達到降本增效的目的。
由此可以看出來，做C端產品更注重對“人”的理解，要求產品經理具備同理心，感知用戶的能力。而做B端產品更注重對“業務”的理解，要求產品經理具有系統性的邏輯思維，富有理性地對企業業務進行全面梳理與診斷，給出合理有效的解決方案。
在規劃產品原型的過程中，產品的信息架構設計是重要一環，其中菜單結構設計、CRUD原則與RBAC模型的應用，可以幫助我們設計出更合理、高效的產品形態。
1. 菜單結構設計
常見的菜單結構設計有兩種，以“人/物”為主線，或以“事”為主線。
大部分的通用型B端產品由于各行各業的垂直差異性，無法做到統一的流程管理，而產品需要滿足盡可能多的行業，因此只能以“物”為主線劃分菜單結構。例如將CRM系統劃分為線索、客戶、聯系人、公海、商機、合同等等，都是以“人/物”作為劃分的標準。
這種劃分方式在一定程度上來說是有缺陷的，因為在實際的業務流程中，物與物之間的傳遞有可能交錯，例如在房產交易、確權、歸檔的幾個環節中都涉及到合同的流轉，而這種菜單結構沒有充分體現這種流轉的特點，同時不同崗位的職責權限也有可能交錯在一起。
而專注于垂直行業的B端產品則往往以業務流程的職責劃分為菜單劃分的標準，也就是以“事”為主線的設計方式。這種設計方式的好處是可以有效的避免重復和混亂的現象，對整個系統的架構都是非常清晰明了的。
2. CRUD原則
在互聯網，各類互聯網書籍都提到過CRUD原則，也就是將新增、刪除、查詢與修改等操作合并成一個管理頁面。例如一個訂單管理頁，包含了新增訂單、刪除訂單、查詢以及修改訂單信息等不同的操作。
但是在很多情況下，一個ERP系統中，錄入訂單是由業務員錄入的，后續由銷售人員更新訂單的信息。當發現退款時，由財務或售后人員撤銷訂單。由此可見這些所謂的“管理”操作往往不是由同一個角色完成的，如果合并在同一個管理頁面會產生很多職責權限混亂的問題。
好在現在越來越多的產品也意識到這個問題，在菜單設計上盡量避免使用“某某管理”這樣的字眼，而是根據業務場景，更靈活地劃分菜單的范圍。
上面這段話的意思，難道說CRUD原則是錯的？其實并非如此，只是CRUD原則對于系統創造的東西才適用，例如管理系統用戶、管理數據字典、管理權限這類的東西就適用該原則。對系統用戶的增刪改查，通常都是由管理員操作的，這個時候我們把這些操作都放在同一個界面就是合理的場景。
3. RBAC權限模型
B端產品的權限設計通常都是適用RBAC模型，也就是每個用戶都要被賦予一個或多個系統角色，每個系統角色都對應一個明確的權限集合，包括對菜單、頁面元素等資源的訪問與操作權限。建立一個“用戶——角色——權限”之間的對應關系。
此時，用戶與角色，角色與權限都是多對多關系，即一個用戶可以對應多個角色，一個角色可以分配給多個用戶，一個角色具有多個權限。當用戶比較多時，可引入用戶組，既對用戶分組，將角色與用戶組進行關聯。
比如某個銷售部門的員工在系統中是一個用戶組，當新的銷售員加入時，只需要設置他所在的用戶組，就會將這個部門關聯的權限賦予這位銷售員。
設置用戶組還有一個好處，當這個部門的權限發生變動時，只需要調整這個用戶組對應的角色權限即可，不需要調整每個用戶和角色對應的關系。
以上三點是我們在做系統建設時最關鍵的核心設計點，相信經過以上的思考之后，結合上一階段整理的系統需求列表，在我們的腦海里已經有大致的產品解決方案了。接下來的我們可以開始畫原型、畫界面，將文字性的想法通過形象化的方式展現出來。因原型的設計不是本文重點，在此不再贅述。
直到這里，相信你已經對B端產品設計的全流程有一個清晰的思路了。韌哥在《產品經理必懂的技術那點事兒》一書中曾寫道：
“產品經理必須習慣與孤獨為伴，這種孤獨不是沒有朋友的孤單感，而是指思考和決策的過程并不會有人給你明晰的指引，只能靠自己的獨立思考和理解給產品賦予生命力，做出關鍵決策。”
本文當然也不是一個教你如何做一款成功的B端產品指南，而是希望在你做B端產品時，能夠提供一些設計的思路幫助你少犯錯，沿著正確的方向思考問題。產品路上并不孤獨，愿你我共勉。
#專欄作家#
阿翹，微信公眾號：阿翹AKIU。平安科技資深產品經理，《產品經理進階：100個案例搞懂人工智能》作者；擅長人工智能技術在金融領域的商業化應用，實踐經驗豐富，對產品設計方法論有深入洞察。
本文原創發布于人人都是產品經理，未經許可，不得轉載。
題圖來自 Unsplash，基于 CC0 協議
太長了，看了好久才看完
結構太亂了
受教了，謝謝
需要一遍、兩遍………..很多遍慢慢消化！
很不錯，有空再看
謝謝，對于我這個產品新人很受用！
歡迎各位朋友添加我的微信交流探討，謝謝
很全面！
贊一個
??
棒棒的，就是這個原諒綠 辣眼睛
嗯 挺系統的