從0到1,如何設計一套B端產品的“待辦”流程
在上一篇文章中——《交互設計 | 先分解后聚合,“權限申請及審批”的產品閉環》,筆者講解了如何利用“先分解、后聚合” 的設計策略,完成“權限申請及審批”的產品閉環。同樣,在該項目中,“待辦”流程也可以采用相同的策略來開展設計,下文將詳細說明如何設計一套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所面臨的任務;
其次,針對各環節的任務展開分析,將任務拆解為一套流程;
然后,根據各環節的對象和任務,在產品內找出用戶觸點,并以此開展交互設計;
最后,將所有環節進行聚合,形成完成的閉環設計方案。
作者:胡欣欣,公眾號:吹拉彈唱大師(ID:cltcds)
本文由@吹拉彈唱大師 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議
請教一下,待辦所對應的已辦該怎么顯示?
會有一個通知中心,其中包括待辦列表,已辦可以通過狀態篩選出來
學到了!
超棒,圖、文字都很棒。學習 ; ??
很棒 支持一下
請教一下,你在設置接受者時,只支持單選,如果作為上級管理者,需要下級所有人(比如12個人)對自己負責的事情做同樣的操作,難道上級管理者需要創建12條“待辦”嗎?
你對這樣的情景是如何處理的?
如果需要下級所有人參與,這種組織行為必然會有一個唯一“負責人”;其次,“待辦”在處理的過程中,允許二次轉發,A完成之后轉發給B繼續處理…以此完成12個人的流轉。
12個人本來是同時可以做的行為,按照你的邏輯需要12個人依次處理啦?你覺得合適嗎?
待辦的分發,不影響12個人同時處理,這個只是一套線上流程,具體線下的行為,由各組織負責人來推進。
都是要線上的呀!要給12個人分發同一個待辦,你的說法是每個待辦只能有一個接收人,那豈不是需要建12次嗎?
建議在設計的時候,可以新增一個選項:待辦發放類型。支持下拉框選擇:指定發放給個人、批量發放給多人。備注說明:批量發放給多人時,每個接收人都會收到一條待辦。
很棒!我訂閱你了,大師!
謝謝~
查看待辦詳情這個環節可以不用做到流程里,而是待辦下的一個可返回的分支,這樣鏈條更短一些
你說的有道理,謝謝~
果然是ue出身,圖畫的真不錯。加油吧。
哈哈 謝謝
最近在研究UML,個人覺得【待辦】的描述,可以用帶泳道的活動圖和針對于“待辦”對象的狀態機圖描述起來會更加清晰流暢,個人愚見~
感謝指導,我會繼續努力提升~
您好,我有一些不明白的地方,泳道流程圖和狀態機圖是分開兩張圖描述比較好呢,還是二者同時放入泳道描述比較好呢?
??
??