編輯導讀：我們經常會收到各種彈窗，它們的目的主要是為回應用戶或讓用戶回應，是用戶與産品間對話的一種方式。但是，彈窗也不是多多益善。如何彈、什麼時候彈？這些都是有章法的。本文作者總結梳理了一套彈窗設計原則，一起來看看吧。

産品經理：我覺得這裡要加個彈窗，你去設計吧。

設計師：emmm…

彈窗到底該不該加？怎麼加？用什麼形态展示？真正的作用是什麼？這些真的是産品經理說了算嗎？

好的産品通常會在恰當的時間、合适的位置給出合理的反饋，彈窗也是必不可少的反饋方式，不反饋、反饋不及時或反饋不合理都會帶來不好的使用體驗，甚至誤導用戶，從而導緻用戶流失。

很多時候，産品經理會從商業角度、公司業務、資源限制等方面考慮問題，但這些未必是用戶所需要的，設計師不應該完全按照産品需求做設計，否則就成了隻會照搬産品原型的“美工”。需要做的是從用戶角度出發，把産品需求轉化成設計目标，隻有經過反複的推敲、認真分析，最終才能打磨出服務于用戶的彈窗設計，所以彈窗該不該加、如何加就成了設計師不可推卸的責任和使命。

本篇文章将圍繞着彈窗類型、使用場景、轉化率及常見問題為側重點，将自己對彈窗的理解、設計經驗分享給大家，幫助大家對彈窗組件有更清晰的認識，為後續避坑設計出更好的彈窗做準備。

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設計師必備的條件，當然，并不能以此定義設計師是否優秀，在此基礎上，還需通過持續的學習探索，挖掘出更多技巧，不斷提高自身的專業能力。

#專欄作家#

大漠飛鷹；公衆号：能量眼球，人人都是産品經理專欄作家。緻力于産品需求的驅動、産品體驗的挖掘，利用設計的手段為受衆用戶帶來更好的體驗，即好看、好用。

本文原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!