產(chǎn)品策劃:消息系統(tǒng)設(shè)計(jì)詳解與案例分析

8 評(píng)論 44801 瀏覽 307 收藏 16 分鐘

看過(guò)很多產(chǎn)品設(shè)計(jì)的文章,很少有對(duì)消息系統(tǒng)這個(gè)模塊的設(shè)計(jì)講得比較清晰的,最近搜集了一些資料,結(jié)合實(shí)際例子梳理了消息系統(tǒng)的設(shè)計(jì)原則,供參考。

一、消息系統(tǒng)定義

消息系統(tǒng),顧名思義即信息的傳達(dá)處理系統(tǒng)。目的是為了讓用戶獲得需要得到的消息及提醒并進(jìn)行處理。

這里的“需要得到”有兩層意思:

  • 用戶彼此互動(dòng)觸發(fā)的信息流(留言、評(píng)論或者回復(fù)、私信等)
  • 應(yīng)用希望用戶了解關(guān)注的信息(系統(tǒng)公告等)

消息系統(tǒng)設(shè)計(jì)的原則可簡(jiǎn)單的歸納為:

  • 消息傳播效率最高(獲取、處理、信息傳達(dá)、用戶反饋等效率)
  • 避免產(chǎn)生騷擾(噪音、頻繁提示)

二、消息分類

不用的平臺(tái)和產(chǎn)品本身由于對(duì)業(yè)務(wù)的需求不一樣,種類也是有區(qū)別的。大致可分為以下幾種:

圖片1

三、消息系統(tǒng)邏輯實(shí)現(xiàn)機(jī)制

消息系統(tǒng)的邏輯精簡(jiǎn)后如下:

圖片2

現(xiàn)對(duì)這幾個(gè)環(huán)節(jié)分開(kāi)說(shuō)明:

1.消息合并

消息在推送之前需要進(jìn)行匯總合并,目的在于提高消息傳播處理效率;減少騷擾,降低噪音;平衡服務(wù)器壓力。

合并周期

固定時(shí)間內(nèi)的消息全部匯總(24小時(shí)內(nèi)/30天等);

無(wú)固定時(shí)間(只要未處理/未讀即匯總)

當(dāng)然一般都組合著用:合并24小時(shí)內(nèi)未處理消息

分類合并

  • 同種類進(jìn)行合并(如n條留言合并為1條)
  • 同一發(fā)起人合并(如張三給你發(fā)來(lái)的n條私信)
  • 同一時(shí)間周期合并(如24小時(shí)共收到n條評(píng)論)

下面我們來(lái)看一下簡(jiǎn)書(shū)關(guān)于消息的實(shí)現(xiàn)是怎么樣的。

簡(jiǎn)書(shū)的消息系統(tǒng)分得比較細(xì),包括評(píng)論、簡(jiǎn)信、投稿請(qǐng)求、喜歡和贊、關(guān)注、打賞、其它提醒等。

圖片3圖片4

提醒的語(yǔ)言分析(摘自簡(jiǎn)書(shū)作者jc-huang)

我們從簡(jiǎn)書(shū)取一組提醒樣本:

  • 3dbe1bd90774 關(guān)注了你
  • magicdawn 喜歡了你的文章 《單點(diǎn)登錄的三種實(shí)現(xiàn)方式》
  • 無(wú)良程序 喜歡了你的文章 《基于RESTful API 怎么設(shè)計(jì)用戶權(quán)限控制?》
  • alexcc4 喜歡了你的文章 《在Nodejs中貫徹單元測(cè)試》
  • 你在《基于RESTful API 怎么設(shè)計(jì)用戶權(quán)限控制?》中收到一條 cnlinjie 的評(píng)論
  • 你的文章《Session原理》已被加入專題 《ios開(kāi)發(fā)》

分析句子結(jié)構(gòu),提醒的內(nèi)容無(wú)非就是

「誰(shuí)對(duì)一樣屬于誰(shuí)的事物做了什么操作」

「someone do something in someone’s something」

  • someone = 提醒的觸發(fā)者,或者發(fā)送者,標(biāo)記為senderdo
  • something = 提醒的動(dòng)作,評(píng)論、喜歡、關(guān)注都屬于一個(gè)動(dòng)作,標(biāo)記為action
  • something = 提醒的動(dòng)作作用對(duì)象,這就具體到是哪一篇文章,標(biāo)記為target
  • someone’s = 提醒的動(dòng)作作用對(duì)象的所有者,標(biāo)記為targetOwner

