不同于toC產品中用戶的角色通常與家庭角色、態度、相關活動方法、興趣、選擇生活方式的能力等對應，在toB產品中，角色常與工作角色或職責相對應，用戶的目標和行為受其性格、能力、經驗的影響較小，而受在企業內的崗位職能的影響較大。

下面將以實際工作中一個小功能——某公司辦公管理系統APP的會議申請功能的設計為例，討論對toB類產品進行角色和場景分析的方法。文章最后會以一個與PM的爭議為例，看看這一方法在交互設計初期，如何幫助團隊及時地與產品經理一起解決異議、統一思路。同時，也會順便以這個爭議為例，探討一下用戶體驗和產品目標之間的權衡問題。

注：實際上線項目不便展示設計細節，僅就方法本身進行探討

1 角色分析

目標用戶：對辦公管理系統APP中的一個會議申請模塊而言，目標用戶就是企業內與一場會議的進行相關的申請人、審批人、參與人員（含普通參與人員與主持人）、場地管理人員。

2 人物模型

對toB產品而言，目標用戶通常比toC產品的目標用戶更為寬泛，需要為不同崗位職能、不同部門、具有不同需要的特定個體類型設計。因此不可避免地在用戶的認知負擔和導航成本上會高于toC產品。正因為這樣，清晰地劃分不同人物模型，有助于避免設計對用戶的理解過于籠統、重點混亂。

根據部門、職能和與場景相關的職能，我們考慮建立5個典型的人物模型，用于分析和建立情境場景。

3 情境場景

會議的申請人、審批人、主持人、參與人、會議室管理人，五個典型的人物模型在會議室管理模塊的使用中，會面對截然不同的使用路徑和具體目標。而會議室管理模塊本身，在“申請會議室”這一核心場景之外，又有非常多的支線場景和異常場景。

通過情境場景，可以通過敘事這一用戶研究與設計之間絕佳的粘合劑，簡明地描述五個人物模型使用本模塊完成各自任務的過程，并從中關注人物模型的思考和行為方式，對理想的體驗進行描述。

3.1 核心場景：申請會議室

張文濤：

• 張文濤早上才到辦公室不久就接到了某建筑設計院趙工的電話，對方希望對A項目的圖紙與公司領導一起進行評審。
• 張文濤將這一消息轉告給項目主管周堯后，周堯對這一進展很高興，讓張文濤趕緊用APP訂一個下午兩點半會議室。
• 張文濤馬上拿出手機照辦。他進入辦公管理系統APP后，在首頁的主界面點選”會議管理“按鈕，進入了會議管理模塊，并在列表中選擇了“會議申請”、進入了會議室列表。
• 會議室列表中列出了公司所有可用的會議室，同時顯示了會議室的照片、地址、規模、座位數、有無投影等關鍵信息。同時，在頁面頂部有一個會議時間控件，填寫時間后，可以篩選當前時間段可以借用的會議室。
• 張文濤填寫了開始時間和借用時長后，列表中篩選后只剩下3個可選項。張文濤按照周堯提到的名單，粗估了一下人數大概為6~7個人，于是點擊了規模為“小型”、離工程部最近的10樓東會議室。
• 進入該會議室的詳情頁后，下方的已預約列表中顯示了當前的預約情況，張文濤粗略地掃了一眼，發現這個會議室的預約情況很滿，很是搶手，他不禁慶幸了一下自己的運氣。
• 張文濤點擊確定按鈕，進入了信息填寫頁。以往需要通過電話和綜合辦確認半天（還經常因為聽不清導致不必要的重復甚至錯漏）的各種信息，在這里只要逐一選擇即可——開始時間、結束時間、會議主題、主持人、參會人員、會議日程、會議詳情、會務要求（視頻會議系統、快餐、茶水等），張文濤逐一填寫、選擇并確認填寫無誤后，點擊了確定按鈕，提交了申請。頁面隨即跳轉至一個提醒提交成功的頁面，頁面中同時告知，本次申請由他的部門行政主管楊威審核。至此，張文濤在3個頁面內完成了一次清晰的會議室預預訂流程。

