彈窗到底該不該加？怎么加？用什么形態展示？真正的作用是什么？這些真的是產品經理說了算嗎？
好的產品通常會在恰當的時間、合適的位置給出合理的反饋，彈窗也是必不可少的反饋方式，不反饋、反饋不及時或反饋不合理都會帶來不好的使用體驗，甚至誤導用戶，從而導致用戶流失。很多時候，產品經理會從商業角度、公司業務、資源限制等方面考慮問題，但這些未必是用戶所需要的，設計師不應該完全按照產品需求做設計，否則就成了只會照搬產品原型的“美工”。需要做的是從用戶角度出發，把產品需求轉化成設計目標，只有經過反復的推敲、認真分析，最終才能打磨出服務于用戶的彈窗設計，所以彈窗該不該加、如何加就成了設計師不可推卸的責任和使命。
本篇文章將圍繞著彈窗類型、使用場景、轉化率及常見問題為側重點，將自己對彈窗的理解、設計經驗分享給大家，幫助大家對彈窗組件有更清晰的認識，為后續避坑設計出更好的彈窗做準備。
本期大綱
一、彈窗的基本介紹
二、彈窗體系分類
三、彈窗的使用場景
四、如何設計有效的彈窗
五、需關注的問題點
六、總結
一、彈窗的基本介紹
1 彈窗的定義
當我們與應用產生主動或被動交互時，頁面上層會彈出容器，將可承載的文本、按鈕、選項、標簽或表單等任一內容與之組合，就可以用來傳遞信息、狀態反饋、引導用戶等操作，這就是彈窗。
彈窗的目的主要是為回應用戶或讓用戶回應，是用戶與產品間對話的一種方式，在線上各種場景中都有可能碰到，相當于產品的線上小助理。不同類型的彈窗其作用不同，但最終都是為了滿足跟用戶之間的友好交流。
2 彈窗組件的構成
彈窗組件的樣式很多，如浮層、對話框、下拉菜單、toast等，且iOS、Android官方平臺也都根據自身的規范對組件進行命名，不管如何稱呼，其常見的彈窗組件絕大多數都是由以下元素組成：
◇ 容器：作為承載彈窗的文本、圖片等內容，容器必不可少，有的彈窗直接以蒙層作為容器，如toast；
◇ 蒙層：為了和底層內容分離，避免信息混淆，通常會在界面上層（容器下層）設置一個不透明度為20%~60%
的純黑色蒙層。部分小型彈窗不設蒙層，但會為容器設置投影，例如篩選器的展開、下拉菜單等；
◇ 文本：文本是彈窗傳達信息主體的必要條件，如標題、按鈕等，即便把文本融入圖片，也能一目了然；
◇ 圖片：用于運營彈窗傳達更多信息內容的方式之一，為了對用戶產生更強的吸引力，還可設計成動態效果；
◇ 表單：為成功進入下一步做準備，如輸入密碼（iOS設備下載應用前的必要步驟）。也可以是當前頁面流程的分支，例如輸入優惠券等；
◇ 選項：條件較少的選項可使用彈窗完成，單選、復選在選項不超過6個的情況下都可使用；
◇ 圖標：在弱化次要操作的情況下，通常會將關閉彈窗按鈕設計成圖標放在右上角或彈窗下方，目的是突出主操作，鼓勵用戶從彈窗中進入下一步，另外還有單選、復選、提示等按鈕；
◇ 按鈕：是進入下一步或回到上一步（去掉彈窗）的操作入口，部分應用也可以點擊彈窗以外的空白區域讓彈窗消失，但同樣會提供按鈕以方便用戶更容易操作。toast等短時間自動消失的彈窗無需設置按鈕。
二、彈窗體系分類
1 模態彈窗
用戶在完成任務的過程中，界面會出現彈窗打斷用戶的操作行為，用戶必須通過主動點擊才可以進行下一步操作，這即是模態彈窗。
模態彈窗通常能較好的獲取用戶的視覺焦點，并通過承載的內容、按鈕主次層級來引導用戶完成他們的需求，這也會根據用戶、產品側重點的不同，彈出樣式也有所不同，常見的模態彈窗有對話框、動作欄、浮層...等。
1.1 對話框Dialog/Alert
對話框是很常見的彈窗，主要在打斷用戶后并提供選項操作，對用戶的干擾較大，通常會配備1~3個操作按鈕，而且會把用戶最期待的或產品最期待用戶操作的按鈕突出顯示。
對話框類型的彈窗主要分為主動、被動兩種觸發類型，主動彈窗：信息的二次確認、輸入內容、前置條件選擇、風險警示等；被動彈窗：版本更新、運營宣傳、消息通知、系統功能授權等。
1.2 動作欄Actionbar
動作欄是通過用戶主動操作后彈出的內容信息，基本都是從底部彈出，屏幕占用比例根據內容量的多少比較隨意，從小區域、半屏、再到全屏隨處可見。
動作欄相比對話框則能承載更多、更豐富的功能信息，在用戶清晰感知當前操作及反饋的情況下，比跳轉到新的頁面更有安全感。
1.3 浮層Popover/Popup
浮層是指用戶操作某個功能/內容后，會在附近出現一個帶有視覺引導性質的彈窗，最常見的浮層就是下拉菜單/彈窗等，浮動于頂層窗口并指向觸發操作的位置。
例如很多社交娛樂類型的應用右上角有一個“+”入口，里面會放置部分常用功能。部分浮層底部沒有設置不透明度的蒙層，為了與頁面信息更好的區分，會給浮層容器加上投影，避免與底部信息混淆。
2 非模態彈窗
相比模態彈窗，非模態彈窗屬較為輕量，觸發后以一種非阻礙的的方式呈現，不會打斷用戶的當前操作，主要是給予用戶即時反饋，讓用戶清楚應用當前的交互后狀態。非模態彈窗不強制用戶操作，根據反饋信息的重要程度及意愿，可在一定的時間內自動消失，也可等待用戶操作后消失，常見的有以下幾種：
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是一種在透明元素上通過填充、反饋用戶當前交互操作的指示層，實時生效，例如視頻類產品中的調整音量、亮度、控制進度條等。
三、彈窗的使用場景
當我們對彈窗體系有了一定了解后，就需要清楚什么場景需要設計彈窗？用什么類型的彈窗？產品最終都是服務于用戶，如果僅憑自己的主觀意見亂加一通，整的花里胡哨，彈窗就成了干擾元素，很大程度上會影響用戶體驗。什么樣的場景適合什么類型的彈窗，我們可以從以下幾點來說明。
1 打斷用戶的操作
風險警示：當用戶的某種操作可能存在風險，為避免操作失誤，會彈出對話框打斷用戶，并給予一定的風險提示引起用戶的注意，讓其有足夠的時間確認是否真的需要進行下一步操作，如：刪除、放棄福利機會、退出登錄等，會彈出對話框提示操作后可能引起的后果。
前置條件：部分任務在流程中設有一定的前置條件，需要滿足條件才能進入下一步操作，通常這種情況會根據內容量的多少、重要程度以對話框或動作欄的樣式彈出，例如下單時選擇優惠券、支付方式。
任務關鍵節點：用戶在滿足任務的基本條件后，需要操作一個關鍵步驟才能成功，則會彈出對話框讓用戶完成最后一步操作，例如提交訂單、表單、輸入支付密碼等。
2 定制化彈窗
這類彈窗主要從產品角度出發，不會過于在乎用戶是否需要、會不會反感，都會引導或強制用戶操作。
例如產品發布新版本，會強制用戶更新，否則將無法使用。還有各大電商APP，在進入首頁時會彈出一堆紅包、優惠券，刻意將取消/關閉入口弱化，給用戶返回造成一定的難度，利用突出的視覺、動態效果突出主題增加吸引力，以達到轉化用戶的目的。
3 二次確認
二次確認也是一種打斷用戶的操作行為，但跟上面純粹的打斷用戶相比其作用更大，主要是在用戶已做好選擇的情況下再次彈出確認，以免操作結果造成用戶認知上的偏差。雖然從用戶體驗角度出發，用最少的操作、最簡單的流程滿足用戶所需是產品追求的目標之一，但通過權和利弊之后，二次確認的出現實屬迫不得已的折中方案，它能夠起到給用戶多一次思考避免誤操作、同樣的含義換種方式表達、重要的內容加深二次記憶等作用。
二次確認使用得當，可以避免用戶、產品的潛在風險，但若是從主觀角度一味的濫用，就成了對用戶的惡意干擾、影響使用體驗，導致出現因多步驟操作增加任務完成難度、降低轉化率、損害產品形象等問題，所以需要從業務（用戶側、產品側）實際角度出發，兩相其害（加-影響使用體驗；不加-造成一定損失）取其輕的考慮是否需要增加二次確認彈窗。
當用戶的某個操作可能帶來不可逆轉、錯誤嚴重程度較高時，例如：放棄僅有一次機會的較好福利、手機系統還原、應用賬號注銷等，系統都會給予二次確認，降低用戶認知偏差后，以確保用戶是經過多次思考才做出的決定，即便后續給用戶造成損失也不會過于降罪產品，產品也算是“問心無愧”了。
4 簡單提示
常見于用戶操作之后的狀態反饋，即便用戶沒有注意到，也不會造成較大的損失、或結果已經注定，相對來說成本較低，大部分出現在任務過程中的提示（可重復）和結果反饋，以確保用戶知曉當前所處狀態。
非模態彈窗toas樣式居多，例如加載中、操作成功、刷新結果、清除緩存等，可出現在其他類型的彈窗之后或同時存在。
四、如何設計有效的彈窗
1 前提條件
優秀的彈窗需要從視覺、交互兩方面思考，視覺上簡潔、易懂，交互上可操作且可控。
視覺層面：首先需要做到的是易懂，這時候就非常注重文案清晰程度及按鈕層級關系了，彈出的信息需能直擊要害，用戶看了能一目了然才是關鍵；其次，彈窗屬于一種干擾信息的存在，設計必須簡潔，在彈出時需要考慮是否會過度影響（影響是一定會有的、且看如何降低）用戶的其他操作。假想我們正在玩游戲、突然來了電話全屏幕覆蓋（傳統來電），自己會以最快的速度掛掉電話，回到游戲中后發現自己已領“盒飯”，即便來電是多么的理所當然，但心里必定是非常不痛快的，那么，如果來電以彈窗的形式且占據屏幕很小區域（如今的來電方式）是不是就給了用戶足夠反應時間及緩沖時間呢？
交互層面：彈出的內容及操作入口需清晰可操作，雖然有時基于業務需求，產品更希望用戶能進行下一步操作而并非回到上一步，即便如此，我們也只能通過弱化次要操作以突出主要操作，用戶有來去自由的權利，如果弱化至用戶看不清、甚至找不到的程度，即便提供了次要操作入口，也會存在反面作用；另外需注意用戶對產品的可控性，不管產品如何期望用戶進入下一步轉化，但不能強制，一定要給用戶提供回去的路（強制版本更新除外），否則，任性的用戶可能會直接結束應用，甚至因產品過于霸道直接卸載。
2 設計目的
首先，設計師應該理解產品需求，分別從用戶側（能給用戶帶來什么？滿足什么樣的需求？避免什么損失?...）、產品側（能給產品帶來什么？產品如何期望？是否合理？能得到什么樣的結果？...）分析為什么要加彈窗，然后將分析的結果轉化為設計目標，以確保彈窗根據不同的需求，在恰當的時間、適合的樣式合理的呈現給用戶。
其次，在得到設計目標后，同樣需要從設計側、技術側思考彈窗組件的一致性。從設計角度，團隊所有成員需要對該組件有清晰且統一的認知，了解組件的使用場景，以確保不會錯用、濫用，如果增加或更換新人設計師，很容易學習和上手，提升效率；站在技術角度，一致性的常用彈窗組件，便于開發做組件封裝后續復用，減少不必要的重復工作，大大提高開發效率。
3 設計思路
在UI設計中，組件的設計思路基本相通，旨在滿足產品的實用性、視覺的統一性，主要圍繞著以下幾點進行：
◇ 基礎定義：利用清晰易懂且簡短的文案描述彈窗組件的內容及目的。
◇ 類型及構成：明確彈窗的類型，如模態/非模態，將其拆分并注明每個小元素的具體信息。
◇ 規則用法：彈窗出現的位置、包含的具體內容及信息的展示規則，比如哪些場景可復用。
◇ 交互狀態：交互流程邏輯清晰，擬請產品交互前、交互中、交互后如何反饋以及用戶隨時可能碰到的問題。
五、需關注的問題點
1 信息的層級關系
設計彈窗時需要注意信息的主次層級關系，優先傳達用戶想要的或產品想要讓用戶知道的，以確保重要的信息在第一時間傳達給用戶。
2 展現形式
彈窗需要根據實際的場景合理使用，不能為了簡潔而過分刪減內容、更不能畫蛇添足。例如一些偏向于操作狀態、系統報告類的提示可以使用簡單的反饋，而可能造成用戶損失的提醒就需要刻意打斷用戶，給予更明確的提示甚至二次確認。
△ 例如刪除內容就需要使用模態彈窗明確提醒用戶，如果用非模態很可能被用戶忽略從而帶來不可逆的損失。
3 文案表述
因彈窗本身承載內容有一定的局限性，固文案一定要簡潔且精確，能用一句話說清楚的就不要過于啰嗦，不僅容器的空間有限且用戶的耐性也有限，需要在有限的空間、有效的時間內清晰的表達出核心內容。
4 彈出的時機及頻率
針對運營彈窗，如果彈出的時間不對或過于頻繁，可能會造成用戶反感，所以需要把握好彈出時機及頻率。
例如用戶有一張未使用的優惠券，如果用戶每次進入應用都看到彈出提醒，確實又沒有購買商品的意愿，總是被彈窗打斷真的就很煩，那么可以將提醒彈窗設置為每日首次進入應用時提示、每累計進入應用5次后提示、即將到期提示或者用戶有購買意愿且優惠券支持改品類時提示等，總之，需要控制在大部分用戶的可接受范圍內。
六、總結
本篇文章主要系統的分析了彈窗組件分類及使用場景，總結的雖然不是很全面，但能讓很多新手設計師清楚認知彈出組件的定義及用法。另外，彈窗不管如何設計，都需要有一個不斷優化的過程，要根據產品的實際情況不斷思考與打磨，通過腦暴或已知問題作出更好的改善。
能清楚認知、理解、使用彈窗組件是一個成熟UI設計師必備的條件，當然，并不能以此定義設計師是否優秀，在此基礎上，還需通過持續的學習探索，挖掘出更多技巧，不斷提高自身的專業能力。
文章來源：站酷 作者：大漠飛鷹JYSJ
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設
