關于一個優(yōu)秀的2B產(chǎn)品設計，如何從流程、角色、批量、個性化4個重要關鍵詞入手呢？

?一、通過流程理解業(yè)務

2B產(chǎn)品設計是從理解業(yè)務開始的。不論是行業(yè)垂直還是業(yè)務垂直的2B產(chǎn)品，大多都是強業(yè)務屬性的。

要完成一項特定的業(yè)務，可能是一個復雜的過程，需要多個人協(xié)調配合。比如說資產(chǎn)的全生命管理是一個很長的過程：采購->入庫->領用->跟蹤->維護->報廢，涉及到的角色可能包括：采購人員、資產(chǎn)管理員、普通員工，如果需要審批的話那還涉及到部門領導、財務人員等等。

可見業(yè)務有兩個特點：過程復雜、角色多，那我們在理解業(yè)務時也試著從這兩個角度來考慮，即流程和角色。如果把流程和角色看做兩個維度，就可以得到泳道圖，which is 常用的業(yè)務邏輯梳理工具。

下邊的泳道圖例子是一個餐廳從顧客點單到結賬的流程，涉及到顧客、服務員、廚房三個角色，如果按點餐的階段也可以分為用餐前、用餐中、用餐后。

如何梳理業(yè)務流程：從宏觀到細節(jié)

復雜的業(yè)務系統(tǒng)梳理往往不是一蹴而就的，為了讓自己的理解更系統(tǒng)、更有條理，可以采用從大到小，從宏觀到細節(jié)的順序分析和梳理業(yè)務流程。

比如上邊舉的餐廳的泳道圖栗子，其實是一個比較寬泛的整體流程。在有了這個流程之后，我們可以更進一步的梳理顧客“點餐”的流程：

我一般會把流程拆分成兩個部分：業(yè)務流程（宏觀）和功能流程（細節(jié)）。

• 業(yè)務流程對應宏觀的流程，如果輸出PRD的話，可以放在產(chǎn)品概述的部分，讓自己和同事首先對業(yè)務有個宏觀的認識；
• 功能流程可以針對一個小的功能點，也可以針對“點餐”這樣的功能模塊，功能流程最好盡可能的詳盡，應該包括各種各樣的異常處理，原則是RD小伙伴能按照這個流程就開發(fā)出來相應的頁面和功能。

流程另一種含義：操作流程

上邊講到的業(yè)務和功能流程更多是我們定義產(chǎn)品、設計產(chǎn)品時候幫助自己或同事理清思路的一種方式。

這里要說的另一種流程是有關用戶體驗的“操作流程”。由于2B業(yè)務本身的屬性，要完成某些任務，過程可能涉及到多步操作，操作流程會比較長、比較繁瑣。出于產(chǎn)品易用性的考慮，在設計這種功能的時候盡量讓用戶的操作流程化。

在表單設計中我們總結過讓用戶填寫信息“分塊分步”，其實就是操作流程化的思路。把繁瑣的表單填寫細化成幾個步驟，用步驟條指明當前所處的位置和接下來要進行的操作。這樣流程化的操作可以讓用戶很順利的完成填寫表單這個比較復雜的任務。

再舉個例子，在一個數(shù)據(jù)采集產(chǎn)品中，采集數(shù)據(jù)人員要完成圖像數(shù)據(jù)的采集工作需要完成上傳數(shù)據(jù)、填寫基本信息、填寫業(yè)務信息、數(shù)據(jù)標注、數(shù)據(jù)校驗幾個步驟，這幾個步驟其實并不具有嚴格的先后順序（可以先填信息也可以先標注數(shù)據(jù)），所以我們設計的第一版產(chǎn)品中這些功能是一個一個分散在頁面中的。

經(jīng)過用戶調研，我們發(fā)現(xiàn)這種設計會讓用戶進入頁面后不知所措，不知道自己該做什么。所以改進的版本中我們把雜亂的功能都列在了一起，看起來像是一個todo list，這樣即使是第一次使用產(chǎn)品的用戶也能快速上手完成采集數(shù)據(jù)這項任務。

二、角色、用戶、權限

什么是角色？用戶？權限？

在上邊點餐的栗子中，顧客、服務員、廚師是角色；顧客小李、顧客小方分別用不同的賬號登錄，分別點餐，他們是兩個用戶；顧客可以查看菜單、點餐，可以說顧客有“查看菜單”、“點餐”的權限。

角色很多時候對應著2B業(yè)務中的某類工作崗位，每個工作崗位負責的工作不同，我們就把他們叫做不同的角色，比如最常見的“普通用戶”、“管理員”等等，都是因為業(yè)務中負責的工作不一樣所以區(qū)分成不同的角色。

