消息通知是連接系統和用戶的橋梁，然而對于不同系統來說，如何設計消息組件，促進用戶與系統的溝通呢？對于平臺中的用戶與用戶之間的溝通，我們又該采用哪些互動方式呢？讓我們一起來看一看不同的消息組件有哪些，希望能幫助我們做出更好地B端設計。

消息通知在我們設計的過程當中非常重要，因為它作為系統與用戶之間溝通的橋梁，能夠幫助我們提示用戶：“目前的操作狀態、系統的公告、用戶之間的互動內容”，而不同的消息內容，我們需要使用不同的消息通知組件來進行反饋，比如用戶與用戶之間的互動應該采取什么互動方式？那我們就來說說消息通知組件的具體使用。

一、消息通知的定義丨具體有哪些組件是消息通知

我查閱了各大設計系統[1]，發現它們對于消息通知的定義都叫做“反饋”，即信息反饋給用戶的形式。而在其反饋的組件當中，會包含有：全局提示（Message）、通知提醒框（Modal）、氣泡確認框（Popcomfirm）、對話框（Modal）、抽屜（Drawer）、進度條（Progress）、結果頁（Result）、加載中（Spin）、骨架屏（Skeleton）但由于組件太多，我們把系統當中用到最多的 消息通知 部分單獨拿出來分析，剩余部分則放在最后去做解析。

對于反饋的內容來說，系統當中會存在 正面、負面、普通 三種不同的反饋情緒，比如你的賬號已經過期，對于系統來說他就會提供一個 負面 的消息通知組件，因此我們會對消息通知的類型進行一個簡單的分類：

• 正向主要包含有：全局提示（Message）、通知提醒框（Modal）、氣泡確認框（Popcomfirm）
• 負向主要包含有：警告提示（Alert ）、對話框（Modal）、通知提醒框（Modal）

當然大家一定要記住，關于 正向 和 負向 的類型，它并不是絕對的，只是大多數情況下它的情緒與這個相關。

[1]查閱的設計系統包含：Element、Arco、Ant、Lightning…

二、消息通知的設計丨關于消息通知究竟有哪些

為了讓所有同學能夠快速直接的了解消息通知的設計形式，我們嘗試去“測評”，將目前的所有消息通知組件，然后按照：「操作干擾度、反饋消息的強弱、出現位置」三個維度來對消息通知進行分類，從而得出消息通知設計當中，它們的差別究竟在哪？

信息展示量：

信息展示量表示組件能夠承載多少信息內容。因為不同的組件它們的使用環境本身并不相同，我們可以通過原子[2]的劃分大致歸納為：圖標、文本、鏈接、按鈕、容器差別

操作干擾度：

操作干擾度主要是 對用戶當中操作會不會產生相應干擾，比如一個 全局提示和一個對話框，它們對于用戶的影響程度是完全不一樣的，因此會使用干擾度進行判斷。

當然操作干擾度這個維度過于主觀，我們又將其細分為：持續時間、是否阻斷、信息來源 三個方面持續時間：用于表示這個組件在頁面當中究竟需要停留多久時間，這樣能夠幫助我們判斷其干擾程度。是否阻斷：頁面當中是否會出現 蒙層 用于阻斷用戶注意力。這也是判斷干擾程度的重要指標。信息來源：這條內容主要來自哪里，分為 系統、用戶 兩種來源方式。

出現位置：

這個組件究竟會在哪一個地方出現，主要考慮它們的呼出方式，以及對應呈現內容，能夠幫助我們快速理解。?

[2]原子設計理論：原理分析丨聊一聊原子設計，對頁面造成的影響

1. 全局提示丨 Message

全局提示在用戶執行操作時，不會中斷當前用戶操作的前提下，通知提示一條簡短的消息。它在整個B端系統當中使用的頻率非常的高，比如：我們在填寫一個表單過后，就會收到全局提示；修改完一個信息過后，會收到一個全局提示。

而它在使用過程當中會有以下幾個特點：

信息展示量：

全局提示只會展示：圖標、容器、提示文字，相對來說它展示的內容較少，是一個非常簡單的組件類型。

在實際工作當中，因為它內容量少，更多提示用戶的便是正確的操作，比如 已添加成功、編輯成功、保存成功 等正向情緒。

操作干擾度：

關于干擾程度，我們剛才講到一共會有三個判斷依據，因此我就從這三個方面來去判斷具體提示的干擾程度。

• 持續時間：非常駐，一般3-5s即可消失
• 是否阻斷：否
• 信息來源：系統收到用戶操作后的提醒

出現位置：

全局提示因為其內容較少（圖標+文字），因此很多時候需要出現在較為顯眼的位置。我們在使用全局提示的時候，基本上都會出現在頁面頂部居中的位置，通常距離頂部的距離為 40-60px 。這個位置大概率是頂部導航與頁面內容的交匯處，不會影響用戶的使用。

注意事項：

關于注意事項，其實就是我們在實際工作當中，還需要去考慮的一些小知識點，我們將其匯總到此：