楊威：

楊威在他的主管辦公室里習慣鎖著門，聚精會神地盯著屏幕上的報表，封閉的空間更有利于他靜心思考問題，所以他不喜歡不停地有人來敲門、進進出出報告瑣碎的小事，好在最近公司引進了綜合辦公系統APP后，這樣的瑣事一下子少了不少，只要留心APP的提醒就是了。正想著，手機響起一聲清脆的提示音。楊威解鎖屏幕后，看到正是綜合辦公系統的APP彈出一條待辦提醒，他點開詳情頁后，看到是部門的小張在申請A項目的圖紙評審會。他簡單地瀏覽了會議時間、人員、議程、詳情和會務要求，確定沒有問題后便點擊了確認按鈕。

周堯：

周堯的手機上收到了推送消息”會議通知 – A項目評審會 11月1日 14:30“，他從推送消息點開詳情頁面看了一下時間和地點后，拿起筆在手旁的日歷上快速記下了這條日程。

李大鵬：

李大鵬的手機上收到了推送消息”會議通知 – A項目評審會 11月1日 14:30“，正在埋頭看B項目的圖紙的李大鵬默默地記在了心里，準備等去開會之前再細看一下地點。

劉燕南：

劉燕南的手機上收到了推送消息”會議通知 – A項目評審會 11月1日 14:30“，她點開詳情看了看地點，打開自己用于記錄全公司會議安排的表格，在14:30的位置記下了”10樓東“的字樣，到時她會提前十五分鐘去開鎖，并按照會議要求準備投影和茶水。

楊威：

楊威在他的主管辦公室里習慣鎖著門，聚精會神地盯著屏幕上的報表，封閉的空間更有利于他靜心思考問題，所以他不喜歡不停地有人來敲門、進進出出報告瑣碎的小事，好在最近公司引進了綜合運營管理的APP后，這樣的瑣事一下子少了不少，只要留心APP的提醒就是了。正想著，手機響起一聲清脆的提示音。楊威解鎖屏幕后，看到綜合運營管理的APP彈出一條待辦提醒，他點開詳情頁后，看到是部門的小張在申請A項目的圖紙評審會。他簡單地瀏覽了會議時間、人員、議程、詳情和會務要求，確定沒有問題后便點擊了確認按鈕。

周堯：

周堯的手機上收到了推送消息”會議通知 – A項目評審會 11月1日 14:30“，他從推送消息點開詳情頁面看了一下時間和地點后，拿起筆在手旁的日歷上快速記下了這條日程。

李大鵬：

李大鵬的手機上收到了推送消息”會議通知 – A項目評審會 11月1日 14:30“，正在埋頭看B項目的圖紙的李大鵬默默地記在了心里，準備等去開會之前再細看一下地點。

劉燕南：

劉燕南的手機上收到了推送消息”會議通知 – A項目評審會 11月1日 14:30“，她點開詳情看了看地點，打開自己用于記錄全公司會議安排的表格，在14:30的位置記下了”10樓東“的字樣，到時她會提前十五分鐘去開鎖，并按照會議要求準備投影和茶水。

3.2 支線場景

3.1.1 無可用會議室

• 張文濤在填寫開始時間和借用時長后，篩選列表中為空，并有一句溫馨的提示語提示他該時段公司所有的會議室都已經被預約了。
• 張文濤馬上告知項目主管周堯，周堯首先讓他看一下10樓的東會議室是被誰預約了，如果是熟悉的部門，可以聯絡一下是否方便讓給他們急用。
• 張文濤取消了“篩選”勾選項，在全部會議室列表中找到10樓東會議室，進入詳情頁后，在下方的當前預約情況列表中，他很快找到了今天下午兩點半的預約情況，預約部門是一個他們很少打交道的部門。
• 聽到張文濤的查詢結果后，周堯決定放棄聯絡對方，并讓他嘗試一下4點是否有空會議室。
• 張文濤重新填寫了開始時間后再次搜索，這時有4個會議室可用，他便在其中找了相對最近的一間會議室，繼續申請流程（后續同核心流程）。

