上文為大家介紹了平臺規範中的彈框類型，那麼我們又該如何判斷在哪些場景中需要用彈框？需要的話又需要哪種類型的彈框？針對這些疑問，筆者將展開進一步分析。
上一期我們講解了平臺規範中模態、非模態框的類型以及它們的使用方法。可回顧：《掌握「彈窗」設計規範，打造優質用戶體驗》。
可知道了平臺規範中的彈框類型之後，你小小的腦袋瓜裡有了大大的問號：了解得越全面，反而無從抉擇了…這下該怎麼辦？
所以這一期我們來講一下彈框的正確打開方式。最重要的還是，在每一次控制項進階專題中，我們都要學會透過表面，探索它們背後值得我們學習的設計策略。
一、你確定你需要這個彈框嗎？
在講解如何正確使用彈框之前，我想讓你先思考一個問題：你真的需要這個彈框嗎？
有時候當我們知道了一個控制項為什麼被定義出來，我們就會掉進慣性思維的陷阱當中。比如我們知道了彈框一般用於承載拓展、提示和反饋信息，我們總是會在這些場景下，不假思索地使用它。
但實際上，彈框的使用場景其實是很值得推敲的。在帶大家了解彈框的「How（怎麼用）」、「What（用什麼）」之前，我們應該先明確「Why（為什麼用）」。
先說一說產品層面的「Why」吧。
說到微信「好看」功能，喜歡閱讀公眾號的朋友一定不會陌生（現已根據戰略將「好看」改為了「在看」）。「好看」功能的誕生初衷是微信為了突破公眾號閱讀量下降的瓶頸，讓優質內容依靠閱讀者自身社交體系，擴散給更多的用戶。
最初微信剛推出公眾號「好看」功能時，用戶點擊「好看」後，會彈出一個 Popovers ，引導用戶記錄下想法，並分享至「看一看」。其好友通過「看一看」這個公共區域，可以了解到最近有哪些不錯的公眾號內容。該功能既可以讓用戶以文會友加深粘性，又可以依賴用戶主動分享的意願，給公眾號輸入更多的流量。
一開始出於新鮮感，「好看」功能吸引了許多用戶使用。但後來願意點擊「好看」的用戶越來越少，其中當然有許多因素，但微信團隊認為：點擊「好看」之後彈出讓用戶記錄想法的 Povpovers 增加了用戶的行為路徑長度，並且給一些不願意記錄想法的用戶帶來了行為負擔，導致越來越多的讀者不願意再點擊「好看」。
於是這個 Popovers 成為了一個和產品目標格格不入的控制項。在微信後續的迭代中，終於還是在保留「寫想法」的功能基礎上，替換了這個氣泡框。
但產品層面可能更多是PM去考慮的問題。那對於設計師，我們說一說交互層面。
我們前面說到，彈框的作用之一就是給用戶帶來行為反饋，反饋有利於搭建用戶使用產品過程中的信心。但即便是為了不幹擾到用戶，將反饋機制儘量以非模態框的形式呈現，依然會增加用戶認知成本，因為人類認知模型都是從學習到理解再到習慣。
所以在我們設計反饋機制時，有時候可以跳出「使用彈框」的設定，「彈框」僅僅是人類五感中「視覺」這一個層面，我們還可以通過「聽覺」和「觸覺」來傳遞用戶反饋。
例如現在有許多APP在用戶發生文本框輸入錯誤時，會採用文本框晃動+設備震動等觸覺反饋。這些交互反饋的含義已經讓用戶形成思維習慣，在不用閱讀理解文字信息的情況下也知道這是一種錯誤提示。並且可以讓產品交互變得更加生動。
所以當你發現你的產品設計中，真的已經有很多彈框的時候，記得問一問自己：我真的需要這個彈框嗎？已經沒有更好的替代方案了嗎？
二、確定要用模態框嗎？
解決了「Why（為什麼用）」的問題之後，如果你確定當前流程真的需要用到彈框，我們就要來探究「How（怎麼用）」的問題了。
上一期文章我們講到：模態框比非模態框更容易打斷用戶心流，所以如果不是關係到危險操作，我們應該儘量選擇更輕量的非模態框。但憑藉我多年使用產品的經驗，發現並非模態框的運用場景就一定是承載危險信息，所以如果以這個標準去判斷應該選擇哪一類彈框，稍微有些以偏概全了。
那麼我們該如何在模態框與非模態框之間做選擇呢？我總結了一個分析手法。
我調研了許多應用的彈框，發現選擇使用模態框還是非模態框可以由以下三個維度依次進行判斷：
1. 是否含有交互類操作
因為非模態框時間短、會自動消失的特質，讓它在大多數時候都是被用於承載用戶操作的反饋提示，例如「收藏成功」、「提交成功」等，而無法包含操作項（SnakeBars 除外）。所以「是否含有交互類操作」成為了影響決策的第一維度。
當你的彈框中包含交互操作項，用戶通過點擊這個操作項會引發下一步交互（如：刪除、提交、跳轉頁面等），那不用猶豫，直接上模態框吧。
那如果彈框中不包含交互類操作，是否就能直接用非模態框呢？那得看接下來的第二個維度。
2. 是否有較高的重要級別
正是因為模態框必需由用戶手動關閉的原因，往往可以用於承載重要信息，獲取用戶注意力。所以就算彈框中並不包含交互操作項，但因為提示內容非常重要（如：隱私協議、危險操作信息、版本更新信息等），也應該使用模態框來呈現。
3. 是否包含大量文字
能走到第三維度的彈框，一定是既不需要交互操作，也不太重要的彈框了。那逼迫著我們邁出最後一步來決定是否使用模態框的判斷條件，就是簡單粗暴的「文字量」了。
由非模態框在平臺規範中的定義就可以看出，Toast的最長時間業界定義為3.5秒，太長的文本信息用戶根本無法完成閱讀。即便是可以停留4-10秒的SnakeBars ，Material Design 也明確告訴了設計者，請不要在 SnakeBars 中放置過長的文本內容。
如果以上三個維度我們的答案都是「否」，那請用非模態框吧，大多數情況下都不會有錯的。
三、你到底該用哪一個彈框？
選定了是使用模態框與非模態框之後，你終於可以思考「What（用什麼）」了。
1. 模態框是用「Alert」還是「Action Sheet」
對於模態框，最容易產生糾結的主要是 Alert 與 Action Sheet 。在抉擇具體使用哪一個控制項之前，只需要弄明白它們的兩大區別即可：
操作項數量區別：iOS人機互動規範規定，為了避免 Alert 選項溢出可視區域，讓用戶產生滑動行為，應最多承載三個選項，但 Action Sheet 可以承載更多；位置區別：Alert 出現在屏幕中心，但 Action Sheet 由屏幕底部向上滑出。對於操作項數量區別，很容易理解。多餘三個操作項的模態框，我們理應使用更符合操作體驗的 Action Sheet。
但對於位置區別，我們該如何加以運用呢？
來看看網易雲音樂的案例。當用戶在批量刪除已下載音樂時，用戶點擊了底部的「刪除下載」按鈕，會彈出以 Action Sheet 形式出現的確認刪除框。
你可能產生疑問：這個確認刪除框包含的操作項數量小於三個，但為什麼網易雲音樂不使用 Alert 呢？
這是一個非常典型的費茨定律案例（篇幅原因，費茨定律在以後的文章中再詳解，有興趣可以先自行查閱資料。費茨定律其中一條定律法則是：當目標大小一定時，起點離目標中心的距離越近，所花費的時間越短；距離越遠，所花時間越長。）
通過 Alert 與 Action Sheet 的出現位置，結合費茨定律，我們可以設計出更符合用戶體驗的設計。
2. 非模態框是用「Toast」還是「SnakeBars」
SnakeBars 當初由 Material Design 創造出來，就是為了解決用戶無法在非模態框中進行交互操作的問題。所以選擇它們的手法不言而喻。但 SnakeBars 在 iOS 端被運用的次數確實太少了，很多時候容易被設計者以相對輕量的模態 Popovers 取代。
所以我認為非模態框的選擇相對自由，只是考慮到產品的統一性，需要在設計規範中將非模態框的樣式、彈出位置等信息定義清楚，以免在類似場景中出現不同的彈框樣式，容易讓用戶產生疑惑。
四、當然，你也可以讓彈框更加情感化
平臺規範下的彈框大多不會考慮情感化設計，因為系統原生的控制項可能被任何應用在任何場景下調用。冷冰冰的彈框往往只是單純為了引導用戶操作、給予用戶反饋，頻率過高就容易讓用戶厭煩。
所以許多應用開始對死板的彈框進行情感化改良。
情感化彈框一般會出現在可能讓用戶產生敏感情緒的場景中。例如產品需要獲取到用戶提醒、訪問等權限，或出於商業考慮需要進行廣告營銷，容易讓用戶產生牴觸情緒時，許多產品會藉助情感化彈框為這一類場景脫敏。
並且為了增加用戶共情，許多APP也會用情感化彈框鼓勵、讚揚他們的用戶或者用於增加節日氛圍，讓用戶在使用產品的過程中更加愉悅。
通過增加動效也可以讓彈框更加生動，現在也已經有許多前端框架中預設了多種類的彈框動畫效果。
這些情感化設計策略，可以在彈框打擾用戶心流時的，給予用戶一些情感彌補。
五、總結
好像很多時候設計師都很牴觸彈框，但是出於各種原因又不得不用到它，使得「彈框」在眾多的控制項中有著很尷尬的地位。
但希望這一期的內容能夠幫助你在今後設計彈框的過程中變得更加得心應手，堅定而明確地選擇彈框控制項，也還彈框一個清白。
要知道，彈框在輔助用戶完整完成任務的過程中，其實是功不可沒的。
本文由 @Howie_t 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議