編輯導(dǎo)語：在產(chǎn)品設(shè)計的過程中，B端系統(tǒng)與用戶之間信息的交互十分關(guān)鍵。本篇文章筆者就以自身的工作經(jīng)驗，來給大家說一下如何進(jìn)行B端通知提醒功能的設(shè)計，一起來學(xué)習(xí)一下。

在產(chǎn)品設(shè)計過程中，B端系統(tǒng)需要與用戶進(jìn)行信息的交互。

網(wǎng)上已經(jīng)有較多的C端消息通知系統(tǒng)設(shè)計的文章，但是B端消息通知系統(tǒng)的設(shè)計，與C端還是有一些側(cè)重點的區(qū)別。

本文就根據(jù)筆者自身的工作經(jīng)驗，來給大家介紹筆者對一下B端系統(tǒng)通知提醒功能設(shè)計思考。

一、通知提醒功能是什么

在開始進(jìn)行B端通知提醒系統(tǒng)的設(shè)計前，我們有必要THINK IN UML，將通知提醒抽象成一個用例（use case），以方便后續(xù)具體的功能設(shè)計。

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

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

• 參與者：驅(qū)動系統(tǒng)，用例是其愿望的體現(xiàn)，可以認(rèn)為是“我”；
• 前置條件：啟動用例的前提，即要煮飯，需要先有米；
• 場景：煮飯的方式有很多種，可以用鐵鍋也可以用電飯煲，場景是用例在不同條件下的處理方式；
• 后置條件：煮飯后，米變成了米飯，表示用例執(zhí)行的結(jié)果。

那么通知提醒這個用例種，參與者或者說是業(yè)務(wù)主角（business actor）是OMS系統(tǒng)的用戶嗎？

在通知提醒這個用例下，顯然不是。業(yè)務(wù)主角應(yīng)滿足以下三個條件：

1. 應(yīng)是主動向系統(tǒng)發(fā)出的動作；
2. 擁有完整的業(yè)務(wù)目標(biāo)；
3. 系統(tǒng)是為他而服務(wù)的。

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

那么在通知提醒這個用例中，我們發(fā)現(xiàn)用戶只是業(yè)務(wù)工人（business worker），在業(yè)務(wù)模型中是被動的去完成主角的目標(biāo)的。

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

系統(tǒng)是為主角服務(wù)的，業(yè)務(wù)主角的確認(rèn)深刻的影響了功能設(shè)計的權(quán)衡取舍，后面會詳細(xì)介紹。

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

• 前置條件：提醒事件，如果沒有提醒事件，則無法進(jìn)行提醒；
• 場景：通知提醒的觸達(dá)手段，B端系統(tǒng)中有多樣化的觸達(dá)手段，以適應(yīng)不同的條件，這個后面會進(jìn)行詳述；
• 后置條件：通知提醒的結(jié)果，B端系統(tǒng)中通知提醒的結(jié)果和C端不同，B端通知的結(jié)果一般都是提醒事件的消失，而非提醒消息本身的已讀。

提醒事件

一個提醒事件可以表述為：“當(dāng)某物滿足什么條件時需進(jìn)行通知提醒”。

人驅(qū)動系統(tǒng)、事體現(xiàn)過程、物記錄結(jié)果、規(guī)則控制運(yùn)行，提醒事件是上游用例的結(jié)果或者說輸出物。

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

那么B端系統(tǒng)有哪些種類的提醒事件呢?

1. 系統(tǒng)正常作業(yè)過程中需要業(yè)務(wù)工人參與的事件

• 發(fā)貨單在已創(chuàng)建狀態(tài)時需進(jìn)行通知提醒；
• 發(fā)貨地址發(fā)生變化時需進(jìn)行通知提醒；
• 顧客催單時需進(jìn)行通知提醒；
• 在系統(tǒng)中預(yù)約完成的事項已完成時。

2. 系統(tǒng)作業(yè)異常時需要業(yè)務(wù)工人處理的事件

• 物流系統(tǒng)配送異常時需進(jìn)行通知提醒；
• 根據(jù)預(yù)設(shè)條件發(fā)現(xiàn)數(shù)據(jù)異常時需進(jìn)行通知提醒；
• 揀貨超時時需要進(jìn)行通知提醒。

3. 系統(tǒng)服務(wù)異常時需要業(yè)務(wù)工人介入處理的事件

• 服務(wù)器宕機(jī)時需要提醒；
• 接口服務(wù)異常時需要提醒。

4. 產(chǎn)品運(yùn)營/客戶方運(yùn)營手動進(jìn)行的信息分發(fā)需要業(yè)務(wù)工人知悉的事件

• 系統(tǒng)升級公告；
• 停止服務(wù)公告；
• 系統(tǒng)能力變更公告；
• 要求店員開啟自動接單功能的公告。

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

觸達(dá)手段