（1）全局提示一共會有五種樣式類型，分為是：指南提示（Info）、普通提示（Normal）、成功提示（Success）、警示提示（ Warning）、失敗提示（ Error）。

這時候，認真的同學可能會問：“老師，你剛才講了全局提示不是表達 正面 的結果嗎？怎么還會出現 警告、失敗等信息呢？其實這個原因主要是“失敗也要分很多種，就像我們的失敗一樣 /偷笑”比如：“在一些小的操作時，你確實不能提供對應的功能，就可以展示警告信息，如下圖”

（2）全局提示“一般”不會存在關閉入口，因為它可以自動消失，不提供給用戶關閉入口還會讓他知道，這個通知本身就會自動消失。所以很多情況下可以忽略關閉入口這個選擇。

（3）關于它的停留時間，我們可以在設計系統當中的 API 里進行自定義，通常 3s – 5s 即可。在去做組件時，一定要去看組件的對應開發文檔，了解這個組件究竟支持哪些自定義功能（拒絕被開發忽悠）

（4）全局提示在短時間內，可以提升多次，多次提示時，按照先后順序從上往下進行排列

2. 警告提示丨Alert

警告提示常駐于頁面中，用于表示持續性的提示信息。多用于危險、警告、緊急 等負面情緒當中。在實際工作當中，因為它的特殊性，一般會用在 系統、全局 性的危險通知上。比如你的訂閱時間已超時、賬號團隊即將解散等通知上。

信息展示量：

這里警告提示會比全局提示展示的信息更多，它主要包含：圖標、提示文字、輔助文字、按鈕、關閉入口

操作干擾度：

• 持續時間：常駐，需用戶點擊關閉后才會消失
• 是否阻斷：否
• 信息來源：系統收到用戶操作后的提醒

警告提示的常用場景：多用于警告、危險等情況，需要提醒用戶，引起他們的注意。比如提示欠費、需要充值

出現位置：

因為其需要常駐，所以通常在設計時候，我們會將它放在模塊與模塊之間，進行展示。這樣既不會影響到其他內容呈現，同時自己又能常駐。

注意事項：

• 全局提示主要呈現 警告、緊急的消息通知，如果想通知一些普通消息，完全可以使用 通知提醒框 來進行提示。
• 全局提示主要是在 模塊與模塊之間 去做呈現。

3. 通知提醒框丨 Notification

通知提醒框在頁面當中，主要是以互動的消息為主，全局展示通知提醒，將信息及時有效的傳達給用戶。在實際的工作當中， 通知提醒框主要用來提示互動等有價值的信息。

信息展示量：

這里通知提示框主要包含：標題、輔助文字、按鈕、關閉入口

操作干擾度：

• 持續時間：常駐 / 3-5s消失
• 是否阻斷：否
• 信息來源：用戶與用戶之間的互動、系統通知

出現位置：

在整個通知提醒框的使用過程中，因為它本身就是與用戶之間的互動所產生的，而這種活動就如同在桌面端當中你收到的消息，我們會將其歸納到右上角的位置去做呈現。這樣既不會太影響用戶，同時也能夠保證消息通知的及時性。

4. 氣泡確認框丨Popconfirm

氣泡確認框是我們在工作當中使用頻率相對較低的組件。它能夠通過組件當中的卡片，完成與用戶的快捷對話，但是由于在實際的場景當中，對話確認是需要強提示的方式，因此總感覺氣泡確認框在它的使用上，有著些許矛盾。氣泡卡片輕量、不易干擾用戶，但是對話框要求阻斷意味更強。

信息展示量：

首先我們從信息展示量來說，氣泡確認框主要由 觸發器、氣泡卡片、圖標、文本、按鈕操作，五部分組成。

在設計時需要格外注意，氣泡確認框本身不能夠過于復雜，否則在一個氣泡卡片當中，就顯得格外擁擠。如果信息過多，就考慮使用 對話框 來進行呈現與優化

操作干擾度

• 持續時間：用戶點擊觸發器后才能展示，操作過后即可消失。
• 是否阻斷：否（氣泡卡片不會存在阻斷的情況）
• 出現位置：跟隨觸發器位置進行呼出，通常會在觸發器的上方來進行展示，如果觸發器位置靠近邊緣，則考慮移動到其他位置進行調整。

5. 對話框丨Modal

對話框在整個系統當中非常重要，因為你會發現在整個系統當中或多或少都會有它的身影，比如一個常見的數據錄入表單，它的整體感覺和對話框較為類似；又或者是 一個穿梭框，你會發現也有異曲同工之處，因此我們先來看一下對話框究竟是什么？

對話框主要用于信息確認與信息錄入，使用對話框會中斷用戶當前的任務流程，同時會對用戶造成些許干擾，因此在使用的時候，我們都需要非常謹慎。

操作干擾度：