3.1.2 取消會議

• 設計院趙工忽然來電話說因為一系列修改，希望能把評審會推遲幾天。張文濤和周堯商議后，決定暫時取消這次會議。
• 張文濤打開APP，從會議管理模塊中進入”申請記錄”選項，選中最近的那條申請記錄，進入詳情頁后點擊了頁面底部醒目的“取消”按鈕，在彈窗中確認后，頁面隨即跳轉至一個提醒取消成功的頁面，頁面中同時告知他，取消通知已送達審批人、主持人、所有參會人員和會議室管理員。
• 楊威、周堯、李大鵬、劉燕南、所有參會人員列表中的人都隨即收到了一條推送消息“會議取消通知 – A項目評審會”。

3.1.3 修改會議

• 中午時分，技術主管李大鵬找到張文濤，告訴他下午他要出差，沒時間參加會議，但這項會議又需要李大鵬才能定奪，所以張文濤和設計院的趙工、周堯溝通后，決定把會議改在明天上午9點。
• 此外，周堯發現張文濤邀請的與會人員中漏掉了一個重要成員汪鳴，讓他趕緊補上。
• 在給趙工的電話中，趙工同時告訴他，設計院方面有四個人要來參加會議，這樣一來之前預訂的小會議室就不夠用了。
• 因此，張文濤需要重新修改會議的時間、地點以及參與人員。他從會議管理模塊中進入“申請記錄”選項，選中最近的那條申請記錄，在詳情頁點選了底部的”修改會議信息”按鈕。
• 首先，他點擊了會議地點，進入重新選擇會議室的界面，該界面同樣有一個會議時間的控件和篩選按鈕，他將會議時間改為明天上午9點后，從篩選后的會議室列表中選取了一個更大的會議室。
• 頁面跳轉至“修改會議信息”頁，他點擊與會人員后進入通訊錄，在其中添加了汪鳴后，在“修改會議信息”頁點下了確認修改按鈕。頁面隨即跳轉至提醒修改成功的頁面，頁面中同時告知，本次修改由他的部門行政主管楊威審核。
• 楊威問明事由后，重新審批通過了該修改。
• 周堯、李大鵬、劉燕南、所有先前處于參會人員列表中的人隨即收到了一條推送消息“會議信息變動 – A項目評審會”
• 而新加入參會人員的汪鳴收到的則是”會議通知 – A項目評審會 11月2日 14:30“。

4 提煉需求

基于角色和場景的分析完成后，順著場景就可以很快地提煉出明確的設計需求?！禔bout Face 4》中認為需要提煉的設計需求如下：

“提煉出人物模型的需求或設計需求，包括對象、動作和情境

• 數據需求：必須在系統中呈現的對象和信息（賬號、用戶名、地址、文件、消息、歌曲等）
• 功能需求：對系統對象執行的操作或功能
• 情境需求：系統中對象之間的關系或依賴、產品的物理環境、人物模型使用產品的技能和能力
• 其他需求：企業和技術的現實需求，包括業務需求、品牌和體驗需求、技術需求、顧客和合作伙伴需求”

而根據項目中的實踐經驗，為了設計的效率考慮，對本階段而言，可以將toB產品的需求提煉精簡為兩個方面：

• 信息需求：需要在界面上呈現給用戶的數據和信息
• 功能需求：需要為用戶提供的功能、相應的可操作控件

由此，我們將第3節中的場景分析提煉如下：

4.1 場景的需求提煉

4.1.1 核心場景——會議申請的相關需求

會議管理模塊主頁面(頁面01)：

功能需求：提供“會議室申請”入口

會議申請頁面(頁面02)：

• 信息需求：列出所有可選會議室列表，顯示了會議室的照片、地址、規模、座位數、有無投影等關鍵信息
• 功能需求：提供會議時間控件，可選取會議開始時間（按整點和半點提供選項）和預計市場（小時數），選擇后可通過“顯示全部/顯示可用”篩選按鈕，在可用會議室可所有會議室之間切換。點選會議室后跳轉至相應會議室詳情頁。

