整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
輯導語：彈窗，不只是“彈出式廣告”，它是一把雙刃劍，用得好能使用戶更加聚焦，用得不好則可能使用戶不快甚至擊退潛在用戶。那么，彈窗要怎么設計呢？本文作者對彈窗進行了詳細的分析，一起來看一下吧。
說到彈窗，很多人對彈窗的印象還停留在“彈出式廣告”: 網站為了獲利，廣告商為了增加點擊率，那時候的廣告就像槍林彈雨，用戶無處可躲，進而惱羞成怒，甚至想要砸掉電腦。
廣告彈窗曾經在2010年被《時代》雜志評為最糟糕的發明之一。
我們如今再熟悉不過的淘寶曾經為在電商領域存活下來，也不得已使用大量的“流氓廣告”，雖然這的確使得用戶惱怒，但是不得不說，淘寶也因此刷臉頻繁而讓大家更熟悉它。
彈窗是一把雙刃劍，用的好確實使用戶更加聚焦，而如果使用的不恰當，可能會使用戶不快甚至擊退潛在用戶。在設計彈窗時，你有沒有遇到過下面的困惑？
可以說，彈窗設計的好不好，可以極大的體現一個設計師的基本功扎不扎實，別看一個小小的彈窗設計起來似乎非常容易，但面對不同的用戶場景、業務背景，彈窗背后的思考從未停止，今天就讓我們全方位地了解彈窗。
在正式認識彈窗前，我們不妨設想以下的場景: 你正在家中做事情，但是這個時候電話鈴響了， 你不得不放下手中的事情去接電話， 但是假如在智能家居環境中，你可以通過人工智能自動接電話，同時你手中的事情仍然在繼續中。
如果說把前者比喻成跳轉的頁面，那么后者就是彈窗，它能夠在吸引你當下注意力的同時，不離開當前的場景。
目前設計界對于彈窗的定義多種多樣， 從外觀布局上看，彈窗是頁面上層彈出的容器，容器中承載著文本、按鈕、選項、標簽或表單等組合內容；從設計目的上看，彈窗是用戶與產品間對話的一種方式，是對用戶注意力的一種引導形式，根據抓取用戶注意力的多少，可具體定義為Dialogue、Actionbar、Popover、Toast、Snackbar等等特定形式。
從廣義上講，彈窗其實并沒有如它的定義那樣框的那么死，有時候彈窗不一定有容器，比如追劇時常見的彈幕，也是一種新型彈窗； 再比方說新手引導，也是一種彈窗。不過，咱們在這里談論的還是狹義上的大家在規范中所常見的彈窗，那些非典型的彈窗就不在今天討論的范圍之內。
彈窗的基本組成可以拆解為：
為了使用戶更聚焦于彈窗，我們會在彈窗容器下方頁面上方加一層遮罩， 通常這種遮罩是半透明黑色，如果遮罩顏色越深，用戶越能夠專注于當前頁面； 遮罩顏色越淺，用戶的跳出感越小，產品也更親民。
當頁面中出現多個彈窗時，也就意味著多個遮罩層，這個時候遮罩層的顏色該怎么確定呢?
根據各大規范，彈窗疊彈窗不建議超過三個，當彈窗大于等于3個時，遮罩的顏色就不再改變。這里再補充一點， 當彈窗數量過多，一個疊一個，用戶容易迷失放向，這時候可以采用位置錯層的方法。
彈窗主體可以拆解為標題、內容、動作按鈕。
彈窗的標題和內容的書寫規則，在后文中有詳細描述，這里不再贅述。
彈窗的動作按鈕一般不超過3個:
1個按鈕: 那一定是可以關閉彈窗的操作，比如信息公告類的彈窗的“我知道了”。
2個按鈕:這是最常見的情況。一個是推進任務進程的動作，一個是取消。
3個按鈕:這種情況比較少見，比如“了解更多”，但這會讓用戶離開彈窗，導致彈窗任務未完成，所以不推薦使用。 如果有更多內容需要向用戶展示，可以內嵌一個信息擴展，點擊圖標在彈窗下方展示更多信息，這樣了解更多信息的同時，也不用離開彈窗。
至于彈窗按鈕的位置擺放，有兩種常見的擺放規則:等分居中擺放和某一側擺放(右側居多)，不同平臺有不同的擺法，接下來舉例說明:
1）Material design中右對齊
2）IOS中等分居中擺放
3）在Fiori規范中，手機端的按鈕是等分居中擺放，但是在電腦端采用右對齊
對于模態和非模態的關閉方式，從根本上說是很不同的。
對于模態彈窗，它的關閉方式只有做出選項選擇后彈窗才會消失， 包括“取消”選項。 而非模態彈窗的關閉方式就很多了，總結下來有四種方式:
1)關閉按鈕(叉叉)
通常是位于右上角，少數規范把關閉按鈕放在左上角，只要保持一致即可。
2)取消按鈕
通常和“確認”或者其他推進任務完成的動作按鈕放在一起，成對出現。
3)ESC鍵
敲擊ESC鍵，也可以退出非模態彈窗。 Esc鍵是英文單詞escape的縮寫， 在1960年由IBM的一位程序員創建，它的功能是“撤銷”、“退出”。
盡管如今使用鼠標進行交互的人占絕大多數，但是出于無障礙設計(包容性設計)的需要， 通過鍵盤完成交互是必不可少的，所以ESC按鈕也是必需的。
而且這類快捷鍵上的優化能夠大大提升用戶使用效率，減輕用戶的操作成本。
尤其在B端產品中，調用鍵盤進行操作優化，是一個不可忽視的用戶爽點。
4)點擊遮罩區域
遮罩區域就是彈窗背后的內容區，通常為了使用戶更聚焦會加上一層暗色遮罩，當用戶點擊遮罩區域后，非模態彈窗會自動消失，不過為了避免用戶誤觸，如果彈窗是表單等需要用戶輸入的內容時，這些內容要自動保存。
對于“取消”和“關閉”按鈕，這里想要再闡述更清楚一些:先舉個生活中常見的例子，假設你有一個愛問十萬個為什么的小孩，你正在津津有味地追劇，結果他跑過來問你問題，他還沒張口呢，你就捂住耳朵不聽不聽，這個呢就相當于彈窗右上角的關閉按鈕(叉叉)，不過關閉按鈕僅僅存在于非模態彈窗中，用戶可以不做任何選擇地關掉彈窗，而模態彈窗要求用戶必須做出某種選擇，不給用戶逃避的機會，所以模態彈窗是沒有關閉按鈕的。
然后小孩問你是雞生蛋還是蛋生雞，你聽了這個問題也不知道怎么解釋，只能和小孩說，這個問題我也不知道怎么回答，這個就相當于彈窗的“取消”按鈕。
雖然“取消”按鈕和關閉按鈕(叉叉)最終都會導致彈窗關閉，但是從邏輯上而言，是不同的。
彈窗可以分為模態彈窗和非模態彈窗兩種類型， 這兩個概念來源于開發人員的術語。
當打開一個模態彈窗后，它所屬頁面的進程被打斷了，必須等用戶處理完畢模態彈窗后，才能夠回到剛才正在進行的頁面。
舉個例子，你準備刪除一個重要的文件，系統彈出一個彈窗，問你確認要刪除嗎?這個你時候你必須下一個明確的指令，選擇刪除或者不刪除，然后你才可以離開當前界面，我們可以簡單的把模態彈窗理解為用戶不得不做的選擇。
再來看非模態彈窗，非模態彈窗允許用戶在不打斷當前頁面的同時，去處理其他任務，舉個例子，設計師們最熟悉不過的PS，你可以同時調用多個彈窗去更改畫面參數，因為藝術創作是一個多線過程，藝術家可以想到什么參數就改變什么參數。
模態和非模態只是一個比較概括性的概念，而且不同的規范里可能對相似的某一類彈窗的稱呼完全不同或者有輕微差異，接下來我分別根據 Microsoft-Fluent UI、Google- Material Design、IOS 規范中拿出一些比較有代表性的彈窗類型詳細講一講。
1）Actionsheet
類型:模態彈窗
參考規范:IOS Design
簡介:Action sheet一次展示和當前語境相關的兩個或者更多的動作，非必要不要展示太多的動作選項，以及避免在動作列表中使用滾動條。
關鍵點:
2）Modal
類型:模態彈窗
參考規范:Microsoft-fluent UI
簡介:Modals也是一種模態彈窗，它需要人們把注意力從當前頁面短暫轉移到彈窗上，并且需要用戶的交互動作。和Dialog不同的是， Modal 更適合長文本內容，如隱私條款、知情同意書等等，抑或是要求用戶進行較為復雜的操作行為如更改頁面設置。
3）Dialog
類型:模態彈窗
參考規范:Microsoft-fluent UI
簡介:Dialog是一種模態彈窗，它需要人們把注意力從當前頁面短暫轉移到彈窗上，并且需要用戶的交互動作。它基本被用于較為簡單的場景下，如確認信息、刪除文檔、做出一個選擇。
分類:
使用場景:
關鍵點:
4）Drawer
類型:模態彈窗
參考規范:Material Design
簡介:Drawer是一種容器， 它的性質和生活中的抽屜很像， 通常用來放置和某個特定窗口相關的一些信息或者選項。默認情況下， Drawer是隱藏的， 它通常是通過一個按鈕或者菜單觸發， 從父級界面的一側滑出來，所以它不能夠脫離父級界面而單獨存在。
關鍵點:避免使用drawer，現在流行的軟件已經很少會使用drawer了，而且也不提倡使用。如果你想展示補充性的內容的話，不妨嘗試一下panel、popover、sidebars、split views。
5）Popover
類型:模態、非模態
參考規范:IOS Design
簡介:當你輕觸一個區域時，Popover會短暫的出現在其他內容的上層， 通常來說，一個Popover包含一個箭頭，指向它彈出來的位置。當你點擊屏幕中的其他區域或者Popover上的按鈕時，一個非模態的popover會取消顯示。而模態的popover只能通過點擊它上面的cancel或者其他按鈕而取消顯示。
Popover更最適合大屏幕的設備， 并且可以容納很多元素，包括導航欄、工具欄、tab欄、表格、圖片、地圖、傳統視圖等等。當Popover可見時，在它消失前，當前頁面的其他交互是不能進行的。
關鍵點:
6）Snackbar &； Toast
類型:非模態
參考規范:Material Design
簡介:此處將Snackbar和Toast放在一起講，因為這兩者十分相似但是又有所差異。
Toast屬于一種輕量級的反饋，它比Snack bar的提示程度輕， 常常以小彈框的形式出現，一般出現1到2秒會自動消失， 但為了保持一致性，同個產品盡量使用同一位置。 和Snack bar有所區別的是，Toast常常被用作系統提示消息，不包含動作按鈕，可以出現在屏幕上中下任意位置， 并且只有安卓中有Toast。
Snack bar被用來通知用戶該程序正在發生或者即將發生的進程，也就是說Snack bar的內容一定是和用戶當前操作相關的，而Toast彈出的內容和當前操作沒有任何關系，只是一個系統提示，比如說“你收到了一條消息”這種。
Snack bar同樣短暫的出現在屏幕的底部，不中斷用戶體驗，也不需要用戶任何操作，自己就會消失。它繼承了Toast的所有基礎屬性，但是不同的是:
這里值得注意的一點，Material design中已經不再推薦使用Toast而是更推薦Snack bar了，但是目前Toast在安卓應用上仍然在被廣泛使用。
下面著重介紹一下Snack bar。
使用場景:既想要展示信息，又想最小程度地打斷用戶注意。
關鍵點:
7）Tooltip
類型:非模態
參考規范:Material Design
簡介:當Tooltip通過鼠標懸停、聚焦、或者觸摸后被激活，它會識別一個與之對應的元素然后在該元素附近顯示簡短、描述性的文案，通常是對該元素的功能解釋，在停留短暫的時長后，Tooltip會自行消失。
關鍵點:
8）Andriod Notification
類型:非模態
參考規范:Material Design
簡介:在軟件不被使用期間，Notifications提供關于軟件簡短、時不時的的相關資訊。這種資訊可以是來自其他用戶的交流信息或者提供任務提醒。
Notifications如何被用戶注意到:
9）Message bar
類型:非模態
參考規范:Microsoft Fluent UI react 8.65.1
簡介:顯示軟件或者文件的錯誤、警告、重要的信息。比如說，一個文檔上傳失敗，那么錯誤的messabe bar就會出現。
關鍵點:
10）Coachmark &； Teaching bubble
類型:非模態
參考規范:Microsoft Fluent UI react 8.65.1
簡介:Coachmark 是為了吸引用戶注意力并且增加用戶使用他們的機會，當鼠標懸?；蛘哌x擇Coachmark時，Teaching bubble就會顯示。
關鍵點:
彈窗作為一種容器，在選用時常常和抽屜、頁面一起比較，那么在給定一個內容時，我們該根據什么來選擇使用哪種類型的容器呢?
首先，我們先把這三個容器的定義搞清楚。
接著，在我們被給定一個需求時，要先分析這個需求，從一下幾個方面去判斷:
1）信息承載量
既然是容器，必然有容量這一說，在這里用信息承載量可能更合適，信息承載量包括圖片、視頻、文本、表格等等各種形式的信息量，當信息量非常大，密密麻麻十分惱人時，彈窗自然是不被推薦使用的了，通常來說信息承載量大小有這么一個規律: 頁面 >； 抽屜 >； 彈窗。
不過信息承載量只是考慮的第一步，是一個比較宏觀的方面，不是決定性因素。
2）頁面獨立性
獨立性可以理解為與前一個或者當前頁面的聯系是否緊密。 頁面的獨立性最高，當你不斷打開一個又一個新的頁面，常常會記不得上一個頁面的內容，這就是因為這些頁面的內容相對獨立，關聯性不大。
而我們僅僅是從定義上不難看出，彈窗和抽屜的獨立性較低， 彈窗的前提是不離開當前頁面內容，甚至彈窗的主體不能夠遮住當前頁面的重要內容；抽屜是建立在父級頁面基礎上的，它是對父級頁面內容的補充。
大多數彈窗是與當前用戶正在執行的操作內容相關的，比如在表單錄入的場景下，選擇時間會彈出時間彈窗，選擇地址時會彈出地址簿彈窗。
抽屜比較適合內容度較深、邏輯緊密、概括性簡短的內容但不是時時必須展示的內容， 如購物網站的目錄導航、safari收藏夾等等。
而頁面和頁面之間的邏輯性不強甚至可以毫無邏輯，比如跳轉到一個莫名其妙的廣告頁面。
3）頁面切換成本
當用戶因為某個業務需求需要頻繁在A和B頁面間切換時，這個時候我們就要考慮切換成本。
抽屜有一個固定位置的觸發按鈕，所以當需要頻繁操作時，用戶能夠快速找到并彈出抽屜，減少學習成本。
彈窗回到頁面的速度也很快， 如果是非模態彈窗，它可能會自行消失、點擊遮罩區域消失或者點擊關閉按鈕消失，對于模態彈窗來說，只要用戶做出了明確的操作后，彈窗就會消失，自然的回到當前頁面。
頁面是切換成本最高的，一般需要點擊返回按鈕，返回上一級頁面，這個時候頁面加載需要一定的時間，用戶需要快速認知一個全新的頁面需要一定的適應時間，所以頁面的切換成本最高。
1）UX Writing規則
2）標題
標題是用戶第一眼注意到的內容，用戶掃一眼標題來快速了解這個彈窗是做什么的，所以標題的重要性不言而喻。
3）內容
4）如何優化按鈕文案
操作清晰可預測。 減少使用中性詞， 從而避免用戶停頓思考，讓用戶看到文本的瞬間就明白按鈕時會發生什么。
優先考慮“動詞+名詞”的形式，如果不能夠這樣表達，再去考慮“確認”“取消”“關閉”這些中性詞。
5）反饋
操作后的反饋對于用戶體驗也很重要，正如你打游戲通關時，系統會發出喝彩的聲音，比如你提交了一個表單彈窗，當你提交后，應當顯示提交成功的反饋。
首先要明確的一點，在各大規范中都不推薦使用滾動條，因為首先彈窗的內容承載量就不大，如果是業務場景復雜的彈窗，我們可以采用Tab或者分步彈窗，盡量去避免在彈窗中使用滾動條。
那么，如果不得不使用滾動條的情況下，有幾點要注意:
1) Web端
調查市面上的電腦分辨率， 從數據圖中可見，分辨率900 * 1080是主流，最小的分辨率是1024 * 768。
俗話說“一個水桶，盛水量得看最短的那塊木板”， 所以理論上來說， 只要彈窗能滿足1024*768的分辨率，就可以適配市面上所有的電腦。
各個平臺根據自身業務量和需求的差異性，可以根據內容量再給彈窗的尺寸分類，常見的可以分為: 超級大、大、中、小尺寸，比如螞蟻中臺的Alert的幾種尺寸:
2) 手機端
手機端的彈窗一般都是全屏顯示，除了一些特殊的彈窗類型如Alert， Error， Notification會有固定的尺寸規范。
彈窗中有兩種生效模式: 即時提交模式(immediate commit model)和延遲提交模式(delayed commit model)
舉個例子，如mac的偏好設置中的桌面屏保，當你選中后立即生效，這里沒有提交也沒有確認按鈕，這種就是即時提交模式；而延遲提交模式更為常見，比如注冊網站會員時，你需要填好所有的信息，然后確認一遍，最后提交。
即時提交模式更適合本身操作量不大，但是切換頻繁的操作，尤其對于視覺聽覺上的效果改變，即時提交是非常高效的，常見的比如更換手機鈴聲、選擇照片濾鏡、更換電腦壁紙等等。
延遲提交模式在B端中非常普遍，它需要用戶仔細斟酌輸入的內容，用戶修改編輯滿意后再確認提交，比起效率，它更重視質量、減少出錯率。
1) 彈窗內的導航:
當彈窗內有次級彈窗(同一個容器，不同的內容)時，在次級彈窗標題部分，有一個返回按鈕，可以返回主彈窗。
2) 用戶改變彈窗的顯示大小
比如一些長列表，里面的條目很多，有一些字段因為比較長，被隱藏住了一部分，用戶需要滾動滑動條，來查看更多的條目，而當彈窗的大小可以被改變時，用戶就可以增大彈窗，從而每滾動一次，就能查看更多的條目，減少滾動條的操作次數，更大的視野也讓用戶的體驗感更好。
這里有兩個小細節值得注意:
3) 拖拽移動彈窗
有時候一個彈窗彈出來正好遮擋住了底部頁面的重要內容，所以彈窗需要有被移動和拖拽的功能:
4) 彈窗的防錯功能
在填寫表單場景下，比方說用戶已經花費了二十分鐘填寫表單，但是他不小心碰到了鍵盤上的Esc鍵，彈窗自動退出，那么他的內容就消失了，這對用戶來說是十分糟糕的，有如五雷轟頂!
所以對于一些彈窗而言，添加防錯功能是很有必要的，在不小心誤觸后，彈窗不會立刻關閉，而是彈出一個確認彈窗“你確定要離開嗎?你的內容將會丟失”，這個確認彈窗可以大大的降低誤觸帶來糟糕后果，畢竟很少人會連續誤觸兩次嘛。
確認彈窗確實是防錯的一個思路，還有一個思路是為彈窗添加自動保存功能，當彈窗不小心關閉后再打開時，剛才的內容還在，不過新用戶的心情會經歷一個跌宕起伏: “糟糕了!我的心血沒了!(哭泣)”–奧!!它們竟然還在，太驚喜了!”
需要明確的一點，在各大規范中，都不推薦彈窗疊彈窗，即使必要情況下，也會限制彈窗的數量，至于為什么這樣限制，打個比方你就懂了:大家小時候玩過俄羅斯套娃吧，每打開一個娃娃會發現里面還藏著一個娃娃，試想把娃娃換成彈窗，彈窗中還有彈窗。
但是在復雜的大型企業軟件中，不可避免的會出現多個彈窗的情況，我們又該怎么解決呢?
根據用戶的目標和任務的對應關系，彈窗和彈窗之間的關系可以分為線性和非線性關系。
1）非線形關系
比如Photoshop，里面的大量窗口都是非線形關系，我可以調一下這個參數，再跳到另一個窗口改變另一個參數，這些參數本身并不存在什么邏輯關系，所以Photoshop的工作臺可以將窗口隨意的打開、隱藏、關閉，可以根據設計師的使用頻率自定義工作臺的內容窗口，而面對復雜大量的功能，PS給了諸如搜索的工具，讓用戶自主的快速找到自己需要的功能。
對于多個非線形彈窗，與其耗費心機的建立一個復雜的結構導航，不如給他們工具，讓用戶找到他們自己想要的東西。
2）線形關系
當彈窗和彈窗之間存在緊密的邏輯關系時，常見的有三種形態:
舉個例子，叮叮的“新建項目”:
假設用戶的目標是想要從已有項目中復制一個模版: 點擊全部模版后，跳到模版界面，這一步就是“A容器中彈出B容器”。
進入模版彈窗后，點擊新建模版，選擇“從已有項目中新建”，可以看出這一步的彈窗的容器沒有變化，只是將彈窗的內容區域進行改變，這就是“同一容器不同內容”。
而“關閉A容器后，彈出B容器”，這個就不太常見，比如通常我們卸載一些流氓軟件時，會確認卸載之后，再確認一次，使得用戶十分惱怒，這些流氓軟件為了留下來真的費盡心機 ； 還有就是在填寫非常重要的信息時，系統為了提醒用戶“你一定要填寫正確，因為這是不可更改的哦”所以會確認兩次。
這個場景不常見，所以絕大多數彈窗只要一個確認彈窗就可以了。
我們從對話框傳遞的信息的性質和來源， 可以將對話框分為系統彈窗、信息展示彈窗、操作彈窗?！禔bout Face 4》一書中將彈窗更細致地分為屬性、功能、通知、公告、進度彈窗，其實理解起來是一樣的: 進度和公告是系統彈窗，通知屬于信息展示彈窗，功能彈窗就是操作彈窗。
系統彈窗:這是由應用程序直接啟動，而不是用戶請求發出的，比如“版本升級到2.0”“頁面崩潰了”。
信息展示彈窗:顧名思義，就是展示信息的彈窗，這個信息可以是來自其他用戶的消息、也可以是查看詳情等等。
操作彈窗:用戶需要對彈窗執行具體的動作，比如常見的表單錄入、確認刪除、上傳信息等等。
一般的簡單場景下，不需要再搭建額外的層級關系， 用常見的簡單的方式就可以完成需求， 但是在復雜的業務場景下，我們可能會遇到各種各樣棘手的問題，如信息太多、信息太復雜.
于是我們將一些頁面中會用到的層級框架運用到彈窗中，但是切記彈窗的承載量是很小的，不要濫用這些手段(比如說彈窗中又有Tabbar，又有側邊欄，這樣是很忌諱的)，這里提供幾種解決思路:
Tab是一種導航控件，當頁面的內容眼花繚亂時，我們可以將內容分類然后放入不同的Tab頁面中，如Mac中的系統偏好設置的顯示器設置。
Tab選項卡的形式是多樣化的， 包括僅文字、僅圖標、圖標+文字、帶有次級選項的Tab選項、帶數字/角標等等，設計師根據業務場景選擇最合適的。
當Tab和底部操作區同時存在時，操作區的層級永遠是最高的，所以說當點擊操作區按鈕時，其生效的范圍是所有Tab，而不是當前Tab。
如果用戶想在當前tab頁面完成操作的話，這個時候可以刪掉底部的操作區，推薦使用選擇控件如單選框/復選框， 當勾選選項的瞬間，這個行為生效。
在使用Tabbar時有幾個小細節要注意:
由于彈窗的寬度限制， Tabbar可承受的數量有限， 當Tab數量太多時，不妨考慮用Sidebar，以騰訊會議的設置彈窗舉例。 Sidebar和Tabbar類似，都是導航控件， 所以同樣地，如果用戶想在當前sidebar選項頁面完成操作的話，推薦使用選擇控件如單選框/復選框，它也是立刻生效。
在表單錄入場景中， 當信息又多又亂的時候，往往會降低用戶的閱讀效率，增加用戶的認知成本，分組就是一個很好的解決辦法。將同類的信息歸納成一組，可以給每個組加上一個標題，也可以只是在組和組之間加上分割線，界面更加清晰，操作流程更加高效。
分步彈窗適用于有一定的先后邏輯的操作步驟，必須完成第一步才能進行第二步，不可以像Tabbar或者Sidebar一樣隨心所欲地去任意位置，最常見的就是網站注冊。
這樣做有幾個好處:
彈窗使我們不得不聚焦于當前任務中，但是在一些信息錄入場景中，我們錄入的信息并不像我們的身份信息一樣信手拈來，比如商品信息的錄入，這個時候可以采用側邊欄的形式將參考信息放在旁邊。
以叮叮的“新建工作待辦”——添加執行人舉例子: 為了減輕用戶的記憶壓力，叮叮在右側提供一個常駐的側邊欄，用戶可以通過“最近聊天”“我的好友”“我的群組”等方式查詢到自己好友的姓名，這個側邊欄于左邊的頁面是相對獨立的。
彈窗規范雖然目前來說已經比較完善了，但是隨著業務場景的復雜化和多元化，我相信還會有更多新的規則產生， 這就要求設計師不僅僅要了解并合理運用規范，更要勇于質疑和思考，去不斷地完善規范。
以上是我對彈窗的一些思考和總結，如果你有不同的想法，歡迎與我交流! 期待聽到你的聲音!
本文由郝小七指導http：//www.woshipm.com/u/917803
作者：自來卷夏憶
本文由 @自來卷夏憶 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
對電腦PC端應用軟件彈窗信息騷擾用戶問題，工信部召開行政指導會，要求相關企業：①充分保障用戶知情權，明確告知用戶彈窗信息來源，不得以“默認同意”等方式強制用戶接受產品自啟動進行彈窗或提供相關服務；②尊重用戶選擇權，為用戶提供清晰、有效、顯著的彈窗信息關閉選項，不得采用虛假或過小關閉按鈕誤導用戶；③進一步優化改進產品，避免開機時集中彈窗，影響用戶正常使用，切實保障用戶權益。（央視新聞客戶端）
來源： 央視新聞
輯導讀：我們經常會收到各種彈窗，它們的目的主要是為回應用戶或讓用戶回應，是用戶與產品間對話的一種方式。但是，彈窗也不是多多益善。如何彈、什么時候彈？這些都是有章法的。本文作者總結梳理了一套彈窗設計原則，一起來看看吧。
產品經理：我覺得這里要加個彈窗，你去設計吧。
設計師：emmm…
彈窗到底該不該加？怎么加？用什么形態展示？真正的作用是什么？這些真的是產品經理說了算嗎？
好的產品通常會在恰當的時間、合適的位置給出合理的反饋，彈窗也是必不可少的反饋方式，不反饋、反饋不及時或反饋不合理都會帶來不好的使用體驗，甚至誤導用戶，從而導致用戶流失。
很多時候，產品經理會從商業角度、公司業務、資源限制等方面考慮問題，但這些未必是用戶所需要的，設計師不應該完全按照產品需求做設計，否則就成了只會照搬產品原型的“美工”。需要做的是從用戶角度出發，把產品需求轉化成設計目標，只有經過反復的推敲、認真分析，最終才能打磨出服務于用戶的彈窗設計，所以彈窗該不該加、如何加就成了設計師不可推卸的責任和使命。
本篇文章將圍繞著彈窗類型、使用場景、轉化率及常見問題為側重點，將自己對彈窗的理解、設計經驗分享給大家，幫助大家對彈窗組件有更清晰的認識，為后續避坑設計出更好的彈窗做準備。
當我們與應用產生主動或被動交互時，頁面上層會彈出容器，將可承載的文本、按鈕、選項、標簽或表單等任一內容與之組合，就可以用來傳遞信息、狀態反饋、引導用戶等操作，這就是彈窗。
彈窗的目的主要是為回應用戶或讓用戶回應，是用戶與產品間對話的一種方式，在線上各種場景中都有可能碰到，相當于產品的線上小助理。不同類型的彈窗其作用不同，但最終都是為了滿足跟用戶之間的友好交流。
彈窗組件的樣式很多，如浮層、對話框、下拉菜單、toast等，且iOS、Android官方平臺也都根據自身的規范對組件進行命名，不管如何稱呼，其常見的彈窗組件絕大多數都是由以下元素組成：
用戶在完成任務的過程中，界面會出現彈窗打斷用戶的操作行為，用戶必須通過主動點擊才可以進行下一步操作，這即是模態彈窗。
模態彈窗通常能較好的獲取用戶的視覺焦點，并通過承載的內容、按鈕主次層級來引導用戶完成他們的需求，這也會根據用戶、產品側重點的不同，彈出樣式也有所不同，常見的模態彈窗有對話框、動作欄、浮層…等。
1.1 對話框Dialog/Alert
對話框是很常見的彈窗，主要在打斷用戶后并提供選項操作，對用戶的干擾較大，通常會配備1~3個操作按鈕，而且會把用戶最期待的或產品最期待用戶操作的按鈕突出顯示。
對話框類型的彈窗主要分為主動、被動兩種觸發類型，主動彈窗：信息的二次確認、輸入內容、前置條件選擇、風險警示等；被動彈窗：版本更新、運營宣傳、消息通知、系統功能授權等。
1.2 動作欄Actionbar
動作欄是通過用戶主動操作后彈出的內容信息，基本都是從底部彈出，屏幕占用比例根據內容量的多少比較隨意，從小區域、半屏、再到全屏隨處可見。
動作欄相比對話框則能承載更多、更豐富的功能信息，在用戶清晰感知當前操作及反饋的情況下，比跳轉到新的頁面更有安全感。
1.3 浮層Popover/Popup
浮層是指用戶操作某個功能/內容后，會在附近出現一個帶有視覺引導性質的彈窗，最常見的浮層就是下拉菜單/彈窗等，浮動于頂層窗口并指向觸發操作的位置。
例如很多社交娛樂類型的應用右上角有一個“+”入口，里面會放置部分常用功能。部分浮層底部沒有設置不透明度的蒙層，為了與頁面信息更好的區分，會給浮層容器加上投影，避免與底部信息混淆。
相比模態彈窗，非模態彈窗屬較為輕量，觸發后以一種非阻礙的的方式呈現，不會打斷用戶的當前操作，主要是給予用戶即時反饋，讓用戶清楚應用當前的交互后狀態。非模態彈窗不強制用戶操作，根據反饋信息的重要程度及意愿，可在一定的時間內自動消失，也可等待用戶操作后消失，常見的有以下幾種：
2.1 提示框Toast/Hud
用于反饋用戶操作成功、警告、錯誤等當前狀態信息，可能出現在任何位置（底部/中間/頂部），在呈現樣式上，相同等級的模塊統一位置、風格即可，無需用戶有任何操作，出現2s左右自動消失。
Toast只有純文字提示，例如格式錯誤、刷新成功、刪除成功等；Hud會使用文字+圖標樣式，例如添加到購物車、關注成功等。
2.2 提示對話框Snackbar
Snackbar早期只是Android系統的一種彈窗控件，后在iOS、Web前端都會使用到，可以看作是toast的加強版。一般只出現在屏幕底部，存在的時間比toast長，提供0~1個操作入口，可自動消失，也可與用戶產生交互后消失或者跳轉至其他頁面。
Snackbar反饋的重要程度強于toast，例如，某個應用今天有重要提醒，同時又不想影響用戶的其他操作，會在用戶首次進入時彈出提醒，并提供關閉操作入口，等待用戶通過手動關閉（部分自動關閉），加強用戶記憶。
2.3 通知Notice
最有代表性的就是消息通知、系統推送，在設備未鎖屏的情況下，通常從頂部彈出，停留幾秒后自動消失，鎖屏后，不同設備彈出的位置也有所不同。Notice的前提是需要在應用設置中打開消息通知開關，具備應用外推送功能的，需在設備系統設置中開啟通知權限。
2.4 透明指示層HUD
HUD是一種在透明元素上通過填充、反饋用戶當前交互操作的指示層，實時生效，例如視頻類產品中的調整音量、亮度、控制進度條等。
當我們對彈窗體系有了一定了解后，就需要清楚什么場景需要設計彈窗？用什么類型的彈窗？
產品最終都是服務于用戶，如果僅憑自己的主觀意見亂加一通，整的花里胡哨，彈窗就成了干擾元素，很大程度上會影響用戶體驗。什么樣的場景適合什么類型的彈窗，我們可以從以下幾點來說明。
風險警示：當用戶的某種操作可能存在風險，為避免操作失誤，會彈出對話框打斷用戶，并給予一定的風險提示引起用戶的注意，讓其有足夠的時間確認是否真的需要進行下一步操作，如：刪除、放棄福利機會、退出登錄等，會彈出對話框提示操作后可能引起的后果。
前置條件：部分任務在流程中設有一定的前置條件，需要滿足條件才能進入下一步操作，通常這種情況會根據內容量的多少、重要程度以對話框或動作欄的樣式彈出，例如下單時選擇優惠券、支付方式。
任務關鍵節點：用戶在滿足任務的基本條件后，需要操作一個關鍵步驟才能成功，則會彈出對話框讓用戶完成最后一步操作，例如提交訂單、表單、輸入支付密碼等。
這類彈窗主要從產品角度出發，不會過于在乎用戶是否需要、會不會反感，都會引導或強制用戶操作。
例如產品發布新版本，會強制用戶更新，否則將無法使用。還有各大電商APP，在進入首頁時會彈出一堆紅包、優惠券，刻意將取消/關閉入口弱化，給用戶返回造成一定的難度，利用突出的視覺、動態效果突出主題增加吸引力，以達到轉化用戶的目的。
二次確認也是一種打斷用戶的操作行為，但跟上面純粹的打斷用戶相比其作用更大，主要是在用戶已做好選擇的情況下再次彈出確認，以免操作結果造成用戶認知上的偏差。雖然從用戶體驗角度出發，用最少的操作、最簡單的流程滿足用戶所需是產品追求的目標之一，但通過權和利弊之后，二次確認的出現實屬迫不得已的折中方案，它能夠起到給用戶多一次思考避免誤操作、同樣的含義換種方式表達、重要的內容加深二次記憶等作用。
二次確認使用得當，可以避免用戶、產品的潛在風險，但若是從主觀角度一味的濫用，就成了對用戶的惡意干擾、影響使用體驗，導致出現因多步驟操作增加任務完成難度、降低轉化率、損害產品形象等問題，所以需要從業務（用戶側、產品側）實際角度出發，兩相其害（加-影響使用體驗；不加-造成一定損失）取其輕的考慮是否需要增加二次確認彈窗。
當用戶的某個操作可能帶來不可逆轉、錯誤嚴重程度較高時，例如：放棄僅有一次機會的較好福利、手機系統還原、應用賬號注銷等，系統都會給予二次確認，降低用戶認知偏差后，以確保用戶是經過多次思考才做出的決定，即便后續給用戶造成損失也不會過于降罪產品，產品也算是“問心無愧”了。
常見于用戶操作之后的狀態反饋，即便用戶沒有注意到，也不會造成較大的損失、或結果已經注定，相對來說成本較低，大部分出現在任務過程中的提示（可重復）和結果反饋，以確保用戶知曉當前所處狀態。
非模態彈窗toas樣式居多，例如加載中、操作成功、刷新結果、清除緩存等，可出現在其他類型的彈窗之后或同時存在。
優秀的彈窗需要從視覺、交互兩方面思考，視覺上簡潔、易懂，交互上可操作且可控。
視覺層面：首先需要做到的是易懂，這時候就非常注重文案清晰程度及按鈕層級關系了，彈出的信息需能直擊要害，用戶看了能一目了然才是關鍵；其次，彈窗屬于一種干擾信息的存在，設計必須簡潔，在彈出時需要考慮是否會過度影響（影響是一定會有的、且看如何降低）用戶的其他操作。假想我們正在玩游戲、突然來了電話全屏幕覆蓋（傳統來電），自己會以最快的速度掛掉電話，回到游戲中后發現自己已領“盒飯”，即便來電是多么的理所當然，但心里必定是非常不痛快的，那么，如果來電以彈窗的形式且占據屏幕很小區域（如今的來電方式）是不是就給了用戶足夠反應時間及緩沖時間呢？
交互層面：彈出的內容及操作入口需清晰可操作，雖然有時基于業務需求，產品更希望用戶能進行下一步操作而并非回到上一步，即便如此，我們也只能通過弱化次要操作以突出主要操作，用戶有來去自由的權利，如果弱化至用戶看不清、甚至找不到的程度，即便提供了次要操作入口，也會存在反面作用；另外需注意用戶對產品的可控性，不管產品如何期望用戶進入下一步轉化，但不能強制，一定要給用戶提供回去的路（強制版本更新除外），否則，任性的用戶可能會直接結束應用，甚至因產品過于霸道直接卸載。
首先，設計師應該理解產品需求，分別從用戶側（能給用戶帶來什么？滿足什么樣的需求？避免什么損失?…）、產品側（能給產品帶來什么？產品如何期望？是否合理？能得到什么樣的結果？…）分析為什么要加彈窗，然后將分析的結果轉化為設計目標，以確保彈窗根據不同的需求，在恰當的時間、適合的樣式合理的呈現給用戶。
其次，在得到設計目標后，同樣需要從設計側、技術側思考彈窗組件的一致性。從設計角度，團隊所有成員需要對該組件有清晰且統一的認知，了解組件的使用場景，以確保不會錯用、濫用，如果增加或更換新人設計師，很容易學習和上手，提升效率；站在技術角度，一致性的常用彈窗組件，便于開發做組件封裝后續復用，減少不必要的重復工作，大大提高開發效率。
在UI設計中，組件的設計思路基本相通，旨在滿足產品的實用性、視覺的統一性，主要圍繞著以下幾點進行：
設計彈窗時需要注意信息的主次層級關系，優先傳達用戶想要的或產品想要讓用戶知道的，以確保重要的信息在第一時間傳達給用戶。
彈窗需要根據實際的場景合理使用，不能為了簡潔而過分刪減內容、更不能畫蛇添足。例如一些偏向于操作狀態、系統報告類的提示可以使用簡單的反饋，而可能造成用戶損失的提醒就需要刻意打斷用戶，給予更明確的提示甚至二次確認。
△ 例如刪除內容就需要使用模態彈窗明確提醒用戶，如果用非模態很可能被用戶忽略從而帶來不可逆的損失。
因彈窗本身承載內容有一定的局限性，固文案一定要簡潔且精確，能用一句話說清楚的就不要過于啰嗦，不僅容器的空間有限且用戶的耐性也有限，需要在有限的空間、有效的時間內清晰的表達出核心內容。
針對運營彈窗，如果彈出的時間不對或過于頻繁，可能會造成用戶反感，所以需要把握好彈出時機及頻率。
例如用戶有一張未使用的優惠券，如果用戶每次進入應用都看到彈出提醒，確實又沒有購買商品的意愿，總是被彈窗打斷真的就很煩，那么可以將提醒彈窗設置為每日首次進入應用時提示、每累計進入應用5次后提示、即將到期提示或者用戶有購買意愿且優惠券支持改品類時提示等，總之，需要控制在大部分用戶的可接受范圍內。
本篇文章主要系統的分析了彈窗組件分類及使用場景，總結的雖然不是很全面，但能讓很多新手設計師清楚認知彈出組件的定義及用法。另外，彈窗不管如何設計，都需要有一個不斷優化的過程，要根據產品的實際情況不斷思考與打磨，通過腦暴或已知問題作出更好的改善。
能清楚認知、理解、使用彈窗組件是一個成熟UI設計師必備的條件，當然，并不能以此定義設計師是否優秀，在此基礎上，還需通過持續的學習探索，挖掘出更多技巧，不斷提高自身的專業能力。
大漠飛鷹；公眾號：能量眼球，人人都是產品經理專欄作家。致力于產品需求的驅動、產品體驗的挖掘，利用設計的手段為受眾用戶帶來更好的體驗，即好看、好用。
本文原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基于 CC0 協議
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
