在上一篇文章中——《交互設計 | 先分解后聚合，“權限申請及審批”的產品閉環》，筆者講解了如何利用“先分解、后聚合” 的設計策略，完成“權限申請及審批”的產品閉環。同樣，在該項目中，“待辦”流程也可以采用相同的策略來開展設計，下文將詳細說明如何設計一套B端產品的“待辦”流程。

一、什么是“待辦”

一項任務或事項等待辦理就是“待辦”，在企業內常見的“待辦”工具是JIRA，用于項目與事務的跟蹤。

在本產品中，主要功能是監控“異常數據”，為了使得“異常數據”能夠形成一套跟蹤流程，所以需要設計一套“待辦”流程：如果用戶認為某條“異常數據”需要被人為處理，就將其納入“待辦”。通過實時跟蹤、管理該“異常數據”的處理進度，從而形成一套完整的“異常數據”處理機制。

二、角色及任務

1. 角色

一條“待辦”的流轉，必定有“創建方”和“承接方”，可分別定義為：發起者、接收者。

在“待辦”流轉過程中，由于“接收者”是被動選中的，因此可能存在以下兩種場景：

1. ?“接收者”無法獨自處理待辦，需要第三方參與處理；
2. ?“接收者”認為該待辦不屬于職責范圍，需要轉移給第三方。

在以上兩種場景中，“接收者”需要將“待辦”進行二次轉發，此時TA的角色可定義為“轉發者”。

據此，可對“待辦”流程定義三種角色：發起者、接收者、轉發者。

1. ?發起者：認為某條異常數據需要被人為跟蹤、處理，于是主動創建一條“待辦”的用戶；
2. ?接收者：承接由“發起者”發起的一條“待辦”，被選擇來負責處理該“待辦”的用戶；
3. ?轉發者：當接受者承接一條“待辦”后，并將其進行二次轉發的用戶。

2.?任務

根據以上定義的角色，可以劃分出“待辦”流程中的4個主要環節：

1. ?創建：由發起者創建一條“待辦”給對應的接收者；
2. ?處理：接收者開始針對“待辦”進行處理；
3. ?完成：接收者認為“待辦”已經被處理完成；
4. ?確認：發起者確認“待辦”的最終處理結果。

那下面就可以根據“待辦”流程的4個主要環節開展交互設計。

三、待辦的狀態及操作

1. 狀態

在“待辦”流轉過程中中，根據各個環節的任務，分別定義了“待辦”的4種狀態：待處理、處理中、已處理、已關閉。

1. ?待處理：待辦被創建之后，還未被處理的狀態；
2. ?處理中：待辦被接收者著手處理的狀態；
3. ?已處理：待辦被接收者處理完成的狀態；
4. ?已關閉：待辦被認可完成或中途廢棄的狀態。

2.?操作

針對不同狀態下的“待辦”，不同角色的操作是存在差別的，那么可以給出如下“角色——操作”對照表：

“發起者”的用戶：

不管待辦此時處于任何狀態，均不能進行操作。

“接收者”的用戶：

1. ?當待辦處于“待處理”時，可以對其操作“開始處理”或“分發”，參考下文4.2章節；
2. ?當待辦處于“處理中”時，可以對其操作“完成”或“分發”，參考下文4.3章節。

“轉發者”的用戶：

當一條待辦的接收者將其“分發”出去之后，那么TA的角色就變更為“轉發者”，所以不管待辦此時處于任何狀態，均不能進行操作。

“發起者+接收者”的用戶：

當一條由“發起者”創建的待辦最終流轉至TA名下時，此時TA的角色既是“發起者”，也是“接收者”。

1. ?當待辦處于“待處理”或“處理中”時，可以對其操作“開始處理”、“分發”或“關閉”；
2. ?當待辦處于“已處理”時，參考下文4.4章節；

四、待辦的流程

1.?創建

由發起者創建一條“待辦”給對應的接收者，即為“創建”。

在創建過程中，“發起者”首先需要選擇“接收者”，其次還需輸入本條待辦的“標題”和“描述”，完成后即可創建一條“待辦”。