會議室詳情頁(頁面03)：

• 信息需求：顯示會議室的關鍵信息（照片、地址、規模、座位數、有無投影等）
• 功能需求：提供確認按鈕

會議信息頁(頁面04)：

• 信息需求：會議室名稱
• 功能需求：開始時間、結束時間、會議主題、主持人、參會人員、會議日程、會議詳情、會務要求（視頻會議系統、快餐、茶水等）的填寫/選擇控件，確認按鈕

申請成功提示頁(頁面05)：

• 信息需求：提示用戶申請提交成功的文案，審核人信息
• 功能需求：返回APP主界面的入口
• 推送提醒功能：新的會議提醒

4.1.2 支線場景1——無可用會議室時的相關需求

會議申請頁面(頁面02)：

• 信息需求：在篩選可用會議室的結果為空時，提供溫和的提示文案，建議用戶換一個時段再做嘗試

會議室詳情頁(頁面03)：

• 信息需求：顯示會議室當前的預訂情況
• 功能需求：提供醒目的返回列表按鈕

4.1.3 支線場景2——取消會議的相關需求

會議管理模塊主頁面(頁面01)：

• 功能需求：提供“申請記錄”入口

會議申請記錄列表(頁面06)：

• 信息需求：顯示已申請會議的記錄列表，每條記錄顯示會議地點、時間、處理狀態和申請時間等信息。
• 功能需求：點擊申請記錄后跳轉至相應申請的詳情頁。

會議申請記錄詳情(頁面07)：

• 信息需求：展示會議地點、會議主題、審核狀態、主持人、會議議程、會議時間、參會人員、會務要求（視頻會議系統、快餐、茶水等）、申請時間、審核人、審核理由等信息。
• 功能需求：對已申請但未進行的記錄，提供“取消申請”按鈕。

會議取消成功提示頁(頁面08)：

• 信息需求：提示用戶申請取消成功的文案
• 功能需求：返回APP主界面的入口
• 推送提醒功能：會議取消提醒

4.1.4 支線場景3——修改會議的相關需求

會議申請記錄詳情(頁面07)：

• 功能需求：對已申請但未進行的記錄，提供“修改會議信息”按鈕。

會議申請修改頁面(頁面09)：

• 功能需求：開始時間、結束時間、會議主題、主持人、參會人員、會議日程、會議詳情、會務要求（視頻會議系統、快餐、茶水等）的填寫/選擇控件，確認修改按鈕

會議修改成功提示頁(頁面10)：

• 信息需求：提示用戶申請修改成功的文案，審核人信息
• 功能需求：返回APP主界面的入口

推送提醒功能：

• 功能需求：會議變動提醒

4.2 需求點匯總

最后，對所有頁面、推送提醒的信息需求和功能需求進行匯總，整理如下：

會議管理模塊主頁面(頁面01)：

• 功能需求：提供“會議室申請”入口；提供“申請記錄”入口。

會議申請頁面(頁面02)：

• 信息需求：列出所有可選會議室列表，顯示了會議室的照片、地址、規模、座位數、有無投影等關鍵信息；在篩選可用會議室的結果為空時，提供溫和的提示文案，建議用戶換一個時段再做嘗試。
• 功能需求：提供會議時間控件，可選取會議開始時間（按整點和半點提供選項）和預計市場（小時數），選擇后可通過“顯示全部/顯示可用”篩選按鈕，在可用會議室可所有會議室之間切換。點選會議室后跳轉至相應會議室詳情頁。

會議室詳情頁(頁面03)：

• 信息需求：顯示會議室的關鍵信息（照片、地址、規模、座位數、有無投影等）；顯示會議室當前的預訂情況。
• 功能需求：提供確認按鈕；提供醒目的返回列表按鈕。

會議信息頁(頁面04)：

