我對B端通知提醒功能的設計思考

ka
6 評論 20743 瀏覽 242 收藏 14 分鐘

編輯導語:在產品設計的過程中,B端系統與用戶之間信息的交互十分關鍵。本篇文章筆者就以自身的工作經驗,來給大家說一下如何進行B端通知提醒功能的設計,一起來學習一下。

在產品設計過程中,B端系統需要與用戶進行信息的交互。

網上已經有較多的C端消息通知系統設計的文章,但是B端消息通知系統的設計,與C端還是有一些側重點的區別。

本文就根據筆者自身的工作經驗,來給大家介紹筆者對一下B端系統通知提醒功能設計思考。

一、通知提醒功能是什么

在開始進行B端通知提醒系統的設計前,我們有必要THINK IN UML,將通知提醒抽象成一個用例(use case),以方便后續具體的功能設計。

一個完整的用例定義由參與者、前置條件、場景、后置條件構成。

為方便大家理解,我們以煮飯這一個用例來解釋用例中的參與者、前置條件、場景、后置條件。

  • 參與者:驅動系統,用例是其愿望的體現,可以認為是“我”;
  • 前置條件:啟動用例的前提,即要煮飯,需要先有米;
  • 場景:煮飯的方式有很多種,可以用鐵鍋也可以用電飯煲,場景是用例在不同條件下的處理方式;
  • 后置條件:煮飯后,米變成了米飯,表示用例執行的結果。

那么通知提醒這個用例種,參與者或者說是業務主角(business actor)是OMS系統的用戶嗎?

在通知提醒這個用例下,顯然不是。業務主角應滿足以下三個條件:

  1. 應是主動向系統發出的動作;
  2. 擁有完整的業務目標;
  3. 系統是為他而服務的。

同時,我們知道參與者通過可以是輸入的一段指令,一筆訂單,一個商品信息,不一定是一個有生命的人。

那么在通知提醒這個用例中,我們發現用戶只是業務工人(business worker),在業務模型中是被動的去完成主角的目標的。

那么按照上述的條件,我們可以將【通知提醒】這一指令抽象為業務主角,其愿望或者說目的是為了保證業務正常的開展。

系統是為主角服務的,業務主角的確認深刻的影響了功能設計的權衡取舍,后面會詳細介紹。

那么在這個用例中,前置條件、場景、后置條件怎么理解呢?

  • 前置條件:提醒事件,如果沒有提醒事件,則無法進行提醒;
  • 場景:通知提醒的觸達手段,B端系統中有多樣化的觸達手段,以適應不同的條件,這個后面會進行詳述;
  • 后置條件:通知提醒的結果,B端系統中通知提醒的結果和C端不同,B端通知的結果一般都是提醒事件的消失,而非提醒消息本身的已讀。

提醒事件

一個提醒事件可以表述為:“當某物滿足什么條件時需進行通知提醒”。

人驅動系統、事體現過程、物記錄結果、規則控制運行,提醒事件是上游用例的結果或者說輸出物。

所有的提醒事件都是圍繞著“物”這么一個實體類開展的。

那么B端系統有哪些種類的提醒事件呢?

1. 系統正常作業過程中需要業務工人參與的事件

  • 發貨單在已創建狀態時需進行通知提醒;
  • 發貨地址發生變化時需進行通知提醒;
  • 顧客催單時需進行通知提醒;
  • 在系統中預約完成的事項已完成時。

2. 系統作業異常時需要業務工人處理的事件

  • 物流系統配送異常時需進行通知提醒;
  • 根據預設條件發現數據異常時需進行通知提醒;
  • 揀貨超時時需要進行通知提醒。

3. 系統服務異常時需要業務工人介入處理的事件

  • 服務器宕機時需要提醒;
  • 接口服務異常時需要提醒。

4. 產品運營/客戶方運營手動進行的信息分發需要業務工人知悉的事件

  • 系統升級公告;
  • 停止服務公告;
  • 系統能力變更公告;
  • 要求店員開啟自動接單功能的公告。

當然,還有一些操作時的即時提醒,這些提醒只是用戶操作用例中的一個需求點,不在B端通知提醒用例中,本文暫不涉及。

觸達手段

一個觸達手段可以表述為:“在什么地方(WHERE)、什么時機(WHEN)、以何種途徑(HOW)、通知誰(WHO)、如何消費(WAY TO FININSH)”。

B端系統與C端系統在觸達手段上是有一些區別的,差異如下:

1. 業務工人的細分角色較多,需執行差異化的觸達策略

不同業務工人在企業內部的角色分工和所屬組織架構的不同,信息焦點所屬載體各不相同。

如運營人員可能并不會一直盯著OMS系統,但是一定保持著企業微信登錄,那么就可以選擇使用企業微信進行信息的觸達。

又如店員可能并不是一直守在收銀機旁,但是不會離開門店,這個時候可以使用聲音提醒的方式;

不同的業務工人關注焦點不同,店員更關注哪些訂單需要揀貨了,而運維人員更關注系統是否穩定運行,故要將不同的提醒事件給相對應的角色進行提醒;

2. SAAS化的B端業務繁雜,千人千面,需支持觸達方式的配置

