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

22 評論 33362 瀏覽 248 收藏 14 分鐘

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 請教一下,待辦所對應的已辦該怎么顯示?

    來自內蒙古 回復
    1. 會有一個通知中心,其中包括待辦列表,已辦可以通過狀態篩選出來

      回復
  2. 學到了!

    回復
  3. 超棒,圖、文字都很棒。學習 ; ??

    來自北京 回復
  4. 很棒 支持一下

    回復
  5. 請教一下,你在設置接受者時,只支持單選,如果作為上級管理者,需要下級所有人(比如12個人)對自己負責的事情做同樣的操作,難道上級管理者需要創建12條“待辦”嗎?
    你對這樣的情景是如何處理的?

    來自上海 回復
    1. 如果需要下級所有人參與,這種組織行為必然會有一個唯一“負責人”;其次,“待辦”在處理的過程中,允許二次轉發,A完成之后轉發給B繼續處理…以此完成12個人的流轉。

      來自江蘇 回復
    2. 12個人本來是同時可以做的行為,按照你的邏輯需要12個人依次處理啦?你覺得合適嗎?

      來自上海 回復
    3. 待辦的分發,不影響12個人同時處理,這個只是一套線上流程,具體線下的行為,由各組織負責人來推進。

      來自江蘇 回復
    4. 都是要線上的呀!要給12個人分發同一個待辦,你的說法是每個待辦只能有一個接收人,那豈不是需要建12次嗎?

      來自上海 回復
    5. 建議在設計的時候,可以新增一個選項:待辦發放類型。支持下拉框選擇:指定發放給個人、批量發放給多人。備注說明:批量發放給多人時,每個接收人都會收到一條待辦。

      來自廣東 回復
  6. 很棒!我訂閱你了,大師!

    來自浙江 回復
    1. 謝謝~

      來自江蘇 回復
  7. 查看待辦詳情這個環節可以不用做到流程里,而是待辦下的一個可返回的分支,這樣鏈條更短一些

    來自四川 回復
    1. 你說的有道理,謝謝~

      來自江蘇 回復
  8. 果然是ue出身,圖畫的真不錯。加油吧。

    來自北京 回復
    1. 哈哈 謝謝

      來自江蘇 回復
  9. 最近在研究UML,個人覺得【待辦】的描述,可以用帶泳道的活動圖和針對于“待辦”對象的狀態機圖描述起來會更加清晰流暢,個人愚見~

    來自天津 回復
    1. 感謝指導,我會繼續努力提升~

      回復
    2. 您好,我有一些不明白的地方,泳道流程圖和狀態機圖是分開兩張圖描述比較好呢,還是二者同時放入泳道描述比較好呢?

      來自湖北 回復
  10. ??

    來自陜西 回復
    1. ??

      來自江蘇 回復