用戶很好理解，一般每個人都有自己的賬號登錄系統(tǒng)，每個人都是一個用戶。

權限呢？其實就是每個用戶可以看到的東西（數(shù)據(jù)權限）、可以操作的功能（功能權限）。正因為每個工作崗位負責的工作不同，工作崗位A的工作內容不希望讓工作崗位B的人看到（比如公司CEO能看到的數(shù)據(jù)和操作的功能肯定和一個普通員工不一樣），所以我們需要通過權限來控制每個用戶能的視野大小。

RBAC模型

細心的小讀者會發(fā)現(xiàn)，角色就是用戶和權限之間的橋梁，一個用戶可以查看的數(shù)據(jù)權限、操作的功能權限是通過角色來配置的。

那我們不禁會問，為什么要通過角色建立用戶和權限的關系呢？為什么不直接給用戶賦予相應的權限呢？

也不是不行，比如在很簡單的權限系統(tǒng)中，只有普通用戶和管理員兩種角色，我們就可以省去角色，直接給管理員用戶賦予相應的權限，其他所有用戶保持基本權限即可。

但在2B產(chǎn)品中，角色往往不止一種，用戶也有非常多，逐個給用戶設置權限是件非常繁瑣的事情。既然有些用戶的工作類似，所需要的權限也一致，我們就把這些權限打包成一個組合，賦給需要這組權限的用戶。

所以從這個角度看，角色也可以叫做“權限組合”。如果一個角色的權限發(fā)生變化，只需要修改該角色的權限范圍即可，不用挨個用戶去修改權限；如果一個用戶的角色發(fā)生變化，只需要修改這個用戶的角色，不用再去單獨配置他的權限。所以通過角色來管理用戶的權限效率會提高很多。

上邊講的這種模式就是RBAC（role based access control）模型。雖然RBAC是個比較偏技術的模型，但它為我們定義產(chǎn)品提供了一種思路：從角色和權限的角度梳理功能。

梳理角色和權限

在RBAC中，角色更偏重“權限組合”的概念。在定義產(chǎn)品時，角色更偏重“業(yè)務中的某類工作崗位”的概念。兩個概念其實是一致的，但在產(chǎn)品定義階段，我們先按照工作崗位的思路來梳理角色。相應的，權限在這個階段也可以理解為該角色看到的內容和操作的功能。

梳理角色和權限也可以分為兩個維度，宏觀和細節(jié)。

宏觀的角色梳理對應到工作中大概是調研階段。2B產(chǎn)品調研更多的是對業(yè)務的調研。在我們梳理業(yè)務流程的過程中，其實對業(yè)務涉及的角色、各角色負責的工作已經(jīng)有了一個大概的認識。角色、工作、流程三種是密不可分的，它們一起組成了上邊提到的泳道圖。泳道圖這種輸出在產(chǎn)品體驗要素中的應該更靠近戰(zhàn)略層，目的是讓我們對產(chǎn)品給誰用、解決什么問題有明確的認識~

細節(jié)的角色和權限梳理就要精確到每一個頁面的每一個功能了，所以對應產(chǎn)品體驗要素中的范圍層。

在產(chǎn)品設計階段，我們要決定每個功能給誰用，不給誰用；數(shù)據(jù)給誰看，不給誰看。比如說，在資產(chǎn)管理中，刪除、編輯的操作是不能開放給普通員工的，因為如果每個人都可以隨意修改資產(chǎn)信息會造成整個數(shù)據(jù)的錯亂。但修改和刪除功能是有必要的，所以我們只把這些功能開放給管理員用戶。

梳理功能權限我常用的就是兩種方法：如果每個角色的差異較大，基本沒有重合的工作，從角色角度分類，分別梳理各個角色的功能就可以了。

如下圖：

如果角色間工作重疊較多，那么可以把角色和所以功能列成一個二維表格，然后逐一考慮這個人需不需這個功能。

如下圖：

有朋友可能會有這樣的疑問：2B產(chǎn)品的權限系統(tǒng)完全開放給用戶，由用戶去配置具體的角色、權限就好了啊，為什么還需要花這么大力氣來梳理角色和權限的關系呢？

我的理解是，梳理的過程也是幫助我們理解業(yè)務的過程，是磨刀不誤砍柴功。如果沒有梳理清角色、權限、流程，那設計出來的產(chǎn)品很大概率會有這樣那樣的邏輯問題，后邊再去修復既費時又費力。

而且我們梳理的角色權限類似一個“標準版”，是適用于大多數(shù)情況的一種配置。如果用戶有個性化需求，在這個“標準版”基礎上進行修改也會更加容易。

三、批量操作

