web端消息中心設計分析——附原型資源分享

05-20

來自專欄 xiaopiu工坊

消息中心幾乎已經成為了每個產品的「標配」，它讓用戶能夠及時獲取到需要知道的消息和提醒並進行處理，同時也讓運營者能夠有一個渠道能向用戶發送重要通知。作為產品的設計者，我們並不能將所有消息一股腦兒地直接推送給用戶，而是需要根據產品特性和消息類型來將消息合理有效地展示給用戶，讓用戶能夠「Get」到最重要的信息。

最近我研究了很多網站的消息中心設計，本文選取了其中5個比較有代表性的網站來和大家一起探討一下。

同時，貼心如我，只分析不分享可不是我的作風，所以我也分享給了大家這幾種常見消息中心的原型資源（完整資源見文末），有需要的小夥伴可以直接下載使用喲～

常見消息中心分析

1.知乎

知乎的消息中心採用了消息彈層+落地頁的形式，彈層向用戶展示消息中最核心的信息，讓用戶能夠高效獲取信息並快速判斷是否需要進行處理。而落地頁則是將所有信息以天為單位進行匯總展示，方便用戶快速定位到某條消息。

知乎作為一個問答社區，有很多種不同的消息通知。但設計者並沒有將所有類型全部單獨自成一類進行展示，而是根據他們的重要程度和內在屬性劃分成了【消息】和【私信】兩個大的類別，又將【消息】中所有通知劃分成了【提醒】、【關注】、【感謝／贊】。讓用戶可以很快的對消息的屬性做出判斷。

在這裡，知乎將【感謝／贊】單獨分成一類，是因為這類操作是表達對知乎平台內容產出者的認同的最重要的方式，而被認同的感覺以及其所伴隨的成就感能夠鼓勵用戶更多地分享自己的學識、見解和經驗，促進活躍。所以在設計消息分類時，我們不僅需要根據消息的邏輯類型來進行劃分，也需要充分結合產品特性進行思考。

2.PMCAFF

PMCAFF是針對產品經理所創立的內容社區，功能相對比較簡單，所以它的的消息中心也設計地非常簡潔，只有一個匯總的落地頁。

但在落地頁中，PMCAFF將【邀請我回答的問題】從【全部通知】中單拎出來列為一個獨立標籤，並且這類消息不是點擊標籤就被標記為已讀，而是需要用戶前往回答或點擊【忽略】才會被標記已讀。這也體現出PMCAFF非常鼓勵用戶去產出，努力地在為用戶營造一個好的UGC環境，讓平台形成良性循環，同時加強自身平台的特色。

3.新浪微博

新浪微博的消息中心非常完善並且龐大，它作為一個社交平台，用戶間的互動形態非常多，並且重要性比較接近，所以它將每種消息單獨作為一個分類，方便用戶進行篩選查看。

新浪微博沒有採用類似知乎的消息彈層的形式，而是直接將用戶從消息提醒引導到功能齊全的落地頁，我認為主要有以下兩點原因：一是因為新浪微博絕大多數消息都是來自對單條微博或評論的交互操作，而微博作為沒有標題的圖文信息，在彈層中並不方便展示其縮略信息；而是在落地頁用戶可以直接看到完整的前後文信息，並可以直接進行【回復】操作，能夠促進用戶進一步交流互動。

4.石墨文檔

石墨文檔是一款可以多人同時編輯同一文檔和表格的在線協作文檔工具，作為一款工具型產品，它的所有消息都是有關合作者的「協同協作」的通知，比如【添加協作者】、【評論】、【@】等。

工具類產品不同於其它平台類產品，消息並不是用戶關注的重點，用戶往往比較專註於自己的工作面板和當前的任務，並不希望常常被打擾。並且用戶可能會直接通過任務本身（比如打開文檔）就能看到【評論】和【@】等內容，而不需要通過消息中心一一查看。所以石墨文檔將消息中心做的非常簡潔輕量，數字提醒很弱，並且只有一個消息彈層來，讓用戶在有需要的時候「有跡可循」，不需要的時候也完全不會受影響。

當然，為了保證重要消息的接收，石墨會為【邀請協同】等重要通知發送郵件提醒，保證用戶能夠實時獲取到重要通知。

5.Teambition

作為一個工具類產品，Teambition同樣是採用了彈層的方式來設計消息中心。但Teambition的消息中心彈層非常大，不僅能夠承載消息通知，還能直接在當前頁對任務進行處理。當然，這樣的設計和Teambition本身的產品功能和特性有很大關係，它的消息幾乎都是和單個任務的操作相關，而單個任務的形態也相對簡單，可以在彈層中完整展示和操作。所以設計者將消息通知和任務快捷處理都設計在彈層中，這樣用戶在工作中可以在不脫離當前的任務流程的情況下，快速高效地在當前頁把事情處理完畢。

知乎、微博、PMCAFF都是平台型的網站，而石墨和Teambition是工具型的網站，因為屬性不同所以消息中心的表達側重點也就不同；而同樣是平台型的網站，由於不同的產品定位、特性和功能，各個平台的消息中心最終呈現方式也各不相同。

所以我們在設計消息中心的時候，除了參考常見的設計形式外，一定要充分結合自身的產品特性、消息類型來進行思考，做到不僅能夠向用戶合理有效地傳達各類信息，也能從產品設計上去引導用戶完成我們想要鼓勵用戶進行的操作。