• 持續時間：常駐，需要操作完信息后，點擊提交才會消失
• 是否阻斷：是，通過黑色蒙層的方式，讓用戶聚焦于表單內部
• 信息來源：根據預設的內容，進行展示
• 出現位置：位于整個頁面的中部，主要目的能夠讓用戶聚焦于內容，減少分心。因為對話框的出現，用戶必須操作完對應信息過后才能夠進入到下一個環節， 因此它在整個流程當中非常重要。

對話框的類型：

在整個對話框的展示當中，你會發現它主要分為三部分，分別是 Header 標題位、Content 內容部分、Footer 底部操作位，而在這三個部分所組成的內容當中。

其中由于它的用途不同，我們可以將其簡單的分類為：確認對話框、消息提示對話框、功能業務對話框

確認對話框：展示對內容信息的二次確認，這樣能夠減少用戶的誤操作，降低操作風險。主要差別是內容部分以操作過程會出現的問題為主，來進行展示。其本質就是一個二次確認的過程，需要用戶去做出判斷，它要比 氣泡確認框 更加重要，阻斷性也更強。

消息提示對話框：展示對應的狀態提示，比如當你刪除掉一個知識庫過后，這種重要操作時，我可以通過消息提示對話框來將成功或者失敗的消息展示給你，并且也能夠讓用戶知道問題究竟出現在哪里。其本質就是一個消息狀態通知，只是更為重要。

功能業務對話框：將 Content 內容部分進行優化，用于展示更多復雜信息，比如 各種復雜信息錄入（輸入框、單選、多選…）以及各種信息呈現，它能夠通過功能業務對話框，去完成很多業務要求。

同時使用彈窗[3]的形式，能夠幫助我們不脫離當前業務的前提下完成更多操作。當然在實際工作當中你會發現，它能夠承載的內容是非常多的，比如步驟條、Tab 標簽、各種選擇錄入，因此我認為這種類型的對話框本質上就是一個 容器，可以去承載很多內容。更多注意事項就是彈窗部分的內容，比如尺寸寬度究竟是多少、高度為多少，是否有蒙層等等。

三、幾個組件的差異對比丨了解組件的差別

為了讓同學們能夠快速了解這幾個組件之間的差別，我們嘗試把剛才提到的這么多組件進行相應的對比，分析一下其中差異點。

全局提示與警告提示

首先這兩個組件在設計樣式上是非常相似的，并且本身使用環境差距不大，因此很容易把這兩個組件進行混淆。其實我們可以從多個方面去進行對比區分：

1. 全局提示不建議使用關閉入口
2. 全局提示優先級更低，主要提示非緊急通知；警告提示則提示更多緊急需要用戶立馬操作的通知
3. 全局提示會停留 3-5s 后自動消失；警告提示則需要操作后消失

氣泡確認框與對話框之間的差別

這兩個組件之間，同為用戶二次確認的組件類型，但在實際的業務當中有著重要級之間的關系。

1. 氣泡確認框相對適合阻斷流程意味不強的情況，它更為輕量。對話框反之
2. 很多時候氣泡確認框會成為 對話框 的二次確認方式，這樣能夠避免出現彈窗套彈窗的尷尬局面

四、消息通知的優化丨了解除了傳統組件之外的通知方式

我們在去理解消息通知的時候，往往不能夠只去看待消息通知本身的組件形式，最終的目的一定是讓用戶能夠更快速、直觀的了解到他所關心的內容，因此在設計上，我們可以進行對應的優化。

聲音提示

因為我們大多數 B 端產品都是采取網頁端的形式進行內容呈現，因此往往會忽略通知提示當中的聲音部分。雖然我們在網頁端，但是也能夠通過播放聲音 + 頁簽的信息通知（你有一個新消息，注意查看），讓用戶知道他有重要信息需要處理，這樣也能間接達到目的。

多端聯動

大多數 B 端產品，都會遇到系統當中主要都是聚焦于桌面端，移動端的體驗幾乎為零。因為很多產品目前的移動端都是使用小程序解決，那通知就變得更加困難，這時候其實可以嘗試用一些通用方式打通設備限制。比如我們可以嘗試發送 微信訂閱號 推送系統通知，這樣既能夠保證用戶日常的使用習慣，同時進行多設備間的聯動。

再舉一個例子，比如在日歷模塊，其實就可以通過日歷本身的 CalDAV 帳戶，來實現多設備間的日歷聯動，這樣就能夠保證 桌面端不是一個孤島~

通知分類

通知本身就是高觸發的一個場景，就類似于手機的短信一樣，會存在大量的冗余信息。因此我們再去設計通知的時候，考慮到不同的通知類型一定要采取不同的處理辦法。

而想要在工作當中做好這件事，必須先將系統當中所有的通知信息進行整理，從而將其進行分類，分類規則大體遵循：用戶之間互動＞用戶系統互動＞系統系統互動。

因此作為 B 端設計師，組件之間的差異一定要重視起來。

五、結尾

消息通知就像是我們用戶與系統、用戶與用戶之間的一個橋梁，而各種消息通知能夠讓我們用戶知道操作是否正確。也正是很多設計系統講的原則：操作之后有反饋，你的反饋內容是什么，就會直接決定我是否敢于去操作。