此時待辦狀態為：待處理。

Q：針對“接收者”，要不要允許多選？

A：按照一般的設計邏輯，可以允許選擇多個“接收者”。

經濟學中有一個概念叫邊際效應（Marginal utility），翻譯成諺語就是：一個和尚挑水喝，兩個和尚抬水喝，三個和尚沒水喝。

針對“待辦”，當具有N個“接收者”的時候，每個“接收者”會認為自己只需要承擔1/N的責任，從而產生懈怠。

那么在該產品中，我們希望每一條“待辦”都具有明確的、100%責任的“接收者”，從而保證每個“接收者”都能對之負責，因此“接收者”不允許多選。

2.?處理

當“待辦”被創建之后，系統會將其流轉給對應的“接收者”，此時作為“接收者”的用戶會收到一條系統消息（承接待辦）。

通過點擊“消息”，可預覽待辦內容，包括：待辦標題、待辦狀態、待辦描述、待辦的來源用戶及時間。

點擊某條待辦可查看待辦詳情，其中包括四部分：

1. ?待辦的標題、來源及時間；
2. ?待辦的流程快照，也就是每個流轉環節的信息：參與者、操作、時間、描述；
3. ?當前待辦可以進行的操作，以“待處理”狀態的待辦為例，其操作有：開始處理、分發、查看異常數據詳情；
4. ?待辦所在產品和編號，也就是這條待辦是在哪個產品中流轉，以及流轉的編號；

這里有兩種場景需要思考：

1. 作為“接收者”的用戶需要對該待辦負責，那么TA可以操作“開始處理”，并輸入相關描述，表示開始對此條待辦進行處理。

提交之后待辦的狀態變更為“處理中”。

2. 作為“接收者”的用戶認為此待辦不屬于職責范圍，那么TA可以操作“分發”，并輸入相關描述，以將此條待辦轉發給其他用戶，接收到此條待辦的用戶則繼續循環本章節“處理”的內容。

3.?完成

當“接收者”完成待辦的事項之后，有兩種場景需要考慮：

1. 作為“接收者”的用戶已經完成待辦的全部內容，那么TA可以操作“完成”，并輸入相關描述，表示此條待辦已經處理完成，此條待辦會流轉至“發起者”。

提交之后待辦的狀態變更為“已處理”。

2. 作為“接收者”的用戶只完成了部分內容，需要第三方繼續參與處理，那么TA可以操作“分發”，并輸入相關描述。

以將此條待辦轉發給其他用戶，此時待辦的狀態仍是“處理中”，接收到此條待辦的用戶則繼續循環第2步“處理”。

4.?關閉

當待辦的狀態變更為“已處理”時，此條待辦會被流轉至“發起者”，作為“發起者”的用戶會收到一條待辦消息。

發起者可以查看待辦詳情，通過流程快照確認是否認可處理結果，此時有兩種場景需要考慮：

1. 發起者認可處理結果，那么TA可以操作“關閉”，并輸入相關描述，表示此條待辦已圓滿得到解決。至此，此條待辦完成；

提交之后待辦的狀態變更為“已關閉”。

2. 發起者不認可處理結果，那么TA可以操作“分發”，并輸入相關描述，繼續將該待辦轉發給其他用戶；

提交之后待辦的狀態變更為“待處理”，此時作為新的接收者的用戶會重復上文4.2章節的內容。

五、總結

至此，已完整建立“待辦”流程，用戶可以在產品實現任務、事項的跟蹤和處理。

作為交互設計師，策略就是：“先分解、后聚合”。

首先，明確各環節的對象以及TA所面臨的任務；

其次，針對各環節的任務展開分析，將任務拆解為一套流程；

然后，根據各環節的對象和任務，在產品內找出用戶觸點，并以此開展交互設計；

最后，將所有環節進行聚合，形成完成的閉環設計方案。

作者：胡欣欣，公眾號：吹拉彈唱大師（ID：cltcds）

本文由@吹拉彈唱大師 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議