這就清楚了,sender和targetOwner就是應(yīng)用的用戶,而target是具體到哪一篇文章,如果提醒的對(duì)象不僅僅局限于文章,還有其他的話,就需要增加一項(xiàng)targetType,來(lái)標(biāo)記目標(biāo)是文章還是其他的什么。而action,則是固定的,整個(gè)應(yīng)用會(huì)觸發(fā)提醒的動(dòng)作可能就只有那幾樣:評(píng)論、喜歡、關(guān)注…..(或者其他業(yè)務(wù)需要提醒的動(dòng)作)

2.消息分發(fā)

消息按照規(guī)則匯總完成后,系統(tǒng)將其通過(guò)消息管道推送到用戶,以便用戶處理。

分發(fā)方式

主要是Push和Pull。

第一種是客戶端使用Pull(拉)的方式,隔一段時(shí)間就去服務(wù)器上獲取信息,看是否有更新的信息出現(xiàn)。

第二種就是服務(wù)器使用Push(推送)的方式,當(dāng)服務(wù)器端有新信息了,則把最新的信息Push到客戶端上。

Pull方式更費(fèi)客戶端的網(wǎng)絡(luò)流量,更主要的是費(fèi)電量,還需要我們的程序不停地去監(jiān)測(cè)服務(wù)端的變化。

Push可以針對(duì)消息的時(shí)效性做出及時(shí)的通知。

以知乎為例

推的比較常見(jiàn),需要針對(duì)某一個(gè)問(wèn)題維護(hù)著一張關(guān)注者的列表,每當(dāng)觸發(fā)這個(gè)問(wèn)題推送的條件時(shí)(例如有人回答問(wèn)題),就把這個(gè)通知發(fā)送給每個(gè)關(guān)注者。

拉的相對(duì)麻煩一點(diǎn),就是推的反向,例如每個(gè)用戶都有一張關(guān)注問(wèn)題的列表,每當(dāng)用戶上線的時(shí)候,對(duì)每個(gè)問(wèn)題進(jìn)行輪詢,當(dāng)問(wèn)題的事件列表出現(xiàn)了比我原本時(shí)間戳大的信息就進(jìn)行拉取。

而我們則根據(jù)消息的不同分類采用不同的獲取方式:

通告和提醒,適合使用拉取的方式,消息產(chǎn)生之后,會(huì)存在消息表中,用戶在某一特定的時(shí)間根據(jù)自己關(guān)注問(wèn)題的表進(jìn)行消息的拉取,然后添加到自己的消息隊(duì)列中,

私信,適合使用推的方式,在發(fā)送者建立一條信息之后,同時(shí)指定接收者,把消息添加到接收者的消息隊(duì)列中。

目前大部分消息優(yōu)先推送未處理消息合并后的總數(shù),已提醒用戶已有新消息需要處理。用戶點(diǎn)擊數(shù)字后再去服務(wù)端請(qǐng)求具體的消息內(nèi)容。此種方式綜合考慮了成本、壓力和體驗(yàn)。當(dāng)然,某些極端情況下需要進(jìn)行優(yōu)化處理:如未讀消息超過(guò)1000,用戶請(qǐng)求時(shí)先推送前50條或者放入cache中等。技術(shù)童鞋會(huì)有各種手段,這里不做詳述。

分發(fā)頻率(時(shí)間)

分發(fā)時(shí)間主要根據(jù)消息的優(yōu)先級(jí)來(lái)做區(qū)隔:

圖片5

分發(fā)管道

分發(fā)管道即消息通知的具體推送渠道,根據(jù)業(yè)務(wù)類型可以分為:App、短信等。

3.用戶處理

根據(jù)前文提到的分發(fā)方式,對(duì)于通知的處理在邏輯上可以分為兩層:通知狀態(tài)的處理和通知內(nèi)容的處理。

狀態(tài)的處理狹義的理解即為是否已讀(已處理).

通常初始數(shù)字即為系統(tǒng)推送過(guò)來(lái)的未讀總量,用戶點(diǎn)擊數(shù)字進(jìn)入相關(guān)功能列表查閱后讀取的動(dòng)作完成,未讀數(shù)字相應(yīng)減少。

圖片6

有幾種情況需要變通處理:

若用戶未讀信息較多(m=100),但第一頁(yè)列表只能顯示(n=10)條的話,那未讀數(shù)字即為m-n=90;

某些產(chǎn)品會(huì)將點(diǎn)擊等同于已讀。即用戶只要點(diǎn)擊無(wú)論是否打開(kāi)列表查看均認(rèn)為已讀。

