消息通知系統設計

33 評論 76927 瀏覽 1104 收藏 22 分鐘

編輯導語:消息通知可以將內容實時送達用戶手機頁面,但是泛濫的消息通知會引起用戶的反感,也違背了這個設計的初衷。如何理解以及設計消息通知,作者作了簡單的分享,我們一起來看看吧。

消息通知可以及時地將狀態、內容的更新觸達到用戶,用戶則可以根據收到的消息做后續判斷。但是如果沒有及時將重要消息觸達到用戶或者濫用消息,則失去了消息通知的初衷。

特別是針對涉及復雜任務流程的產品,消息類型繁雜,難以全面盤點消息類型,消息系統的設計就顯得尤為重要。

希望通過這篇文章讓各位在設計消息通知系統的時候能夠更加全面高效。

一、如何理解消息通知

消息通知需要為產品服務,幫助用戶快速獲取對應的通知信息。收到一條新回復的提示、工作臺展示工作進度、朋友的來電,生活中處處是信息的交換。在 App 和網頁應用中最常見的信息交換方式則是消息通知。

消息作為一種信息交換方式,抽象其過程,即為“在達到某一觸發條件下,由發送方發送消息給到接收方,接收方可針對此條消息提供反饋”。需要包含以下關鍵因素:

  1. 消息觸發時間與條件(何時什么事):如按周期重復的時間點,或系統狀態變更、用戶操作結果等;
  2. 消息發送方(誰發現的事):可能是系統、第三方服務商,或者某個用戶;
  3. 消息接收方(誰需要知道):即接收方,可能是系統中的全部用戶,也可能會根據權限劃分推送到某個用戶群組,或者是某個特定用戶;
  4. 消息觸達渠道(怎么找到他):短信、電話、App 內通知等;
  5. 消息通知內容(告訴他什么):短信的文本、電話對話內容、通知消息的文案等消息通知;
  6. 消息操作反饋(他可以干嘛):主要分為只讀與操作反饋。只讀,即當前消息用戶在瀏覽后不需要做更多的操作,主要以了解為主;操作反饋,即當前消息需要用戶瀏覽,且在瀏覽后做相應的后續操作。

好的消息系統要滿足什么條件:

  1. 全面:通知的消息項要完整全面,用戶才能放心地通過消息通知系統了解消息更新內容;
  2. 及時:消息的觸達方式要及時有效,在消息相關事件發生后,用戶能在第一時間獲取到信息并提供操作反饋給到消息發送方;
  3. 高效:能通過合理的消息發送途徑、允許用戶設置及合并相似信息等方式避免過多消息侵擾用戶,讓用戶能夠高效處理消息通知。

二、如何盤點消息通知

設計全面、及時、有效的消息通知系統需要對消息的六個關鍵因素進行全面盤點,通過分步的方式逐步完成消息通知系統的設計。主要分為以下三步:

  1. 盤點系統中包含的消息項:包含其觸發條件、通知來源及通知對象。需要盤點完整消息項從而保證消息系統的完整性;
  2. 確定消息觸達渠道:包含各消息項的觸達渠道。讓所有消息都能觸達到用戶的同時,能夠讓重要信息更易觸達,保證消息通知的及時性;
  3. 撰寫通知內容與操作反饋:包含各消息項的通知內容與操作反饋。讓消息內容能夠有效地傳達給用戶,讓用戶能快速反饋、操作。

盤點的過程,即對消息通知清單的梳理。與產品、研發等團隊成員的溝通也將使用該清單。最終目標即完成下方表格的填寫:

1. 盤點系統中包含的消息項

當前步驟需要對系統中可能會有的消息項進行完整的盤點。盤點消息項可以通過按消息類型走查方式完成。市場上比較有共識的消息的分類方式主要分為禁止、警告、成功三類。但是在實際設計工作中還需要配合以下的消息分類方式去更完整地盤點消息項:

(1)盤點出的每個消息項都需要補充以下四個關鍵因素

  1. 觸發條件:結合產品核心場景梳理完整??赏ㄟ^狀態圖或泳道圖查缺補漏(詳見下段內容);
  2. 通知來源:可能是某個內部系統,可能是某個用戶組,也可能是某個具體用戶。用戶組的劃分需要提前與產品、研發同事溝通完成;
  3. 通知對象:可能是全部用戶,也可能是某個用戶組或具體用戶。由觸發條件中的場景決定;
  4. 重要性:需要與團隊溝通得出,可使用“高”、“中”、“低”的分類方式。

盤點完成的消息項使用下表進行整理,方便產品、設計、研發之間的溝通。

(2)用流程圖或泳道圖查缺補漏

對于 ToB 或 ToG 類含有復雜狀態轉換以及任務流的產品,除了使用分類的方式盤點消息項,還需要對照流程圖或泳道圖查缺補漏,避免消息類型的遺漏。

如,顧客線上購買商品并收取商品的商品相關狀態變化如下圖所示,每個狀態都可對應著一條消息項:

△線上購物過程中的消息流程圖示意

當系統內包含多角色,且角色間流程有交互時,則可以使用泳道圖的方式進行梳理。在泳道圖中的每一條狀態變更線,都對應著一個狀態變更提醒。其中角色間交互的線,由于需要角色主動處理方可進入下一流程狀態,這條消息一般會成為一條待辦消息。

(3)什么類型的消息不要納入消息通知系統

需要注意的是,雖然通知的完備性很重要,但某些消息在前期梳理時就需要從清單中剔除,包括:

  1. 單純問候類消息,如“好久不見”等
  2. 不需要用戶知道的消息,如系統后臺數據更新等

2. 確定消息觸達渠道

確定要推送給用戶的消息類型后,需要給各消息匹配適合的通知方式。不同的通知方式會有不同的適用場景,可對照下表結合第一步整理的重要性配置消息的觸達渠道:

消息觸達渠道的配置結果到第一步的表格中:

平衡通知量:

一個好的消息系統需要能有效觸達的同時不過分侵擾用戶。這就要求我們對系統實際運行中可能會出現的通知量進行預估,并適量調整通知方式,讓重要的消息能夠更有效及時地觸達到用戶。

最終調整后的消息數量與提醒強度的關系最好能形成如下圖所示金字塔的模式。

△ 提醒強度與消息數量的金字塔關系

(1)合并重復消息

對于出現頻率較高,且用戶不需及時了解每條消息的消息項,可以通過合并消息的方式減少通知的數量。合并主要有兩種方式:合并流程過往節點信息和合并同類消息。

合并流程過往節點消息:對于一些流程類通知,若用戶在響應或查看前,流程已經進入到下一階段,歷史節點的信息已經無需了解時,可合并過往流程節點的消息。如淘寶在展示物流時,針對同一訂單的物流,僅保留最新的一條。

合并同類信息:對于同類型消息過多,且用戶不需要一一查看,只需在用戶有需要的時候提供入查看完整內容時,自動合并同類型的消息,減少對用戶的打擾。如 Instagram 在展示用戶動態信息時,會合并同一天同一類型的消息。

△兩種合并消息方式

智能推送:有條件的系統可根據用戶行為分析及用戶畫像,進行智能推送。如基于用戶畫像按類型推送運營類消息,基于用戶接受消息數量,判斷是否合并消息推送等。

(4)渠道間消息項的延續與統一

出于信息持續性的考慮,觸達渠道之間有部分關聯關系在制定消息觸達渠道時需要注意,如:

  1. 若系統包含App、web等不同端,相同通知類型的消息要保持統一
  2. badge提示需要在應用內消息通知模塊有對應消息提示
  3. push消息的文案需要與應用內消息中心保持一致

3. 撰寫通知內容與操作反饋