親身體驗！“批量”的思想在2B產(chǎn)品設計中真的很重要！先來康康一些簡單的批量操作功能。

?（郵件的批量刪除）

?（批量增加需求）

（批量審批）

其實“批量”的思想在很多地方都有體現(xiàn)，除了上邊這幾個栗子，還有個非常常用的批量功能就是excel導入。那么到底什么功能需要“批量”呢？

什么功能需要批量？

我的一點點經(jīng)驗是可以從使用頻率和功能復雜程度的角度來考慮，顯然應該優(yōu)先考慮使用頻繁而且功能復雜的功能的批量化。

舉個例子，在一個歷史數(shù)據(jù)采集平臺（核心功能是人工把各種存量歷史數(shù)據(jù)上傳到系統(tǒng)中）里，最最核心、高頻的操作就是上傳數(shù)據(jù)。但上傳數(shù)據(jù)的同時還要填寫一些數(shù)據(jù)信息描述，相對來說操作比較復雜。

于是除了單個數(shù)據(jù)上傳外，我們設計了兩種批量上傳數(shù)據(jù)的方式：

• 方式一是先批量上傳多個數(shù)據(jù)，然后分別填寫描述信息；
• 方式二是先填寫部分共同的描述信息（比如一批數(shù)據(jù)可能屬于相同任務、時間和作者），然后批量上傳數(shù)據(jù)，描述信息會分別賦給每個數(shù)據(jù)。

批量功能的設計套路

這小節(jié)總結一下比較常見的批量功能實現(xiàn)方式~

（1）導入

通過excel導入大量的數(shù)據(jù)是非常好用的批量手段，尤其是有歷史數(shù)據(jù)需要導入產(chǎn)品時，歷史數(shù)據(jù)很有可能是通過excel保存的，所以excel導入這樣的方式能兼顧用戶的使用習慣又能提高錄入數(shù)據(jù)效率。

導入功能可以分為模板下載、文檔上傳和錯誤數(shù)據(jù)處理三個部分。有幾篇文章（淺析批量導入的功能設計、批量導入的詳細設計說明）已經(jīng)總結的很清楚啦，推薦推薦，這里就不贅述了。

（關于模板設計還是贅述一個小tip吧，因為上邊推薦的兩篇文章好像沒提到）如果某個字段對應到系統(tǒng)中是枚舉類型的（類似下拉框選擇的選項，選項是有限固定的），可以考慮在模板中填寫時就采用下拉選擇的形式，防止由于名稱不規(guī)范等原因出現(xiàn)導入錯誤。

（2）列表+批量

批量操作也經(jīng)常在列表的基礎上實現(xiàn)，列表主要負責展示數(shù)據(jù)的概況，勾選多條數(shù)據(jù)后可以對勾選的數(shù)據(jù)做批量操作，比如上邊舉例中的批量刪除、批量審批就都屬于這種。

再舉個栗子，在資產(chǎn)管理中，可以在資產(chǎn)列表中選擇多個要處理的資產(chǎn)，然后同時對它們進行領用、借用、歸還等操作。

（3）表單+批量

表單的批量操作一般是新增數(shù)據(jù)時候使用，比如同時新增多條數(shù)據(jù)。單條新增數(shù)據(jù)的問題主要是填寫信息較多而且一次只能添加一條數(shù)據(jù)，如果新增數(shù)據(jù)是高頻、大量的操作（比如添加資產(chǎn)一次可能要增加幾十臺設備）用戶體驗會很差。

表單的批量操作我見到過的主要是兩種形式，一種是精簡填寫內容后把本來多個的表單合成一個大表單，所有內容默認同上，如下：

第二種形式是創(chuàng)建“模板”后，以模板內容為基準，用戶只需要調整少量內容即可，如下：

四、擁抱個性化需求

2b產(chǎn)品中的個性化需求真的很讓人頭大，每個客戶都有自己的想法，一千個客戶有一千個哈姆雷特，一開始我是拒絕的。

但是客戶爸爸的意見又不能不聽啊，怎么辦呢？

首先深呼吸一口，放松心情。個性化需求雖然惡心，但是并不是妖魔鬼怪，只要我們花點心思梳理，會發(fā)現(xiàn)其實是可以解決的。而且在2b業(yè)務中，客戶之所以會提出這樣那樣看似無理的需求，實際上是因為他們的公司在業(yè)務中已經(jīng)遇到了這些問題，而做產(chǎn)品不就是為了解決用戶問題嘛！所以這樣想，心態(tài)就會好很多了~

從另外一個角度看，遇到的個性化需求越多，我們的產(chǎn)品就不得不進行改造升級，這個過程非常痛苦，但結果是產(chǎn)品架構會越來越合理、產(chǎn)品配置越來越靈活、還可能抽象出一些以后可以復用的模塊組件，總體來說解決個性化需求會幫助我們的產(chǎn)品越來越好~