• 信息需求：會議室名稱
• 功能需求：開始時間、結束時間、會議主題、主持人、參會人員、會議日程、會議詳情、會務要求（視頻會議系統、快餐、茶水等）的填寫/選擇控件，確認按鈕

申請成功提示頁(頁面05)：

• 信息需求：提示用戶申請提交成功的文案，審核人信息
• 功能需求：返回APP主界面的入口

會議申請記錄列表(頁面06)：

• 信息需求：顯示已申請會議的記錄列表，每條記錄顯示會議地點、時間、處理狀態和申請時間等信息。
• 功能需求：點擊申請記錄后跳轉至相應申請的詳情頁。

會議申請記錄詳情(頁面07)：

• 信息需求：展示會議地點、會議主題、審核狀態、主持人、會議議程、會議時間、參會人員、會務要求（視頻會議系統、快餐、茶水等）、申請時間、審核人、審核理由等信息。
• 功能需求：對已申請但未進行的記錄，提供“取消申請”按鈕、“修改會議信息”按鈕。

會議取消成功提示頁(頁面08)：

• 信息需求：提示用戶申請取消成功的文案
• 功能需求：返回APP主界面的入口

會議申請修改頁面(頁面09)：

• 功能需求：開始時間、結束時間、會議主題、主持人、參會人員、會議日程、會議詳情、會務要求（視頻會議系統、快餐、茶水等）的填寫/選擇控件，確認修改按鈕

會議修改成功提示頁(頁面10)：

• 信息需求：提示用戶申請修改成功的文案，審核人信息
• 功能需求：返回APP主界面的入口

推送提醒功能：

• 功能需求：新的會議提醒、會議取消提醒、會議變動提醒

由此，我們將角色和場景轉化成了清晰的需求清單，而通過這樣一個基于頁面結構的信息和功能需求清單，我們下一步的信息架構設計也有了堅實可靠的研究基礎，而不是憑空拍腦袋或者拿競品來東拼西湊。

5 解決異議：用戶體驗與產品目標的權衡

在這個會議管理模塊的例子中，在角色和場景分析階段后，產品同事對“修改會議信息”的場景提出了異議，建議已提交的會議申請記錄只支持取消，不支持修改。需要修改時，只有取消后再重新申請。

產品方給出的理由如下：

1. 修改會議信息的頁面與申請新會議時填寫的頁面中，表單元素基本完全相同，單獨設置修改會議信息的路徑沒有必要。
2. 會議地點的變化、人員的增刪、議題的改動、會務要求的變動，都需要向多方發送不同的推送提醒，非常容易造成混亂。
3. 收到變動提醒后，用戶難以看出是哪些地方發生了變動，徒增困惑。
4. 考慮到企業內部分不熟悉移動端操作的用戶，應當盡量簡化任務和推送提醒的類型。
5. 先收到取消提醒、再收到一次新會議提醒，確實會讓收到推送的一方產生不愉快的情緒，但這一較高的犯錯成本實際上有助于會議申請人養成對申請信息負責、一次性填寫正確的習慣。

其中，對前3點而言，初版的場景設計從交互角度上看都是有自己的考慮的。首先，在使用場景不同時，即使內容完全相同的頁面，設置單獨的路徑也有助于用戶明確自己在使用路徑中的位置。其次，第2、3點實際上都是關于變更后推送方式的問題，第2點可以通過清晰地分解不同用例，針對不同接收方發送不同的提醒內容，邏輯上并不難理順。第3點可以通過將有變動的字段用不同字體樣式顯示有效地解決。溝通后也得到了同事的理解。

而第4、第5點理由則確實值得重新考慮。對會議管理這一個面向企業內所有部門、所有層次，幾乎所有領導和員工都有可能使用的模塊而言，盡量簡化任務路徑、推送提醒的數目和種類是有一定道理的。很多基于設計師個人的能力和經驗考慮，覺得理所應當的操作，對中老年用戶來說并不容易學習，記住“申請和取消“兩種任務的使用方法永遠比”申請、變更、取消“三種的學習成本更低。