通知的內容需要滿足簡明易懂的同時,還要讓用戶能夠快速處理。根據大量經驗總結,通知內容的撰寫可使用一個通用撰寫公式:

在應用撰寫公式寫內容時,需注意以下要點:

  1. 重點前置:用戶觸達的第一場景,可能是手機的 push 消息,可能是多個消息的列表。這就要求在撰寫文案時要將重要信息前置,如驗證碼、還款金額、事件提醒名稱等。
  2. 敏感信息保護:由于無法確認用戶獲取信息的場景是否私密。對于金額、個人信息等隱私數據,建議在應用內或其他渠道提供設置項,提供用戶自主選擇是否在消息通知中包含具體數值。如果要默認顯示,需要提前告知用戶。
  3. 來源信息露出:在郵件、短信等非產品自有渠道推送消息時,用戶可能會不確定消息的來源是否官方,需要包含消息來源信息。
  4. 提供觸發時間:當消息的發生時間對用戶后續判斷、操作有影響時,需要在通知內容中包含消息發生的時間。

除了以上通用注意事項,由于渠道本身的特征差異,還需注意以下渠道相關的要點:

  1. 電話:需要設定客服話術標準,一般需要在會話開始前先告知用戶來電是誰、有什么目的。在講述完通知內容后,還應告知用戶如何處理當前信息,如果想了解詳細內容該前往哪個渠道了解。
  2. 短信-來源平臺:由于通知類短信的發送號碼可能會由于服務商設置的問題導致有多個發送號碼發送給用戶,用戶無法根據號碼判斷發件人身份。故需要在短信最開始說明平臺來源,建立品牌認知,避免用戶錯認為是垃圾短信。
  3. 短信-操作反饋:由于大部分短信為純文本短信,相關操作反饋需要通過鏈接或者路徑指引的方式提供。若短信包含詳情鏈接,鏈接最好能設置為保留根域名的短鏈,如:點擊了解詳情:cdc.qq.com/d8djei
  4. 郵件:與短信相似會有來源可信度問題,郵件內容需包含品牌元素,同時發件的郵箱地址后綴使用產品官方網站。另外需要注意,某些郵件軟件會設置不自動下載圖片,郵件重要內容不要使用圖片。
  5. push推送(移動端):是消息在移動端的特有觸達渠道,由手機系統發送。發送的信息格式會受系統要求有所限制。最新的推送要求可參考相關設計規范文檔或接口規范。應用的icon與名稱系統會自動補充,撰寫文案時不用包含。
  6. 微信公眾號(訂閱號/服務號):由于微信對訂閱號與服務號的消息推送方式會經常變化,需要確認最新的要求并撰寫文案,相關鏈接見鏈接。

在完成通知內容以及操作反饋的梳理后,對消息梳理表格進行更新,補充相關信息:

自此,消息項的盤點已經完成,后續可基于該表格與產品、研發溝通。當業務出現變更時,也需要對表格內容進行同步更新。

三、如何設計消息中心

消息通知的觸達渠道中,電話、短信、push 推送的呈現由系統決定。但是若產品有獨立 App,往往需要消息中心去承載全量的消息列表。本章會介紹如何設計消息中心。

不同應用的消息中心處理方式受產品定位、應用框架等因素影響,設計差異化較大。但是可以通過按路徑分割去簡化設計:消息中心的入口、消息列表的組織方式、消息卡片的樣式、消息的設置等幾個部分。

1. 消息中心入口

主要有底部 tab、個人中心附近的圖標入口、個人中心的菜單項等三種入口形式:

△ 消息中心的三種入口

  1. 底部tab:一般適用于產品核心功能中包含大量用戶間通訊,或者希望通過強化消息露出來促進用戶上傳更多內容。對于重要的消息類型可提供數字 badge 作為未讀消息數量的提示;
  2. 頂部圖標入口:一般適用于產品消息數量較少,或消息對產品核心場景的影響較少的情況。一般會在首頁的頂部,或個人中心頁的頂部有一圖標作為入口。圖標會包含數字 badge 作為未讀消息數量的提示;
  3. 個人中心菜單項:一般適用于當產品頂部空間作他用,沒有圖標入口的位置時使用。