一個觸達(dá)手段可以表述為：“在什么地方（WHERE）、什么時機(jī)（WHEN）、以何種途徑（HOW）、通知誰（WHO）、如何消費(fèi)（WAY TO FININSH）”。

B端系統(tǒng)與C端系統(tǒng)在觸達(dá)手段上是有一些區(qū)別的，差異如下：

1. 業(yè)務(wù)工人的細(xì)分角色較多，需執(zhí)行差異化的觸達(dá)策略

不同業(yè)務(wù)工人在企業(yè)內(nèi)部的角色分工和所屬組織架構(gòu)的不同，信息焦點所屬載體各不相同。

如運(yùn)營人員可能并不會一直盯著OMS系統(tǒng)，但是一定保持著企業(yè)微信登錄，那么就可以選擇使用企業(yè)微信進(jìn)行信息的觸達(dá)。

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

不同的業(yè)務(wù)工人關(guān)注焦點不同，店員更關(guān)注哪些訂單需要揀貨了，而運(yùn)維人員更關(guān)注系統(tǒng)是否穩(wěn)定運(yùn)行，故要將不同的提醒事件給相對應(yīng)的角色進(jìn)行提醒；

2. SAAS化的B端業(yè)務(wù)繁雜，千人千面,需支持觸達(dá)方式的配置

使用同一套系統(tǒng)的客戶，由于業(yè)態(tài)不同和組織架構(gòu)的不同，業(yè)務(wù)工人接受信息傳遞的載體，以及接受到提醒的方式也不同，需支持配置，以適應(yīng)千人千面的業(yè)務(wù)場景。

配置的設(shè)計可參考筆者的這篇文章：干貨總結(jié)：我對B端系統(tǒng)配置功能設(shè)計的思考 | 人人都是產(chǎn)品經(jīng)理 (woshipm.com)

3. 一切為了業(yè)務(wù)的正常開展

在B端系統(tǒng)中，B端的用戶在核心的業(yè)務(wù)用例中，擔(dān)任業(yè)務(wù)工人的角色，例如門店人員必須及時揀貨，否則系統(tǒng)無法完成訂單履約業(yè)務(wù)。

為滿足業(yè)務(wù)的正常開展，我們可采取的設(shè)計思路如下，即使一些在C端產(chǎn)品上會被認(rèn)為用戶體驗很差的受手段：

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

當(dāng)然以上手段不是絕對的，需要我們根據(jù)具體的提醒事件靈活裁剪設(shè)計思路。

那么我們可以知道B端的觸達(dá)手段有以下特點：

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

4. 注意平衡消息量

在保證提醒效果的前提下，需要平衡好消息的提醒數(shù)量，方法有以下幾種：

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

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

2）消息合并提醒

• 合并方案1： 按照作業(yè)方式提醒：有多筆發(fā)貨單且還未被提醒，則應(yīng)只提醒一次即可，此時不應(yīng)每筆單據(jù)都提醒一遍；
• 合并方案2： 按照單據(jù)聚合提醒：一個單據(jù)如果先創(chuàng)建后立即接單，如果此時新訂單的消息未提醒，則應(yīng)直接提醒訂單需揀貨的消息。

那么B端有哪些觸達(dá)手段呢，筆者做了當(dāng)前我們系統(tǒng)中觸達(dá)手段的整理，可能并不完整，供大家參考：

二、應(yīng)用實例：以系統(tǒng)內(nèi)通知提醒設(shè)計為例

那么文章的最后，給大家分享一下，我做發(fā)貨單系統(tǒng)內(nèi)提醒功能時的設(shè)計流程吧。

1. 整理業(yè)務(wù)流程

可以通過簡單的流程圖，來梳理期望實現(xiàn)的通知提醒的效果。

2. 接著可以按照標(biāo)準(zhǔn)化的文檔，收集整理需求點，下面給一個我在用的整理模板：

3. 補(bǔ)充說明一下提醒文案的設(shè)計：

• 信息脫敏：提醒文案中不應(yīng)將單據(jù)中的敏感信息提供出來，如顧客的姓名電話等；
• 重點突出：如果是系統(tǒng)通知，則應(yīng)展示通知的重要性和時間節(jié)點，如果是訂單，則應(yīng)突出展示所屬平臺以及需要作業(yè)的時間，需根據(jù)具體業(yè)務(wù)確定；
• 角色明確：如一個提醒要同時發(fā)給多個用戶角色，則應(yīng)標(biāo)注清楚是哪種角色需要重點關(guān)注此信息；
• 操作清晰：明確告知在什么時間去哪個系統(tǒng)哪個模塊對哪個單據(jù)做什么。

4. 當(dāng)然接下來我們還需要整理相關(guān)頁面，優(yōu)化交互體驗。

功能開發(fā)完成后注意交付——跟進(jìn)——復(fù)盤——迭代，這些不再累述。

三、結(jié)語

B端系統(tǒng)消息通知設(shè)計與C端消息通知設(shè)計有很多共通之處。

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

本文由 @kathic 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議。