實際上，如果按照只允許”申請和取消“的設計，相當于將”變更“操作拆解為了”申請-取消“兩步，人為增加了流程長度，同時也增加了推送提醒的數量。這顯然對用戶體驗是不利的。

但對企業應用而言，更好地完成產品目標是比用戶體驗更重要的考量。對一個辦公管理平臺而言，最大的產品目標就是提升辦公效率，而如果當變更操作過于便捷時，頻繁的變更是有損于這一目標的達成的。因此，人為提高變更操作的時間成本，在合理范圍內損失一定的用戶體驗，促使用戶自覺地一次性提交正確申請信息，才更有利于辦公效率的提升。至于確有會議信息需要變更的情況，可以結合企業工作流程的實際情況，靈活地多種方式解決：如果只是局部人員變動，單獨通過電話提醒受影響的人員即可，避免重新通知全體；如果是會議內容、議題的變動，實際上沒有必要在系統中重新發布；如果是會務要求的變動，同樣通過電話聯系會議室管理員說明情況即可。那么剩下的只有當會議室地點和時間變更的情況下，才需要取消后重新申請了，而這部分需求的數量其實并不高。

因此，如果犧牲用戶體驗有助于達到產品的短期目標（本例中是提高用戶申請會議的決策成本）和長期目標（本例中是讓教育員工養成對自己的會議申請負責的習慣），那么用戶體驗在一些特殊情況下并不作為最高優先級去考慮，這種局面在toB產品中尤其常見。

項目中最終決定采納產品方的意見。但需要在確認提交會議申請時通過文案提醒用戶，申請后將無法修改，有變更需要取消本次申請后再重新提交。

修改后的”修改會議“場景：

• 中午時分，技術主管李大鵬找到張文濤，告訴他下午他要出差，沒時間參加會議，但這項會議又需要李大鵬才能定奪，所以張文濤和設計院的趙工、周堯溝通后，決定把會議改在明天上午9點。
• 此外，周堯發現張文濤邀請的與會人員中漏掉了一個重要成員汪鳴，讓他趕緊補上。
• 在給趙工的電話中，趙工同時告訴他，設計院方面有四個人要來參加會議，這樣一來之前預訂的小會議室就不夠用了。
• 因此，張文濤需要重新修改會議的時間、地點以及參與人員。他從會議管理模塊中進入“申請記錄”選項，選中最近的那條申請記錄，在詳情頁點選了底部的”取消”按鈕。并重新回到會議室列表開始了新的申請流程。
• 周堯、李大鵬、劉燕南、所有先前處于參會人員列表中的人隨即收到了一條推送消息“會議取消通知 – A項目評審會”
• 他填寫了會議時間為明天上午9點后，從篩選后的會議室列表中選取了一個更大的會議室。
• 頁面跳轉至“填寫會議信息”頁，他點擊與會人員后進入通訊錄，勾選了包括汪鳴在內的所有與會人員后返回填寫頁，逐一重新填寫了所有表單后并確認后，頁面跳轉至提醒申請成功的頁面，頁面中同時告知，本次修改由他的部門行政主管楊威審核。
• 楊威問明事由后，重新審批通過了這次新的申請。
• 周堯、李大鵬、劉燕南、包括汪鳴在內的所有參會人員收到了一條推送消息“會議通知 – A項目評審會 11月2日 9:00”，大家心領神會地明白會議是因為某些緣故改期了，而第一次收到通知的汪鳴則馬上將它記在了自己的臺歷上。

根據修改后的場景，需求和后續的信息架構設計同樣會進行相應的調整，這里就不再贅述。

從這個例子可以看到，在設計初期進行準確的角色和場景分析，有利于團隊在項目前期就及時發現一些方向性的問題，避免在進行詳細的信息架構、流程設計，甚至產出交互稿后再進行大幅度的返工。

作者：Qinsman，原文地址：http://qinsman.com/1611_meeting/

本文由 @Qinsman 原創發布于人人都是產品經理。未經許可，禁止轉載。