這樣的處理一般用于重要級(jí)別較低的消息。點(diǎn)擊即已讀可有效降低騷擾。

某些重要級(jí)別較高的消息已處理狀態(tài)可以定義為用戶進(jìn)行相關(guān)操作后才為已處理,而非查閱。

如用戶進(jìn)行評(píng)論、回復(fù)、點(diǎn)擊忽略或點(diǎn)擊刪除等動(dòng)作時(shí)才認(rèn)為已處理。

內(nèi)容的處理狹義的理解即為用戶是否操作

根據(jù)不同消息的種類和業(yè)務(wù)的需要,操作可分為:

  • 處理:用戶必須點(diǎn)擊功能鏈接進(jìn)行處理。如:你的密碼過(guò)于簡(jiǎn)單,點(diǎn)此進(jìn)行修改;
  • 回復(fù):如回復(fù)私信,對(duì)評(píng)論進(jìn)行回復(fù);
  • 確認(rèn):對(duì)消息做出確認(rèn)的反饋,如某些系統(tǒng)提示可設(shè)置”我已知道,不再提示”的選項(xiàng);
  • 忽略:用戶進(jìn)行忽略操作或不進(jìn)行任何操作;
  • 刪除:用戶刪除本消息。
  • 消息處理后的狀態(tài)需要統(tǒng)一

消息需要標(biāo)記是否已處理的狀態(tài),且狀態(tài)在不同的終端是打通的。

如:用戶在客戶端對(duì)消息進(jìn)行了查看,在web站點(diǎn)本消息應(yīng)自動(dòng)標(biāo)記為已讀狀態(tài)。

4.消息回收

回收主要針對(duì)用戶已處理消息的操作,用戶之間觸發(fā)的消息一般需要留檔保存。如評(píng)論/回復(fù)/留言/私信等。產(chǎn)品可提供選項(xiàng)詢問(wèn)用戶是否超過(guò)一定周期自動(dòng)清理。

  • 在部分產(chǎn)品中,還需要考慮功能的優(yōu)先級(jí)。如解除好友關(guān)系或加入黑名單后自動(dòng)將刪除雙方的私信記錄。
  • 系統(tǒng)觸發(fā)的消息一般設(shè)置一定的回收刪除時(shí)間。如系統(tǒng)提醒、通知、公告等。過(guò)期后自動(dòng)在產(chǎn)品里刪除。物理上可以設(shè)置是否備份。
  • 過(guò)期但用戶未處理消息(用戶長(zhǎng)時(shí)間未登錄但收到他人的回復(fù))可以根據(jù)業(yè)務(wù)需求來(lái)處理。如未讀的私信/評(píng)論/回復(fù)永久保留等。重要未讀消息可嘗試二次推送或使用其他途徑(郵箱、APP、短信等)通知。

    四、iOS和安卓的消息提醒設(shè)計(jì)

    1.IOS版本的APP消息提醒設(shè)計(jì)

iOS對(duì)于消息通知的提示也有自己的一套設(shè)計(jì)規(guī)范,而且分為本地通知和推送通知。 推送通知或推送消息是服務(wù)器執(zhí)行。

iOS的消息通知有兩種形式,Badge Notification和Alert Notification。

Badge Notification

指出現(xiàn)在應(yīng)用程序圖標(biāo)右上角的紅色圓形數(shù)字提醒,用于提醒一些無(wú)需即時(shí)處理的消息,比如程序更新數(shù)、未讀郵件數(shù)等。Badge Notification只有在Home Screen的對(duì)應(yīng)屏上才能看到,因此不適合用于提醒一些重要性高或需要及時(shí)處理的通知。而且Badge Notification的形狀顏色大小等都是默認(rèn)且無(wú)法改變的。

Alert Notification

非常直接地以對(duì)話窗口的形式出現(xiàn)在屏幕上,用于重要或需要及時(shí)處理的通知。不過(guò)Alert Notification常常粗暴地打斷正在進(jìn)行中的任務(wù),強(qiáng)迫用戶馬上做出選擇,且無(wú)法匯總查看所有通知,當(dāng)有多條通知時(shí),無(wú)法選擇性處理,只能按提供提供的順序一個(gè)個(gè)處理。

圖片7

下面是介紹ios的四種消息通知類型

橫幅(Banner)

