關於一個優秀的2B產品設計，如何從流程、角色、批量、個性化4個重要關鍵詞入手呢？
一、通過流程理解業務
2B產品設計是從理解業務開始的。不論是行業垂直還是業務垂直的2B產品，大多都是強業務屬性的。
要完成一項特定的業務，可能是一個複雜的過程，需要多個人協調配合。比如說資產的全生命管理是一個很長的過程：採購->入庫->領用->跟蹤->維護->報廢，涉及到的角色可能包括：採購人員、資產管理員、普通員工，如果需要審批的話那還涉及到部門領導、財務人員等等。
可見業務有兩個特點：過程複雜、角色多，那我們在理解業務時也試著從這兩個角度來考慮，即流程和角色。如果把流程和角色看做兩個維度，就可以得到泳道圖，which is 常用的業務邏輯梳理工具。
下邊的泳道圖例子是一個餐廳從顧客點單到結賬的流程，涉及到顧客、服務員、廚房三個角色，如果按點餐的階段也可以分為用餐前、用餐中、用餐後。
如何梳理業務流程：從宏觀到細節
複雜的業務系統梳理往往不是一蹴而就的，為了讓自己的理解更系統、更有條理，可以採用從大到小，從宏觀到細節的順序分析和梳理業務流程。
比如上邊舉的餐廳的泳道圖栗子，其實是一個比較寬泛的整體流程。在有了這個流程之後，我們可以更進一步的梳理顧客“點餐”的流程：
我一般會把流程拆分成兩個部分：業務流程（宏觀）和功能流程（細節）。
- 業務流程對應宏觀的流程，如果輸出PRD的話，可以放在產品概述的部分，讓自己和同事首先對業務有個宏觀的認識；
- 功能流程可以針對一個小的功能點，也可以針對“點餐”這樣的功能模塊，功能流程最好儘可能的詳盡，應該包括各種各樣的異常處理，原則是RD小夥伴能按照這個流程就開發出來相應的頁面和功能。
流程另一種含義：操作流程
上邊講到的業務和功能流程更多是我們定義產品、設計產品時候幫助自己或同事理清思路的一種方式。
這裡要說的另一種流程是有關用戶體驗的“操作流程”。由於2B業務本身的屬性，要完成某些任務，過程可能涉及到多步操作，操作流程會比較長、比較繁瑣。出於產品易用性的考慮，在設計這種功能的時候儘量讓用戶的操作流程化。
在表單設計中我們總結過讓用戶填寫信息“分塊分步”，其實就是操作流程化的思路。把繁瑣的表單填寫細化成幾個步驟，用步驟條指明當前所處的位置和接下來要進行的操作。這樣流程化的操作可以讓用戶很順利的完成填寫表單這個比較複雜的任務。
再舉個例子，在一個數據採集產品中，採集數據人員要完成圖像數據的採集工作需要完成上傳數據、填寫基本信息、填寫業務信息、數據標註、數據校驗幾個步驟，這幾個步驟其實並不具有嚴格的先後順序（可以先填信息也可以先標註數據），所以我們設計的第一版產品中這些功能是一個一個分散在頁面中的。
經過用戶調研，我們發現這種設計會讓用戶進入頁面後不知所措，不知道自己該做什麼。所以改進的版本中我們把雜亂的功能都列在了一起，看起來像是一個todo list，這樣即使是第一次使用產品的用戶也能快速上手完成採集數據這項任務。
二、角色、用戶、權限
什麼是角色？用戶？權限？
在上邊點餐的栗子中，顧客、服務員、廚師是角色；顧客小李、顧客小方分別用不同的賬號登錄，分別點餐，他們是兩個用戶；顧客可以查看菜單、點餐，可以說顧客有“查看菜單”、“點餐”的權限。
角色很多時候對應著2B業務中的某類工作崗位，每個工作崗位負責的工作不同，我們就把他們叫做不同的角色，比如最常見的“普通用戶”、“管理員”等等，都是因為業務中負責的工作不一樣所以區分成不同的角色。
用戶很好理解，一般每個人都有自己的賬號登錄系統，每個人都是一個用戶。
權限呢？其實就是每個用戶可以看到的東西（數據權限）、可以操作的功能（功能權限）。正因為每個工作崗位負責的工作不同，工作崗位A的工作內容不希望讓工作崗位B的人看到（比如公司CEO能看到的數據和操作的功能肯定和一個普通員工不一樣），所以我們需要通過權限來控制每個用戶能的視野大小。
RBAC模型
細心的小讀者會發現，角色就是用戶和權限之間的橋樑，一個用戶可以查看的數據權限、操作的功能權限是通過角色來配置的。
那我們不禁會問，為什麼要通過角色建立用戶和權限的關係呢？為什麼不直接給用戶賦予相應的權限呢？
也不是不行，比如在很簡單的權限系統中，只有普通用戶和管理員兩種角色，我們就可以省去角色，直接給管理員用戶賦予相應的權限，其他所有用戶保持基本權限即可。
但在2B產品中，角色往往不止一種，用戶也有非常多，逐個給用戶設置權限是件非常繁瑣的事情。既然有些用戶的工作類似，所需要的權限也一致，我們就把這些權限打包成一個組合，賦給需要這組權限的用戶。
所以從這個角度看，角色也可以叫做“權限組合”。如果一個角色的權限發生變化，只需要修改該角色的權限範圍即可，不用挨個用戶去修改權限；如果一個用戶的角色發生變化，只需要修改這個用戶的角色，不用再去單獨配置他的權限。所以通過角色來管理用戶的權限效率會提高很多。
上邊講的這種模式就是RBAC（role based access control）模型。雖然RBAC是個比較偏技術的模型，但它為我們定義產品提供了一種思路：從角色和權限的角度梳理功能。
梳理角色和權限
在RBAC中，角色更偏重“權限組合”的概念。在定義產品時，角色更偏重“業務中的某類工作崗位”的概念。兩個概念其實是一致的，但在產品定義階段，我們先按照工作崗位的思路來梳理角色。相應的，權限在這個階段也可以理解為該角色看到的內容和操作的功能。
梳理角色和權限也可以分為兩個維度，宏觀和細節。
宏觀的角色梳理對應到工作中大概是調研階段。2B產品調研更多的是對業務的調研。在我們梳理業務流程的過程中，其實對業務涉及的角色、各角色負責的工作已經有了一個大概的認識。角色、工作、流程三種是密不可分的，它們一起組成了上邊提到的泳道圖。泳道圖這種輸出在產品體驗要素中的應該更靠近戰略層，目的是讓我們對產品給誰用、解決什麼問題有明確的認識~
細節的角色和權限梳理就要精確到每一個頁面的每一個功能了，所以對應產品體驗要素中的範圍層。
在產品設計階段，我們要決定每個功能給誰用，不給誰用；數據給誰看，不給誰看。比如說，在資產管理中，刪除、編輯的操作是不能開放給普通員工的，因為如果每個人都可以隨意修改資產信息會造成整個數據的錯亂。但修改和刪除功能是有必要的，所以我們只把這些功能開放給管理員用戶。
梳理功能權限我常用的就是兩種方法：如果每個角色的差異較大，基本沒有重合的工作，從角色角度分類，分別梳理各個角色的功能就可以了。
如下圖：
如果角色間工作重疊較多，那麼可以把角色和所以功能列成一個二維表格，然後逐一考慮這個人需不需這個功能。
如下圖：
有朋友可能會有這樣的疑問：2B產品的權限系統完全開放給用戶，由用戶去配置具體的角色、權限就好了啊，為什麼還需要花這麼大力氣來梳理角色和權限的關係呢？
我的理解是，梳理的過程也是幫助我們理解業務的過程，是磨刀不誤砍柴功。如果沒有梳理清角色、權限、流程，那設計出來的產品很大概率會有這樣那樣的邏輯問題，後邊再去修復既費時又費力。
而且我們梳理的角色權限類似一個“標準版”，是適用於大多數情況的一種配置。如果用戶有個性化需求，在這個“標準版”基礎上進行修改也會更加容易。
三、批量操作
親身體驗！“批量”的思想在2B產品設計中真的很重要！先來康康一些簡單的批量操作功能。
（郵件的批量刪除）
（批量增加需求）
（批量審批）
其實“批量”的思想在很多地方都有體現，除了上邊這幾個栗子，還有個非常常用的批量功能就是excel導入。那麼到底什麼功能需要“批量”呢？
什麼功能需要批量？
我的一點點經驗是可以從使用頻率和功能複雜程度的角度來考慮，顯然應該優先考慮使用頻繁而且功能複雜的功能的批量化。
舉個例子，在一個歷史數據採集平臺（核心功能是人工把各種存量歷史數據上傳到系統中）裡，最最核心、高頻的操作就是上傳數據。但上傳數據的同時還要填寫一些數據信息描述，相對來說操作比較複雜。
於是除了單個數據上傳外，我們設計了兩種批量上傳數據的方式：
- 方式一是先批量上傳多個數據，然後分別填寫描述信息；
- 方式二是先填寫部分共同的描述信息（比如一批數據可能屬於相同任務、時間和作者），然後批量上傳數據，描述信息會分別賦給每個數據。
批量功能的設計套路
這小節總結一下比較常見的批量功能實現方式~
（1）導入
通過excel導入大量的數據是非常好用的批量手段，尤其是有歷史數據需要導入產品時，歷史數據很有可能是通過excel保存的，所以excel導入這樣的方式能兼顧用戶的使用習慣又能提高錄入數據效率。
導入功能可以分為模板下載、文檔上傳和錯誤數據處理三個部分。有幾篇文章（淺析批量導入的功能設計、）已經總結的很清楚啦，推薦推薦，這裡就不贅述了。
（關於模板設計還是贅述一個小tip吧，因為上邊推薦的兩篇文章好像沒提到）如果某個字段對應到系統中是枚舉類型的（類似下拉框選擇的選項，選項是有限固定的），可以考慮在模板中填寫時就採用下拉選擇的形式，防止由於名稱不規範等原因出現導入錯誤。
（2）列表+批量
批量操作也經常在列表的基礎上實現，列表主要負責展示數據的概況，勾選多條數據後可以對勾選的數據做批量操作，比如上邊舉例中的批量刪除、批量審批就都屬於這種。
再舉個栗子，在資產管理中，可以在資產列表中選擇多個要處理的資產，然後同時對它們進行領用、借用、歸還等操作。
（3）表單+批量
表單的批量操作一般是新增數據時候使用，比如同時新增多條數據。單條新增數據的問題主要是填寫信息較多而且一次只能添加一條數據，如果新增數據是高頻、大量的操作（比如添加資產一次可能要增加幾十臺設備）用戶體驗會很差。
表單的批量操作我見到過的主要是兩種形式，一種是精簡填寫內容後把本來多個的表單合成一個大表單，所有內容默認同上，如下：
第二種形式是創建“模板”後，以模板內容為基準，用戶只需要調整少量內容即可，如下：
四、擁抱個性化需求
2b產品中的個性化需求真的很讓人頭大，每個客戶都有自己的想法，一千個客戶有一千個哈姆雷特，一開始我是拒絕的。
但是客戶爸爸的意見又不能不聽啊，怎麼辦呢？
首先深呼吸一口，放鬆心情。個性化需求雖然噁心，但是並不是妖魔鬼怪，只要我們花點心思梳理，會發現其實是可以解決的。而且在2b業務中，客戶之所以會提出這樣那樣看似無理的需求，實際上是因為他們的公司在業務中已經遇到了這些問題，而做產品不就是為了解決用戶問題嘛！所以這樣想，心態就會好很多了~
從另外一個角度看，遇到的個性化需求越多，我們的產品就不得不進行改造升級，這個過程非常痛苦，但結果是產品架構會越來越合理、產品配置越來越靈活、還可能抽象出一些以後可以複用的模塊組件，總體來說解決個性化需求會幫助我們的產品越來越好~
當然啦也不是所有客戶需求都是要滿足的，梳理個性化需求的第一步是判斷該需求是不是在我們產品的範圍之內。如果一個餐廳訂單系統的客戶非要讓我們管理採購業務，那我們只能抱歉的說這超出了我們的能力範圍了（但如果有需要可以提供和採購系統的交互接口）。
剔除了產品範圍之外的需求，剩下的需求可以分為三種：
- 可以用現有功能解決的；
- 可以通過配置實現的和；
- 可以定製化開發實現的。從研發成本角度看，1<2<3。
用已有功能解決
我們常說用戶說的不一定是他們想要的，或者說用戶的需求可以通過其他方式滿足而不一定通過他們所給出的方案解決。用已有功能滿足用戶提出的個性化需求，對我們來說是最經濟高效的解決方案。
舉個栗子，在一個類似在線excel的產品中，客戶提出想要一個excel中按顏色篩選單元格的功能，那麼我們就要問為什麼呢？
通過訪談和觀察現有的操作習慣發現，用戶會在操作過程中把有疑問的行背景設置一個顏色，然後通過按顏色篩選找出這些有疑問的行再進行進一步操作。所以可見用戶想要按顏色篩選的功能不是真的關注單元格顏色，而是需要一個標誌並按照這個標誌進行篩選。我們的產品已經有一個標記功能，可以給行做不同的標記，再加上一個按標記篩選的功能就可以滿足用戶的需求了。
通過配置項解決
配置項把更大的自由和權力開放給用戶，允許用戶設置自己的數據字典、用戶權限、業務流程等等。
（1）什麼功能需要做配置？
上圖我覺得講的很明白！其實也是一個優先級的問題，多數用戶不一樣而且每個用戶頻繁變更的功能配置化的價值是最大的、優先級也是最高的；多數用戶不一樣但每個用戶變更頻率低的功能可以初始化的時候在代碼層面配置好；還有少數用戶的高頻需求可以作為定製化的付費功能。
（2）常見的配置項有哪些？
配置項的內容可以分為產品層面和功能層面。
因為每個客戶的實際情況都不一樣，所以產品層面的配置很有必要。但產品層面的配置大部分在上邊四象限圖中屬於②多數用戶不一樣但切換頻率低的功能，所以產品初期可能沒必要設為配置項。隨著客戶增多，每個客戶都要差別初始化的成本會越來越高，這時候在進行配置化改造也可行。
- 前邊講到的RBAC把角色權限設置交給用戶就是一種很典型的配置項，現在已經是大部分2b產品的標配了；
- 數據字典各公司的差異性很大，比如資產管理中資產分類、資產用途等數據，所以做成可配置項的價值也比較高；
- 審批流程的差異化也比較大，而且發生變動的可能性也較高（比如之前報銷超過1000元就需要分管領導審批，現在改成超過2000元才需要審批），所以也經常被做成用戶可配置的。
功能層面的配置針對每個小功能，粒度更細。比如在資產管理中，要生產貼在每個設備上的標籤，標籤上該顯示什麼信息呢？每個公司的規定可能都不一樣，甚至每種類型的設備也都不一樣。所以我們需要把標籤顯示信息做成可配置的，方便不同場景下不同用戶的選擇。
功能配置不是越多越好，配置多雖然產品靈活性好，但對單個用戶來說會提高上手難度、降低用戶體驗（想象一些軟件還沒用就要配置十幾項信息是非常讓人頭疼的一件事）。而且配置項越多開發的成本越高、週期越長，所以配置項做哪些不做哪些值得仔細思考~
通過定製化開發解決。
上邊四象限中的情況③少數用戶的高頻功能就非常適合作為定製化開發的對象。定製化開發的成本高，通用性還低，但從商業價值上來看不一定沒有意義，可以看做是我們解決個性化需求的兜底方案。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
