在上一篇文章中——《交互設計 | 先分解後聚合，“權限申請及審批”的產品閉環》，筆者講解了如何利用“先分解、後聚合” 的設計策略，完成“權限申請及審批”的產品閉環。同樣，在該項目中，“待辦”流程也可以採用相同的策略來開展設計，下文將詳細說明如何設計一套B端產品的“待辦”流程。
一、什麼是“待辦”
一項任務或事項等待辦理就是“待辦”，在企業內常見的“待辦”工具是JIRA，用於項目與事務的跟蹤。
在本產品中，主要功能是監控“異常數據”，為了使得“異常數據”能夠形成一套跟蹤流程，所以需要設計一套“待辦”流程：如果用戶認為某條“異常數據”需要被人為處理，就將其納入“待辦”。通過實時跟蹤、管理該“異常數據”的處理進度，從而形成一套完整的“異常數據”處理機制。
二、角色及任務
1. 角色
一條“待辦”的流轉，必定有“創建方”和“承接方”，可分別定義為：發起者、接收者。
在“待辦”流轉過程中，由於“接收者”是被動選中的，因此可能存在以下兩種場景：
- “接收者”無法獨自處理待辦，需要第三方參與處理；
- “接收者”認為該待辦不屬於職責範圍，需要轉移給第三方。
在以上兩種場景中，“接收者”需要將“待辦”進行二次轉發，此時TA的角色可定義為“轉發者”。
據此，可對“待辦”流程定義三種角色：發起者、接收者、轉發者。
- 發起者：認為某條異常數據需要被人為跟蹤、處理，於是主動創建一條“待辦”的用戶；
- 接收者：承接由“發起者”發起的一條“待辦”，被選擇來負責處理該“待辦”的用戶；
- 轉發者：當接受者承接一條“待辦”後，並將其進行二次轉發的用戶。
2. 任務
根據以上定義的角色，可以劃分出“待辦”流程中的4個主要環節：
- 創建：由發起者創建一條“待辦”給對應的接收者；
- 處理：接收者開始針對“待辦”進行處理；
- 完成：接收者認為“待辦”已經被處理完成；
- 確認：發起者確認“待辦”的最終處理結果。
那下面就可以根據“待辦”流程的4個主要環節開展交互設計。
三、待辦的狀態及操作
1. 狀態
在“待辦”流轉過程中中，根據各個環節的任務，分別定義了“待辦”的4種狀態：待處理、處理中、已處理、已關閉。
- 待處理：待辦被創建之後，還未被處理的狀態；
- 處理中：待辦被接收者著手處理的狀態；
- 已處理：待辦被接收者處理完成的狀態；
- 已關閉：待辦被認可完成或中途廢棄的狀態。
2. 操作
針對不同狀態下的“待辦”，不同角色的操作是存在差別的，那麼可以給出如下“角色——操作”對照表：
“發起者”的用戶：
不管待辦此時處於任何狀態，均不能進行操作。
“接收者”的用戶：
- 當待辦處於“待處理”時，可以對其操作“開始處理”或“分發”，參考下文4.2章節；
- 當待辦處於“處理中”時，可以對其操作“完成”或“分發”，參考下文4.3章節。
“轉發者”的用戶：
當一條待辦的接收者將其“分發”出去之後，那麼TA的角色就變更為“轉發者”，所以不管待辦此時處於任何狀態，均不能進行操作。
“發起者+接收者”的用戶：
當一條由“發起者”創建的待辦最終流轉至TA名下時，此時TA的角色既是“發起者”，也是“接收者”。
- 當待辦處於“待處理”或“處理中”時，可以對其操作“開始處理”、“分發”或“關閉”；
- 當待辦處於“已處理”時，參考下文4.4章節；
四、待辦的流程
1. 創建
由發起者創建一條“待辦”給對應的接收者，即為“創建”。
在創建過程中，“發起者”首先需要選擇“接收者”，其次還需輸入本條待辦的“標題”和“描述”，完成後即可創建一條“待辦”。
此時待辦狀態為：待處理。
Q：針對“接收者”，要不要允許多選？
A：按照一般的設計邏輯，可以允許選擇多個“接收者”。
經濟學中有一個概念叫邊際效應（Marginal utility），翻譯成諺語就是：一個和尚挑水喝，兩個和尚抬水喝，三個和尚沒水喝。
針對“待辦”，當具有N個“接收者”的時候，每個“接收者”會認為自己只需要承擔1/N的責任，從而產生懈怠。
那麼在該產品中，我們希望每一條“待辦”都具有明確的、100%責任的“接收者”，從而保證每個“接收者”都能對之負責，因此“接收者”不允許多選。
2. 處理
當“待辦”被創建之後，系統會將其流轉給對應的“接收者”，此時作為“接收者”的用戶會收到一條系統消息（承接待辦）。
通過點擊“消息”，可預覽待辦內容，包括：待辦標題、待辦狀態、待辦描述、待辦的來源用戶及時間。
點擊某條待辦可查看待辦詳情，其中包括四部分：
- 待辦的標題、來源及時間；
- 待辦的流程快照，也就是每個流轉環節的信息：參與者、操作、時間、描述；
- 當前待辦可以進行的操作，以“待處理”狀態的待辦為例，其操作有：開始處理、分發、查看異常數據詳情；
- 待辦所在產品和編號，也就是這條待辦是在哪個產品中流轉，以及流轉的編號；
這裡有兩種場景需要思考：
1. 作為“接收者”的用戶需要對該待辦負責，那麼TA可以操作“開始處理”，並輸入相關描述，表示開始對此條待辦進行處理。
提交之後待辦的狀態變更為“處理中”。
2. 作為“接收者”的用戶認為此待辦不屬於職責範圍，那麼TA可以操作“分發”，並輸入相關描述，以將此條待辦轉發給其他用戶，接收到此條待辦的用戶則繼續循環本章節“處理”的內容。
3. 完成
當“接收者”完成待辦的事項之後，有兩種場景需要考慮：
1. 作為“接收者”的用戶已經完成待辦的全部內容，那麼TA可以操作“完成”，並輸入相關描述，表示此條待辦已經處理完成，此條待辦會流轉至“發起者”。
提交之後待辦的狀態變更為“已處理”。
2. 作為“接收者”的用戶只完成了部分內容，需要第三方繼續參與處理，那麼TA可以操作“分發”，並輸入相關描述。
以將此條待辦轉發給其他用戶，此時待辦的狀態仍是“處理中”，接收到此條待辦的用戶則繼續循環第2步“處理”。
4. 關閉
當待辦的狀態變更為“已處理”時，此條待辦會被流轉至“發起者”，作為“發起者”的用戶會收到一條待辦消息。
發起者可以查看待辦詳情，通過流程快照確認是否認可處理結果，此時有兩種場景需要考慮：
1. 發起者認可處理結果，那麼TA可以操作“關閉”，並輸入相關描述，表示此條待辦已圓滿得到解決。至此，此條待辦完成；
提交之後待辦的狀態變更為“已關閉”。
2. 發起者不認可處理結果，那麼TA可以操作“分發”，並輸入相關描述，繼續將該待辦轉發給其他用戶；
提交之後待辦的狀態變更為“待處理”，此時作為新的接收者的用戶會重複上文4.2章節的內容。
五、總結
至此，已完整建立“待辦”流程，用戶可以在產品實現任務、事項的跟蹤和處理。
作為交互設計師，策略就是：“先分解、後聚合”。
首先，明確各環節的對象以及TA所面臨的任務；
其次，針對各環節的任務展開分析，將任務拆解為一套流程；
然後，根據各環節的對象和任務，在產品內找出用戶觸點，並以此開展交互設計；
最後，將所有環節進行聚合，形成完成的閉環設計方案。
題圖來自Unsplash, 基於CC0協議
閱讀更多 人人都是產品經理 的文章
