全栈工程师?
嗯.....目前并不是!

從0到1,如何設計一套B端產品的“待辦”流程

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

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《從0到1,如何設計一套B端產品的“待辦”流程》
文章链接:https://www.pmbear.com/%e5%be%9e0%e5%88%b01%ef%bc%8c%e5%a6%82%e4%bd%95%e8%a8%ad%e8%a8%88%e4%b8%80%e5%a5%97b%e7%ab%af%e7%94%a2%e5%93%81%e7%9a%84%e5%be%85%e8%be%a6%e6%b5%81%e7%a8%8b/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们