當然啦也不是所有客戶需求都是要滿足的，梳理個性化需求的第一步是判斷該需求是不是在我們產(chǎn)品的范圍之內。如果一個餐廳訂單系統(tǒng)的客戶非要讓我們管理采購業(yè)務，那我們只能抱歉的說這超出了我們的能力范圍了（但如果有需要可以提供和采購系統(tǒng)的交互接口）。

剔除了產(chǎn)品范圍之外的需求，剩下的需求可以分為三種：

1. 可以用現(xiàn)有功能解決的；
2. 可以通過配置實現(xiàn)的和；
3. 可以定制化開發(fā)實現(xiàn)的。從研發(fā)成本角度看，1<2<3。

用已有功能解決

我們常說用戶說的不一定是他們想要的，或者說用戶的需求可以通過其他方式滿足而不一定通過他們所給出的方案解決。用已有功能滿足用戶提出的個性化需求，對我們來說是最經(jīng)濟高效的解決方案。

舉個栗子，在一個類似在線excel的產(chǎn)品中，客戶提出想要一個excel中按顏色篩選單元格的功能，那么我們就要問為什么呢？

通過訪談和觀察現(xiàn)有的操作習慣發(fā)現(xiàn)，用戶會在操作過程中把有疑問的行背景設置一個顏色，然后通過按顏色篩選找出這些有疑問的行再進行進一步操作。所以可見用戶想要按顏色篩選的功能不是真的關注單元格顏色，而是需要一個標志并按照這個標志進行篩選。我們的產(chǎn)品已經(jīng)有一個標記功能，可以給行做不同的標記，再加上一個按標記篩選的功能就可以滿足用戶的需求了。

通過配置項解決

配置項把更大的自由和權力開放給用戶，允許用戶設置自己的數(shù)據(jù)字典、用戶權限、業(yè)務流程等等。

（1）什么功能需要做配置？

上圖我覺得講的很明白！其實也是一個優(yōu)先級的問題，多數(shù)用戶不一樣而且每個用戶頻繁變更的功能配置化的價值是最大的、優(yōu)先級也是最高的；多數(shù)用戶不一樣但每個用戶變更頻率低的功能可以初始化的時候在代碼層面配置好；還有少數(shù)用戶的高頻需求可以作為定制化的付費功能。

（2）常見的配置項有哪些？

配置項的內容可以分為產(chǎn)品層面和功能層面。

因為每個客戶的實際情況都不一樣，所以產(chǎn)品層面的配置很有必要。但產(chǎn)品層面的配置大部分在上邊四象限圖中屬于②多數(shù)用戶不一樣但切換頻率低的功能，所以產(chǎn)品初期可能沒必要設為配置項。隨著客戶增多，每個客戶都要差別初始化的成本會越來越高，這時候在進行配置化改造也可行。

• 前邊講到的RBAC把角色權限設置交給用戶就是一種很典型的配置項，現(xiàn)在已經(jīng)是大部分2b產(chǎn)品的標配了；
• 數(shù)據(jù)字典各公司的差異性很大，比如資產(chǎn)管理中資產(chǎn)分類、資產(chǎn)用途等數(shù)據(jù)，所以做成可配置項的價值也比較高；
• 審批流程的差異化也比較大，而且發(fā)生變動的可能性也較高（比如之前報銷超過1000元就需要分管領導審批，現(xiàn)在改成超過2000元才需要審批），所以也經(jīng)常被做成用戶可配置的。

功能層面的配置針對每個小功能，粒度更細。比如在資產(chǎn)管理中，要生產(chǎn)貼在每個設備上的標簽，標簽上該顯示什么信息呢？每個公司的規(guī)定可能都不一樣，甚至每種類型的設備也都不一樣。所以我們需要把標簽顯示信息做成可配置的，方便不同場景下不同用戶的選擇。

功能配置不是越多越好，配置多雖然產(chǎn)品靈活性好，但對單個用戶來說會提高上手難度、降低用戶體驗（想象一些軟件還沒用就要配置十幾項信息是非常讓人頭疼的一件事）。而且配置項越多開發(fā)的成本越高、周期越長，所以配置項做哪些不做哪些值得仔細思考~

通過定制化開發(fā)解決。

上邊四象限中的情況③少數(shù)用戶的高頻功能就非常適合作為定制化開發(fā)的對象。定制化開發(fā)的成本高，通用性還低，但從商業(yè)價值上來看不一定沒有意義，可以看做是我們解決個性化需求的兜底方案。

本文由@LCC?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。