2. 消息列表

從消息中心入口點擊后跳轉到消息列表。由于消息的即時性,需要按時間維度排列。但是如果產品的消息類型較多,可通過分組合并或者分 tab 的方式提升用戶觸達消息的效率。

△ 分組合并消息列表

△分 Tab 合并消息列表

對于通知類型復雜的系統,還可使用二級列表的形式對消息進一步分類展示,如微信及支付寶,由于其包含大量第三方服務,消息復雜,均設置了二級消息列表幫助用戶分類查找消息。

△ 二級消息列表

3. 消息卡片

消息列表中的卡片有兩種樣式可選,一般在一級消息列表使用小卡片樣式,讓用戶有更高的瀏覽效率。大卡片樣式則用于二級消息列表,或當前應用的消息數量較少時。

△消息卡片應用示意

4. 消息中心設置

一般位于消息中心列表頁右上角,若可設置項較多,則提供設置入口在二級頁設置。一些常用的消息設置項如下:

  1. 全部已讀:對于消息數量較多,且未讀態會影響 badge 的展示時需要提供該設置項。點擊后設置列表消息項全部已讀。
  2. 發起對話:若系統包含通訊功能,一般會在消息類表頁提供發起對話的快捷入口。點擊后跳轉到通訊錄或好友列表。
  3. 設置通知提示方式:提供按消息類型設置某些通知項的接受渠道、接收時間段、各渠道之間的已讀聯動等,如微博;或者讓用戶選擇消息通知的精確度,是否包含具體信息,如微信可接收“您收到了一條信息”的模糊消息。
  4. 打開消息推送權限:一些應用有一些狀態更新或重要的提醒需要用戶在系統設置中打開當前應用的通知權限,會包含提示用戶打開通知的功能。這些提示需要在用戶進行了如“辦理事項”、“上傳狀態”等發起流程的操作后提示。不建議在用戶啟動 App 時就彈窗提示打開通知。

四、總結

本文是對消息通知系統設計的初步介紹,希望能幫助到新手產品、交互、產品體驗設計師快速了解消息通知系統的內容盤點與消息中心的設計方法,制定及時、高效、完整的消息通知系統。

文中主要覆蓋了常見的系統與場景,若實施過程中遇到文中方法無法解決的情況歡迎留言溝通。

 

作者:Megan,來自騰訊CDC主創團隊

推薦關注公眾號 “騰訊設計”( 微信ID:TencentDesign ),第一時間獲取騰訊官方的設計方法論

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

題圖來自Unsplash,基于CC0協議

作者:卡卡西xi

來源公眾號:騰訊設計(ID:TencentDesign),設計向善

