消息模塊是輔助業務實現與用戶互動最直接的產品模塊。由於消息本身的意義很寬泛，所以業務的不同，也會產生不同的消息產品形態，消息產品的設計也是仁者見仁，智者見智。業務千變萬化，掌握消息設計的關鍵點，才能以不變應萬變。
以某淘為例，在電商場景中，基於核心業務需求，會有不同業務的消息需要觸達用戶，有些信息優先級較高，有些需要跟用戶實時溝通，比如私聊，IM通訊等。
因此，在做消息系統設計之前，一定要清楚消息涉及的業務形態。這決定在具體設計時，如何設計消息形態與交互。就電商而言。消息形態分類：
消息頁面會根據業務消息量，在頁面信息路徑上有不同的展示方案。
一般，消息頁面共有二級：消息列表頁——消息主頁。
消息主頁可以是以服務號的消息卡片流為主，也可以是一行文案或者連結，或H5互動頁，或卡片流；如下圖：
電商產品消息設計，重點集中在售後的環節。
因此，在消息創建主體來源於商品/門店/訂單/物流/品牌/優惠券/促銷活動等這一類業務資源的變動。通常這一類消息會由相應的管理系統發送，但產品經理也需要依據相應的業務動態定義消息的形態。
對照電商產品，社交產品的消息設計則又明顯的側重。如下圖：
以「微博」產品為例，相關的消息類型總結如下：
社交類產品中，消息的產生可以來自於：關注與未關注用戶、粉絲、群、社區、訂閱號等主體對象。而這些角色則也是構建社交產品的基本框架。
從以上案例來看，在實際消息設計中，我們需要分清自己負責的平臺的屬性是電商/社交/金融等。根據具體業務，定義消息產品流程、消息類型、消息優先級、消息發送方式、消息展示方式。
消息發送的產品流程見下圖：
從消息的本質來思考如果為系統編輯消息誕生的規則，我們可以從語義以及系統的原理中找到答案：
第一點： 從場景角度解構，消息作為一個包含動作的詞語，從語義上來分析，存在一個普遍結構：模型1 ：「對象+動作」 或者 「 對象A+動作+對象B」
其中，對象A就是動作的施加者，對象B則是動作的承受者（非常簡單的語法解構）。
第二點，從開發的角度來說：資源在不斷更新中觸發消息產生的規則，並最終並推送給訂閱接收的用戶；
這裡包含4個對象：
比如對於電商產品來說，提醒觸發的者可以分為促銷系統/管理員/門店/訂單系統/物流系統/；社交類，則是用戶、KOL等自媒體帳號。
輸出需求關鍵點1：定義：資源/動作+消息模版；即：誰+在什麼情況下+對什麼，作出什麼事情，且在用戶端的消息文案模版如何展示；
每一個用戶都有一張屬於自己的訂閱管理表。subscribeconfig，來記錄用戶的提醒設置。當用戶沒有提醒設置是，可以使用系統默認的一套設置。一則用戶訂閱管理記錄大致包括：
輸出需求關鍵點2：定義用戶訂閱管理對象名稱有哪些，如上圖。
1 消息分發方式的確定：
2 分發頻率的確定：
依照消息的優先級制定消息發送的高低策略。比如高優先級消息，頻率可以是：實時更新；這類信息需要用戶即使知曉並處理。中級消息，不需要即使知道，頻率可以是：時/天/周；低優先級消息，頻率可以是：固定周期；
3 消息分發的優化：聚合
消息的聚合，就是可以定義什麼情況下，可以把類似的行為劃分為同一類信息，進行推送。
輸出需求關鍵點3：消息分發的方式（可以跟技術溝通），消息分發的優先級更新策略。
輸出需求關鍵點4：
定義消息數量展示規則：
1. 消息在TAB或在列表中的展示規則，如展示方式，最多展示幾條，超過限制如何展示等；
2. 定義消息處理的交互以及處理狀態：定義消息的有效操作，即用戶如何操作才標記為已讀/以處理等狀態。
從交互的弱——強來分，處理交互可分為：
消息回收：產品依據開發實際開發需求，設置相應用戶設計，向用戶確認是否在一定周期內刪除指定的消息內容。
消息產品設計前提：明確消息產生的主體（非常重要）；
消息設計的本質是在考量產品經理是否具備抽象業務的思維，這也是搭建產品基礎框架的基本素質，同時也涉及到對於信息的設計以及交互等知識，值得好好研究。
本文由 @Sherry 楊 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議