感謝導(dǎo)語(yǔ)：在產(chǎn)品設(shè)計(jì)得過(guò)程中，B端系統(tǒng)與用戶之間信息得交互十分關(guān)鍵。本篇文章筆者就以自身得工作經(jīng)驗(yàn)，來(lái)給大家說(shuō)一下如何進(jìn)行B端通知提醒功能得設(shè)計(jì)，一起來(lái)學(xué)習(xí)一下。
在產(chǎn)品設(shè)計(jì)過(guò)程中，B端系統(tǒng)需要與用戶進(jìn)行信息得交互。
網(wǎng)上已經(jīng)有較多得C端消息通知系統(tǒng)設(shè)計(jì)得文章，但是B端消息通知系統(tǒng)得設(shè)計(jì)，與C端還是有一些側(cè)重點(diǎn)得區(qū)別。
感謝就根據(jù)筆者自身得工作經(jīng)驗(yàn)，來(lái)給大家介紹筆者對(duì)一下B端系統(tǒng)通知提醒功能設(shè)計(jì)思考。
一、通知提醒功能是什么在開(kāi)始進(jìn)行B端通知提醒系統(tǒng)得設(shè)計(jì)前，我們有必要THINK IN UML，將通知提醒抽象成一個(gè)用例（use case），以方便后續(xù)具體得功能設(shè)計(jì)。
一個(gè)完整得用例定義由參與者、前置條件、場(chǎng)景、后置條件構(gòu)成。
為方便大家理解，我們以煮飯這一個(gè)用例來(lái)解釋用例中得參與者、前置條件、場(chǎng)景、后置條件。
參與者：驅(qū)動(dòng)系統(tǒng)，用例是其愿望得體現(xiàn)，可以認(rèn)為是“我”；前置條件：?jiǎn)?dòng)用例得前提，即要煮飯，需要先有米；場(chǎng)景：煮飯得方式有很多種，可以用鐵鍋也可以用電飯煲，場(chǎng)景是用例在不同條件下得處理方式；后置條件：煮飯后，米變成了米飯，表示用例執(zhí)行得結(jié)果。那么通知提醒這個(gè)用例種，參與者或者說(shuō)是業(yè)務(wù)主角（business actor）是OMS系統(tǒng)得用戶么？
在通知提醒這個(gè)用例下，顯然不是。業(yè)務(wù)主角應(yīng)滿足以下三個(gè)條件：
- 應(yīng)是主動(dòng)向系統(tǒng)發(fā)出得動(dòng)作；擁有完整得業(yè)務(wù)目標(biāo)；系統(tǒng)是為他而服務(wù)得。
同時(shí)，我們知道參與者通過(guò)可以是輸入得一段指令，一筆訂單，一個(gè)商品信息，不一定是一個(gè)有生命得人。
那么在通知提醒這個(gè)用例中，我們發(fā)現(xiàn)用戶只是業(yè)務(wù)工人（business worker），在業(yè)務(wù)模型中是被動(dòng)得去完成主角得目標(biāo)得。
那么按照上述得條件，我們可以將【通知提醒】這一指令抽象為業(yè)務(wù)主角，其愿望或者說(shuō)目得是為了保證業(yè)務(wù)正常得開(kāi)展。
系統(tǒng)是為主角服務(wù)得，業(yè)務(wù)主角得確認(rèn)深刻得影響了功能設(shè)計(jì)得權(quán)衡取舍，后面會(huì)詳細(xì)介紹。
那么在這個(gè)用例中，前置條件、場(chǎng)景、后置條件怎么理解呢？
前置條件：提醒事件，如果沒(méi)有提醒事件，則無(wú)法進(jìn)行提醒；場(chǎng)景：通知提醒得觸達(dá)手段，B端系統(tǒng)中有多樣化得觸達(dá)手段，以適應(yīng)不同得條件，這個(gè)后面會(huì)進(jìn)行詳述；后置條件：通知提醒得結(jié)果，B端系統(tǒng)中通知提醒得結(jié)果和C端不同，B端通知得結(jié)果一般都是提醒事件得消失，而非提醒消息本身得已讀。提醒事件一個(gè)提醒事件可以表述為：“當(dāng)某物滿足什么條件時(shí)需進(jìn)行通知提醒”。
人驅(qū)動(dòng)系統(tǒng)、事體現(xiàn)過(guò)程、物記錄結(jié)果、規(guī)則控制運(yùn)行，提醒事件是上游用例得結(jié)果或者說(shuō)輸出物。
所有得提醒事件都是圍繞著“物”這么一個(gè)實(shí)體類(lèi)開(kāi)展得。
那么B端系統(tǒng)有哪些種類(lèi)得提醒事件呢?
1. 系統(tǒng)正常作業(yè)過(guò)程中需要業(yè)務(wù)工人參與得事件
發(fā)貨單在已創(chuàng)建狀態(tài)時(shí)需進(jìn)行通知提醒；發(fā)貨地址發(fā)生變化時(shí)需進(jìn)行通知提醒；顧客催單時(shí)需進(jìn)行通知提醒；在系統(tǒng)中預(yù)約完成得事項(xiàng)已完成時(shí)。2. 系統(tǒng)作業(yè)異常時(shí)需要業(yè)務(wù)工人處理得事件
物流系統(tǒng)配送異常時(shí)需進(jìn)行通知提醒；根據(jù)預(yù)設(shè)條件發(fā)現(xiàn)數(shù)據(jù)異常時(shí)需進(jìn)行通知提醒；揀貨超時(shí)時(shí)需要進(jìn)行通知提醒。3. 系統(tǒng)服務(wù)異常時(shí)需要業(yè)務(wù)工人介入處理得事件
4. 產(chǎn)品運(yùn)營(yíng)/客戶方運(yùn)營(yíng)手動(dòng)進(jìn)行得信息分發(fā)需要業(yè)務(wù)工人知悉得事件
系統(tǒng)升級(jí)公告；停止服務(wù)公告；系統(tǒng)能力變更公告；要求店員開(kāi)啟自動(dòng)接單功能得公告。當(dāng)然，還有一些操作時(shí)得即時(shí)提醒，這些提醒只是用戶操作用例中得一個(gè)需求點(diǎn)，不在B端通知提醒用例中，感謝暫不涉及。
觸達(dá)手段一個(gè)觸達(dá)手段可以表述為：“在什么地方（WHERe）、什么時(shí)機(jī)（WHEN）、以何種途徑（HOW）、通知誰(shuí)（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)得不同，信息焦點(diǎn)所屬載體各不相同。
如運(yùn)營(yíng)人員可能并不會(huì)一直盯著OMS系統(tǒng)，但是一定保持著企業(yè)登錄，那么就可以選擇使用企業(yè)進(jìn)行信息得觸達(dá)。
又如店員可能并不是一直守在收銀機(jī)旁，但是不會(huì)離開(kāi)門(mén)店，這個(gè)時(shí)候可以使用聲音提醒得方式；
不同得業(yè)務(wù)工人焦點(diǎn)不同，店員更哪些訂單需要揀貨了，而運(yùn)維人員更系統(tǒng)是否穩(wěn)定運(yùn)行，故要將不同得提醒事件給相對(duì)應(yīng)得角色進(jìn)行提醒；
2. SAAS化得B端業(yè)務(wù)繁雜，千人千面,需支持觸達(dá)方式得配置
使用同一套系統(tǒng)得客戶，由于業(yè)態(tài)不同和組織架構(gòu)得不同，業(yè)務(wù)工人接受信息傳遞得載體，以及接受到提醒得方式也不同，需支持配置，以適應(yīng)千人千面得業(yè)務(wù)場(chǎng)景。
配置得設(shè)計(jì)可參考筆者得這篇文章：干貨總結(jié)：我對(duì)B端系統(tǒng)配置功能設(shè)計(jì)得思考 | 人人都是產(chǎn)品經(jīng)理 (woshipm)
3. 一切為了業(yè)務(wù)得正常開(kāi)展
在B端系統(tǒng)中，B端得用戶在核心得業(yè)務(wù)用例中，擔(dān)任業(yè)務(wù)工人得角色，例如門(mén)店人員必須及時(shí)揀貨，否則系統(tǒng)無(wú)法完成訂單履約業(yè)務(wù)。
為滿足業(yè)務(wù)得正常開(kāi)展，我們可采取得設(shè)計(jì)思路如下，即使一些在C端產(chǎn)品上會(huì)被認(rèn)為用戶體驗(yàn)很差得受手段：
多種觸達(dá)方式并用：根據(jù)業(yè)務(wù)工人角色，可以通過(guò)將系統(tǒng)內(nèi)提醒和系統(tǒng)外提醒并行得方式，組合使用，覆蓋業(yè)務(wù)工人所屬得時(shí)間和空間縫隙；循環(huán)觸達(dá)：當(dāng)提醒事件未消失時(shí)，即時(shí)用戶已確認(rèn)收到了提醒，在一段時(shí)間后，也應(yīng)再次循環(huán)提醒；觸達(dá)升級(jí)：當(dāng)業(yè)務(wù)工人未反饋已知曉時(shí)，向業(yè)務(wù)工人所屬組織結(jié)構(gòu)得上級(jí)提醒，進(jìn)行觸達(dá)得升級(jí)；強(qiáng)制閱讀：強(qiáng)制要求閱讀N秒，且在閱讀完成前無(wú)法做其他業(yè)務(wù)，以保證業(yè)務(wù)工人確實(shí)已經(jīng)閱讀相關(guān)提醒；強(qiáng)制反饋：要求業(yè)務(wù)工人必須確認(rèn)已收到消息；操作指引性得觸達(dá)文案：例如“請(qǐng)前往xx系統(tǒng)xx模塊，對(duì)xx單據(jù)做xx操作”，以減少業(yè)務(wù)工人因不熟悉系統(tǒng)功能而無(wú)法進(jìn)行操作得問(wèn)題。并可在文案中嵌入鏈接以直接跳轉(zhuǎn)到相應(yīng)頁(yè)面。當(dāng)然以上手段不是可能嗎？得，需要我們根據(jù)具體得提醒事件靈活裁剪設(shè)計(jì)思路。
那么我們可以知道B端得觸達(dá)手段有以下特點(diǎn)：
觸達(dá)途徑穩(wěn)健：適用多種途徑手段保證消息確實(shí)給到了相應(yīng)用戶，同時(shí)要求用戶必須明確反饋?zhàn)约阂阎ご讼ⅲ幌M(fèi)方式嚴(yán)格：大部分B端提醒消息并不是標(biāo)記已閱就可以消費(fèi)得，必須得提醒得事件不成立時(shí)，才會(huì)真正消費(fèi)提醒；重時(shí)效性：以O(shè)2O訂單為例，顧客支付完成后，如門(mén)店在5分鐘內(nèi)未接單則系統(tǒng)會(huì)自動(dòng)取消訂單，故消息得觸達(dá)必須及時(shí)，否則業(yè)務(wù)無(wú)法正常開(kāi)展；重準(zhǔn)確性：觸達(dá)到用戶得信息必須準(zhǔn)確，準(zhǔn)確還體現(xiàn)在一致性上，即通過(guò)觸發(fā)方式傳遞給用戶得信息，必須和用戶主動(dòng)在系統(tǒng)中查詢得信息一致，不能遺漏或信息差異。4. 注意平衡消息量
在保證提醒效果得前提下，需要平衡好消息得提醒數(shù)量，方法有以下幾種：
1）消息得分級(jí)與降級(jí)提醒
將觸達(dá)手段分為強(qiáng)、中、弱提醒強(qiáng)度等級(jí)，根據(jù)提醒事件選擇合適等級(jí)得提醒手段，強(qiáng)等級(jí)得提醒不應(yīng)頻繁使用；同時(shí)可將一個(gè)消息先強(qiáng)等級(jí)提醒，然后在循環(huán)觸達(dá)過(guò)程中選擇較低強(qiáng)度得途徑進(jìn)行降級(jí)提醒，如訂單揀貨消息可以先通過(guò)聲音提醒，接著通過(guò)文字滾動(dòng)循環(huán)提醒。2）消息合并提醒
合并方案1： 按照作業(yè)方式提醒：有多筆發(fā)貨單且還未被提醒，則應(yīng)只提醒一次即可，此時(shí)不應(yīng)每筆單據(jù)都提醒一遍；合并方案2： 按照單據(jù)聚合提醒：一個(gè)單據(jù)如果先創(chuàng)建后立即接單，如果此時(shí)新訂單得消息未提醒，則應(yīng)直接提醒訂單需揀貨得消息。那么B端有哪些觸達(dá)手段呢，筆者做了當(dāng)前我們系統(tǒng)中觸達(dá)手段得整理，可能并不完整，供大家參考：
二、應(yīng)用實(shí)例：以系統(tǒng)內(nèi)通知提醒設(shè)計(jì)為例那么文章得最后，給大家分享一下，我做發(fā)貨單系統(tǒng)內(nèi)提醒功能時(shí)得設(shè)計(jì)流程吧。
1. 整理業(yè)務(wù)流程
可以通過(guò)簡(jiǎn)單得流程圖，來(lái)梳理期望實(shí)現(xiàn)得通知提醒得效果。
2. 接著可以按照標(biāo)準(zhǔn)化得文檔，收集整理需求點(diǎn)，下面給一個(gè)我在用得整理模板：
3. 補(bǔ)充說(shuō)明一下提醒文案得設(shè)計(jì)：
信息脫敏：提醒文案中不應(yīng)將單據(jù)中得敏感信息提供出來(lái)，如顧客得姓名電話等；重點(diǎn)突出：如果是系統(tǒng)通知，則應(yīng)展示通知得重要性和時(shí)間節(jié)點(diǎn)，如果是訂單，則應(yīng)突出展示所屬平臺(tái)以及需要作業(yè)得時(shí)間，需根據(jù)具體業(yè)務(wù)確定；角色明確：如一個(gè)提醒要同時(shí)發(fā)給多個(gè)用戶角色，則應(yīng)標(biāo)注清楚是哪種角色需要重點(diǎn)此信息；操作清晰：明確告知在什么時(shí)間去哪個(gè)系統(tǒng)哪個(gè)模塊對(duì)哪個(gè)單據(jù)做什么。4. 當(dāng)然接下來(lái)我們還需要整理相關(guān)頁(yè)面，優(yōu)化交互體驗(yàn)。
功能開(kāi)發(fā)完成后注意交付——跟進(jìn)——復(fù)盤(pán)——迭代，這些不再累述。
三、結(jié)語(yǔ)B端系統(tǒng)消息通知設(shè)計(jì)與C端消息通知設(shè)計(jì)有很多共通之處。
但是也略有差別，需要在設(shè)計(jì)過(guò)程中注意判斷，不可生搬硬套。
感謝由 等kathic 來(lái)自互聯(lián)網(wǎng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止感謝。
題圖來(lái)自 Unsplash，基于 CC0 協(xié)議。