本文由人人都是產品經理合作媒體 @騰訊設計 授權發布,未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 您好,首先說明我是個小白,可能表達不那么明確,麻煩大佬們,幫忙看看,非常感謝!

    我這邊最近也是做關于評估消息通知的頁面,web端的頁面流程,主要按照:計劃到期(工作人員上一次評估時選擇下次評估時間)系統自動提醒,可以點擊去評估,進行操作。

    但是現在的問題是

    來自山東 回復
    1. 但是現在的問題是
      1.雖有固定角色,但大部分工作人員均可評估,所以只能是通知到所有人目前
      2.通知的是按照一條一條通知的,如若a員工點擊去評估了,b員工應該就沒有去評估的按鈕了吧或是顯示已經在評估中,是這樣的邏輯嗎?
      3.通知的是所有人,但是針對于一條通知,該條通知我是發給所有人(比如50人),那是不是就產生了50條數據;還是針對于一條通知,該條通知我是發給所有人(比如50人),產生一條,由50人顯示已讀哪些人呢?

      來自山東 回復
  2. 感謝科普;如果能增加后臺配置,那就更感激不盡了

    來自浙江 回復
  3. 非常好,mark

    來自北京 回復
  4. 如果只有第三方配置的模板消息,如何做消息中心,哪位大佬可以幫忙解答

    來自湖北 回復
  5. 很精彩的留言區,我是頭大來搜文章的,那個留言流程不去摻和了,我感覺作者是站在了所有的各個平臺都已經配置好了然后去拿去統計數據的來源做消息功能,而不是樓上大佬們討論的我怎么去配置某一個功能項。
    對于我來說我感覺自己都會卡在第一步:盤點系統全局消息來源,無論是系統提示,或者用戶操作反饋,或者是運營模塊、通知公告類等,因為我感覺我看不見系統內里面流程(乙方),用戶端需要賬號會很復雜,后臺鐵定肯定更看不見…??我特么心累

    來自北京 回復
  6. 感覺挺常規的

    來自江蘇 回復
  7. 表面設計是說明白的,但是具體實現并沒有寫,比如如何接入業務系統、業務系統和消息中心的職責劃分是怎么樣的?整體的系統實現流程是什么樣子的,對這些更感興趣

    來自上海 回復
    1. 后臺一般不會做分享的

      來自北京 回復
    2. 哎,還是挺難的

      來自上海 回復
    3. 我最近有在做消息中心模塊的功能,我是前臺產品,我們是分了消息中心前臺、消息中心后臺、業務中臺三塊。首先我是梳理了消息推送的主流程,包括消息觸發條件、消息推送內容、消息推送人群、消息儲存等;再是對消息的觸發條件進行了分類,哪些是需要業務系統觸發的,哪些是需要運營同學配置發送的;接著對消息的內容進行了整理,把共有的內容提了出來,然后做成模板(或者說接口樣式),然后把這個消息模板的管理放在了消息中心后臺,由運營進行配置消息模板;業務系統觸發就取對應的消息模板接口的消息內容給業務系統對應的人進行推送消息,運營配置發送的就把消息模板和人群包綁在一起,定向給某部分人發消息

      來自北京 回復
    4. 現在前臺產品都這么全能了嗎?這塊對于產品來說這么多挺全的了,但是實現起來總是會遇到數據和系統邊界問題,
      就比如運營同學想配一個模板,模板內需要應用訂單號等數據,那么問題來了,需要引用哪些數據(總不能全部數據吧),引用的數據怎么做權限,如A產品線只能用A線的數據,不能用其他線路的數據,初步的想法是將業務類型跟數據源綁定,比如負責訂單的同學可以看到abcd四個數據并用于配置到消息模板中,負責物流的同學可以看到bce并用于配置到消息模板,但是新的問題又來了,這個東西在哪里配?誰來配?數據哪里來(數據中臺?沒數據中臺怎么整?)?
      再說系統邊界問題,需求如下:給3年以上的會員發一個祝福,那么這個觸發條件“3年以上的會員”怎么做?如果業務系統來做,好了,那天天都有滿三年的,天天要調用你消息中心的接口,業務一多受得了嗎?再加上有些業務系統會將消息內容在自己系統內配置,如何說服他們在我們系統配置?在我們系統配置有什么好處(目前看來還有數據問題,的確吃力不討好);如果嗎發送條件放到消息中心來做,那么消息中心的開發將陷入無休止的業務深潭中,不僅消息中心的迭代進度受到影響,而且在中臺開發不了解業務的情況下,往往代碼質量堪憂

      綜上所述,我覺得消息中心是個對開發、架構要求高于產品的模塊,重頭戲還是背后,就是文章里沒說的部分,想想都牛逼

      來自上海 回復
    5. 我們組是做營銷工具和用戶運營的業務,這個消息中心前后臺都是我們組在負責,只是因為我是校招生,時間比較充裕,我在負責需求的梳理、業務的梳理和前臺頁面的設計以及中臺后臺需求的對接。我們目前訂單類的消息是沒有走配置頁面的,當中臺那邊訂單的狀態滿足某條件時就給我們訂單消息的接口(訂單類消息有統一的接口)灌數據,我們拿到數據后進行儲存和給前臺查詢。我們是平臺自營電商,對消息中心是否展示訂單消息的需求沒有那么強烈,又加上對消息中心的規劃是主要用于營銷消息,所以在訂單消息方面沒有做多復雜。
      關于第二條,我們目前的系統架構是:消息中心后臺創模板、用戶畫像標簽平臺圈人群、營銷渠道平臺做執行發送,你提到的“給3年以上的會員發祝?!边@個需求,目前我們業務上是沒有的,但如果有這樣的需求,我想的話讓用戶畫像標簽平臺每天凌晨刷新當天或者當月或者當年是注冊3年的會員的人群是可以實現的。

      來自北京 回復
    6. 1、給誰發消息是業務策略,應該是業務確認的
      2、怎么幫助業務確認目標“3年以上會員”是取數問題,背后涉及模塊劃分(研發分工問題),數據權限問題(BI、業務問題)
      3、怎么觸達更好,是交互方式問題,產品可以基于人性、心理學、上線后的數據表現考慮。
      作為產品,這些問題應該捋清楚,讓對應團隊回答,點到即止。
      如果團隊分工不明確,都讓你回答,這里橫跨了運營&技術,說明你的權力也不小了

      來自廣東 回復
    7. 通透啊通透,看來是苦逼產品一枚。

      來自浙江 回復
    8. 對于一般的APP來講,講到這個程度已經足夠了。
      給產品講的,當然集中在產品層面。電商APP比較復雜,當然應該另當別論。

      來自浙江 回復
    9. 你這個是啥產品的,有業務中臺的嗎?

      來自四川 回復
    10. 有中臺

      來自北京 回復
    11. 電商的

      來自北京 回復
    12. 比較常規的思路。一般消息中心前后端都是這些功能,區別在于細節,這個是需要在使用中不斷去提煉需求并合入功能中的。

      來自江蘇 回復
  8. 想咨詢一下這個消息的時間,具體是什么時間?消息接受成功的時間嗎?消息發送成功的時間嗎?還是怎樣的?

    來自廣東 回復
    1. 前臺主要是收到的時間,后臺主要是發送的時間

      來自北京 回復
  9. 消息什么來的->誰發出的->通過什么發送的->要發給誰->發的什么內容->需要怎么做

    來自北京 回復
  10. 太強了

    來自山東 回復
  11. 在二、如何盤點消息通知,3. 撰寫通知內容與操作反饋里面的第二個圖,“在完成通知內容以及操作反饋的梳理后,對消息梳理表格進行更新,補充相關信息”倒數第三列是否應該是“觸達渠道”?如果是對應上面一個流程下來的話

    來自廣東 回復
  12. 官方出品, 學習了,感謝。 那個消息中心, 跑馬燈 的分類是否應該是 “消息形式 ”而不是 [觸發條件] ?

    來自上海 回復
  13. 前段時間,正好做消息埋點,很多坑都踩過,對這個文章是深有感觸。感謝大佬

    來自江蘇 回復
  14. 這個整理真的很到位,之前我做過公司的消息系統,感覺當時要看到這篇文章應該設計的很全

    來自北京 回復
    1. 我設計還挺到位的 , 但總結沒有這篇文章那么好, 還有一些瑕疵。

      來自廣東 回復
  15. 對1年經驗的產品都要求這么高了嗎?
    汗汗汗

    來自北京 回復
  16. 官方……打擾了

    來自北京 回復
  17. 看的過程中就覺得總結得很全面,原來是官方團隊出品,??

    來自廣東 回復