以電商/社交為例,解析不同業務消息功能的關鍵點

0 評論 1.7萬 瀏覽 41 收藏 10 分鐘

消息模塊是輔助業務實現與用戶互動最直接的產品模塊。由于消息本身的意義很寬泛,所以業務的不同,也會產生不同的消息產品形態,消息產品的設計也是仁者見仁,智者見智。業務千變萬化,掌握消息設計的關鍵點,才能以不變應萬變。

一、消息的分類:案例分析

1. 電商產品的消息分類設計:以:“某淘”為例

以某淘為例,在電商場景中,基于核心業務需求,會有不同業務的消息需要觸達用戶,有些信息優先級較高,有些需要跟用戶實時溝通,比如私聊,IM通訊等。

因此,在做消息系統設計之前,一定要清楚消息涉及的業務形態。這決定在具體設計時,如何設計消息形態與交互。就電商而言。消息形態分類:

消息頁面會根據業務消息量,在頁面信息路徑上有不同的展示方案。

一般,消息頁面共有二級:消息列表頁——消息主頁。

消息主頁可以是以服務號的消息卡片流為主,也可以是一行文案或者鏈接,或H5互動頁,或卡片流;如下圖:

電商產品消息設計,重點集中在售后的環節。
因此,在消息創建主體來源于商品/門店/訂單/物流/品牌/優惠券/促銷活動等這一類業務資源的變動。通常這一類消息會由相應的管理系統發送,但產品經理也需要依據相應的業務動態定義消息的形態。

2. 社交產品的消息分類設計:以“某博”為例

對照電商產品,社交產品的消息設計則又明顯的側重。如下圖:

以“微博”產品為例,相關的消息類型總結如下:

社交類產品中,消息的產生可以來自于:關注與未關注用戶、粉絲、群、社區、訂閱號等主體對象。而這些角色則也是構建社交產品的基本框架。

二、“消息”基本產品流程

從以上案例來看,在實際消息設計中,我們需要分清自己負責的平臺的屬性是電商/社交/金融等。根據具體業務,定義消息產品流程、消息類型、消息優先級、消息發送方式、消息展示方式。

消息發送的產品流程見下圖:

?三、“消息”產品分步驟設計

第一步:「定義消息」

從消息的本質來思考如果為系統編輯消息誕生的規則,我們可以從語義以及系統的原理中找到答案:

第一點: 從場景角度解構,消息作為一個包含動作的詞語,從語義上來分析,存在一個普遍結構:模型1 :“對象+動作” 或者 “ 對象A+動作+對象B”

其中,對象A就是動作的施加者,對象B則是動作的承受者(非常簡單的語法解構)。

第二點,從開發的角度來說:資源在不斷更新中觸發消息產生的規則,并最終并推送給訂閱接收的用戶;

這里包含4個對象:

  1. someone = 提醒的觸發者,或者發送者,標記為sender
  2. do something = 提醒的動作,評論、喜歡、關注都屬于一個動作,標記為action
  3. something = 提醒的動作作用對象,這就具體到是哪一篇文章,標記為target
  4. someone’s = 提醒的動作作用對象的所有者,標記為targetOwner

比如對于電商產品來說,提醒觸發的者可以分為促銷系統/管理員/門店/訂單系統/物流系統/;社交類,則是用戶、KOL等自媒體帳號。

輸出需求關鍵點1:定義:資源/動作+消息模版;即:誰+在什么情況下+對什么,作出什么事情,且在用戶端的消息文案模版如何展示;

第二步「用戶訂閱」

每一個用戶都有一張屬于自己的訂閱管理表。subscribeconfig,來記錄用戶的提醒設置。當用戶沒有提醒設置是,可以使用系統默認的一套設置。一則用戶訂閱管理記錄大致包括:

  1. 訂閱的目標(資源是什么)
  2. 訂閱的目標類型
  3. 訂閱的動作(action)
  4. 訂閱的觸發條件 (subscribereason =發布,則對應的action=贊/評論,比如我發表了一篇文章,如果有人針對這篇文章進行點贊和評論,就可以通知我)

輸出需求關鍵點2:定義用戶訂閱管理對象名稱有哪些,如上圖。

第三步 消息分發與獲取

1 消息分發方式的確定:

  • 第一種:拉??;客戶端在用戶登錄時請求服務拉取相關消息數據,定時向服務器獲取新的消息,并進行更新,或者在用戶進行手動下拉加載消息頁面時進行更新。
  • 第二種:push;push在針對消息的時效性方面作用很大。

2 分發頻率的確定:

依照消息的優先級制定消息發送的高低策略。比如高優先級消息,頻率可以是:實時更新;這類信息需要用戶即使知曉并處理。中級消息,不需要即使知道,頻率可以是:時/天/周;低優先級消息,頻率可以是:固定周期;

3 消息分發的優化:聚合

消息的聚合,就是可以定義什么情況下,可以把類似的行為劃分為同一類信息,進行推送。

輸出需求關鍵點3:消息分發的方式(可以跟技術溝通),消息分發的優先級更新策略。

第四步: 消息的閱讀、標記

輸出需求關鍵點4:

定義消息數量展示規則:

1. 消息在TAB或在列表中的展示規則,如展示方式,最多展示幾條,超過限制如何展示等;

2. 定義消息處理的交互以及處理狀態:定義消息的有效操作,即用戶如何操作才標記為已讀/以處理等狀態。

從交互的弱——強來分,處理交互可分為:

  • 忽略:忽略此條信息
  • 查看:點擊詳情或主動標記為已讀
  • 刪除:刪除本消息
  • 確認:需要對本消息進行確認
  • 回復:需要進行數據交互
  • 處理:適合更為復雜的業務通知。

第五步:消息的回收

消息回收:產品依據開發實際開發需求,設置相應用戶設計,向用戶確認是否在一定周期內刪除指定的消息內容。

四、總結

消息產品設計前提:明確消息產生的主體(非常重要);

  • 第一步:定義:資源/動作+消息模版;
  • 第二步:定義用戶訂閱管理具體對象;
  • 第三步:消息分發的方式(可以跟技術溝通)、對象、時間、更新時間、加載規則;消息分發的優先級更新策略;
  • 第四步:定義消息在產品端的展示規則(數量/文案/圖文結構等);消息標記規則;
  • 第五步:消息的回收規則。

消息設計的本質是在考量產品經理是否具備抽象業務的思維,這也是搭建產品基礎框架的基本素質,同時也涉及到對于信息的設計以及交互等知識,值得好好研究。

 

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

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!