橫幅通知會(huì)顯示程序的小圖標(biāo)(低分屏下顯示29×29的圖標(biāo),高分屏顯示58×58的圖標(biāo)),程序的名字和通知的內(nèi)容。(只要不是鎖屏狀態(tài),都可以從屏幕頂部向下滑打開(kāi)通知中心。 )

圖片8

提醒(Alert)

提醒通知不會(huì)自動(dòng)消失,需要用戶與之交互才能關(guān)閉。設(shè)計(jì)師需要設(shè)計(jì)通知的具體內(nèi)容,有時(shí)還要為action button(后面會(huì)談到)設(shè)計(jì)title。

APP設(shè)計(jì)師值得注意的是:一條提醒可能會(huì)包含一到兩個(gè)按鈕。對(duì)于有兩個(gè)按鈕的提醒,需要把關(guān)閉提醒的按鈕放在左邊,把a(bǔ)ction button放在右邊。 如果只有一個(gè)按鈕,這個(gè)按鈕應(yīng)該是一個(gè)確定按鈕。

標(biāo)記(Badge)

標(biāo)記通知是顯示在程序圖標(biāo)的右上角的紅色橢圓形標(biāo)記,里面顯示的數(shù)字表示需要用戶處理的通知的數(shù)量。

這種方式都是很常見(jiàn)的。而且也很醒目。切記,標(biāo)記圖標(biāo)的設(shè)計(jì)尺寸。

聲音(Sound)

聲音提示也是iOS的一種通知方式,支持自定義,可以與前面三種通知類型搭配使用。

這樣的方式是非常人性化的提醒用戶不要遺忘重要的信息。比如會(huì)議時(shí)間等等。

2.Android 版本的APP消息提醒設(shè)計(jì)

最新的Android的通知欄的設(shè)計(jì)和功能與前幾代Android系統(tǒng)基本一樣,也是從屏幕頂部向下拉出,唯一不同的地方就是用戶可以將某條通知按住向左拖動(dòng)移除該通知。

圖片9

更加人性化,android也有一樣的消息提醒設(shè)計(jì):

  • Alert:強(qiáng)打斷型提醒,提醒內(nèi)容與當(dāng)前應(yīng)用有聯(lián)系時(shí)可以接受;
  • 標(biāo)記:一種不緊急的提醒方式,增量很難記住,部分用戶有強(qiáng)迫清零的習(xí)慣;
  • Toast:純告知,不需要處理;針對(duì)正在操作的反饋;
  • 預(yù)覽:可輔助用戶判斷是否需要查看該信息詳情,但要注意結(jié)合“標(biāo)記為已讀”機(jī)制;
  • 通知欄:是一種被普遍接受的通知方式,優(yōu)點(diǎn)是“集中處理”;

圖片10

我們?cè)谠O(shè)計(jì)APP消息提醒或通知的時(shí)候,還應(yīng)該考慮我們所設(shè)計(jì)的APP針對(duì)的人群,從而選擇合適的消息推送方式或是消息提醒方案。

 

作者:Jason ? ?個(gè)人微信號(hào):jason-pong

本文由 @Jason 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 感謝哦,對(duì)消息成型的理解了

    來(lái)自北京 回復(fù)
  2. 以前沒(méi)做消息推送,一籌莫展的時(shí)候,看到了你的文章,一邊看你的文章,一邊把消息推送的需求寫(xiě)了個(gè)大概。非常感謝!

    來(lái)自江蘇 回復(fù)
  3. 與13年老曹的這篇還挺像的http://m.codemsi.com/pd/32652.html

    來(lái)自江蘇 回復(fù)
    1. 哈哈哈,很像啊,我也看過(guò),現(xiàn)在好多人寫(xiě)的文章都這樣,換換用例圖片

      來(lái)自浙江 回復(fù)
  4. 請(qǐng)教一下:例如點(diǎn)贊,推送的內(nèi)容為:您24小時(shí)內(nèi)共收到98個(gè)贊。且在用戶的消息中對(duì)每個(gè)贊都有留檔。像我這種情況,究竟有沒(méi)有進(jìn)行消息合并?(從推送內(nèi)容看有進(jìn)行合并。從留檔看是不合并的,每個(gè)贊都會(huì)當(dāng)成一條消息通知)

    來(lái)自廣東 回復(fù)
  5. 很詳細(xì)很實(shí)用,還沒(méi)做過(guò)消息通知推送的產(chǎn)品策劃,是很好的知識(shí)補(bǔ)充

    回復(fù)
  6. 實(shí)用

    回復(fù)
  7. 非常感謝

    來(lái)自湖北 回復(fù)