使用同一套系統的客戶,由于業態不同和組織架構的不同,業務工人接受信息傳遞的載體,以及接受到提醒的方式也不同,需支持配置,以適應千人千面的業務場景。

配置的設計可參考筆者的這篇文章:干貨總結:我對B端系統配置功能設計的思考 | 人人都是產品經理 (woshipm.com)

3. 一切為了業務的正常開展

在B端系統中,B端的用戶在核心的業務用例中,擔任業務工人的角色,例如門店人員必須及時揀貨,否則系統無法完成訂單履約業務。

為滿足業務的正常開展,我們可采取的設計思路如下,即使一些在C端產品上會被認為用戶體驗很差的受手段:

  • 多種觸達方式并用:根據業務工人角色,可以通過將系統內提醒和系統外提醒并行的方式,組合使用,覆蓋業務工人所屬的時間和空間縫隙;
  • 循環觸達:當提醒事件未消失時,即時用戶已確認收到了提醒,在一段時間后,也應再次循環提醒;
  • 觸達升級:當業務工人未反饋已知曉時,向業務工人所屬組織結構的上級提醒,進行觸達的升級;
  • 強制閱讀:強制要求閱讀N秒,且在閱讀完成前無法做其他業務,以保證業務工人確實已經閱讀相關提醒;
  • 強制反饋:要求業務工人必須點擊確認已收到消息;
  • 操作指引性的觸達文案:例如“請前往xx系統xx模塊,對xx單據做xx操作”,以減少業務工人因不熟悉系統功能而無法進行操作的問題。并可在文案中嵌入鏈接以直接跳轉到相應頁面。

當然以上手段不是絕對的,需要我們根據具體的提醒事件靈活裁剪設計思路。

那么我們可以知道B端的觸達手段有以下特點:

  • 觸達途徑穩健:適用多種途徑手段保證消息確實給到了相應用戶,同時要求用戶必須明確反饋自己已知悉此消息;
  • 消費方式嚴格:大部分B端提醒消息并不是標記已閱就可以消費的,必須得提醒的事件不成立時,才會真正消費提醒;
  • 重時效性:以O2O訂單為例,顧客支付完成后,如門店在5分鐘內未接單則系統會自動取消訂單,故消息的觸達必須及時,否則業務無法正常開展;
  • 重準確性:觸達到用戶的信息必須準確,準確還體現在一致性上,即通過觸發方式傳遞給用戶的信息,必須和用戶主動在系統中查詢的信息一致,不能遺漏或信息差異。

4. 注意平衡消息量

在保證提醒效果的前提下,需要平衡好消息的提醒數量,方法有以下幾種:

1)消息的分級與降級提醒

  • 將觸達手段分為強、中、弱提醒強度等級,根據提醒事件選擇合適等級的提醒手段,強等級的提醒不應頻繁使用;
  • 同時可將一個消息先強等級提醒,然后在循環觸達過程中選擇較低強度的途徑進行降級提醒,如訂單揀貨消息可以先通過聲音提醒,接著通過文字滾動循環提醒。

2)消息合并提醒

  • 合并方案1: 按照作業方式提醒:有多筆發貨單且還未被提醒,則應只提醒一次即可,此時不應每筆單據都提醒一遍;
  • 合并方案2: 按照單據聚合提醒:一個單據如果先創建后立即接單,如果此時新訂單的消息未提醒,則應直接提醒訂單需揀貨的消息。

那么B端有哪些觸達手段呢,筆者做了當前我們系統中觸達手段的整理,可能并不完整,供大家參考:

二、應用實例:以系統內通知提醒設計為例

那么文章的最后,給大家分享一下,我做發貨單系統內提醒功能時的設計流程吧。

1. 整理業務流程

可以通過簡單的流程圖,來梳理期望實現的通知提醒的效果。

2. 接著可以按照標準化的文檔,收集整理需求點,下面給一個我在用的整理模板:

3. 補充說明一下提醒文案的設計:

  • 信息脫敏:提醒文案中不應將單據中的敏感信息提供出來,如顧客的姓名電話等;
  • 重點突出:如果是系統通知,則應展示通知的重要性和時間節點,如果是訂單,則應突出展示所屬平臺以及需要作業的時間,需根據具體業務確定;
  • 角色明確:如一個提醒要同時發給多個用戶角色,則應標注清楚是哪種角色需要重點關注此信息;
  • 操作清晰:明確告知在什么時間去哪個系統哪個模塊對哪個單據做什么。

4. 當然接下來我們還需要整理相關頁面,優化交互體驗。

功能開發完成后注意交付——跟進——復盤——迭代,這些不再累述。

三、結語

B端系統消息通知設計與C端消息通知設計有很多共通之處。

但是也略有差別,需要在設計過程中注意判斷,不可生搬硬套。

 

本文由 @kathic 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 前來觀摩學習

    來自江蘇 回復
  2. 好棒

    來自浙江 回復
  3. 干貨,很實用!

    來自湖北 回復
    1. 互相學習,共同進步~~

      來自上海 回復
  4. 康總yyds

    來自上海 回復
  5. 原來菜鳥裹裹的物流通知是這樣來的,每天一個關于生活的產品知識。

    來自廣西 回復