編輯導語：彈窗是吸引用戶注意力的一種方式，不管是PC端還是移動端都廣泛使用。本文作者從交互設計的角度，對彈窗進行分析，讨論了日常工作中深惡痛覺的常見問題，希望能給您帶來幫助。

在彈窗（上）篇，我們講完了彈窗的定義與應用場景，彈窗（中）篇說完了基本布局，那麼這篇内容，我們将讨論兩個日常工作中深惡痛絕的常見問題：連續彈彈窗、彈窗疊彈窗，本篇内容中提到的“彈窗”多指modal dialog模态對話框——畢竟99%的彈窗體驗問題都是模态對話框的問題。

一、信息彈窗的體驗問題

彈窗留給廣大群衆的印象很糟糕。即使不是交互設計師，聊起“彈窗”這個東西的時候，腦海中一下子蹦出來的第一印象都是PC時代鋪天蓋地、像電線杆子上小廣告一樣密密麻麻、層層疊疊的廣告彈窗。

假如你不小心點開了不該點的網站，或者安裝了“急速下載器”的客戶端，那開機後迎接你的就是十幾個按順序打開的彈窗、并且往往還附帶震耳欲聾的音樂——每個都需要你親自、純手工點掉。

廣告彈窗之所以成為體驗問題，也很好理解。即使不是專業設計師的人也能細數一二，比如19年這篇法治周末就列舉了廣告彈窗的三宗罪：

1. 推送頻率過于頻繁
2. 關閉按鈕過于隐蔽
3. 重疊的窗口影響正常網頁的浏覽

前兩個問題本篇不作讨論，主要是第三個問題很值得細究：之所以重疊的廣告彈窗很惡心，一定程度上是因為它讓低用戶價值、低優先級的内容（垃圾廣告）遮住了高優先級、高用戶價值的内容（用戶自己打開的頁面），并且除非用戶和彈窗進行交互，否則根本無法獲取自己感興趣的内容。

基于我們在從交互的角度講講彈窗（上）中的結論：彈窗是一種對注意力的引導形式，我們可以說，作為一種信息展示彈窗，彈窗堆疊導緻用戶的注意力被錯誤地強引導向了低價值的内容，并且關閉成本太高，因此這種設計手段不可取。

二、操作彈窗的體驗問題

既然連續彈信息彈窗的體驗問題部分在于遮擋了高價值的内容；那麼連續彈操作彈窗是否存在體驗問題呢？

畢竟操作彈窗都是用戶自己主動打開的，因此對于操作彈窗的内容多少是有預期的，甚至可以說操作彈窗上的内容都是存在用戶價值的，用戶為了完成某些操作，的确需要看到這些内容。

先說結論：在網頁端存在多種處理彈窗層級關系的方式，的确應該盡量避免模态操作彈窗的堆疊，但并不是完全不可接受。然後我們來細細的拆解操作彈窗的“連續彈窗”和信息展示彈窗的“連續彈窗”有什麼差異。

1. 彈窗的層級與任務的從屬關系

上文使用的例子是多個廣告彈窗連續彈出，各個廣告彈窗之間實際上沒有層級關系——沒有哪個廣告彈窗是另一個廣告彈窗的入口。

但操作彈窗卻很經常出現這樣的情況：想象你打開一張工資編輯表，新增/删除員工可以在頁面上進行，但是對每一個員工的工資/補貼做編輯，則需要進入下一級員工工資編輯彈窗進行操作。

那麼此時“工資編輯表頁面”和“員工工資編輯彈窗”就構成了頁面上的層級關系（或者父子級關系），而從目标與任務維度上來講，“編輯員工和工資”是用戶想要達到的總任務目标，“編輯某個具體員工的工資”是延伸出來的可選子任務。

用戶目标與任務之間的關系，映射到頁面上，也就形成了頁面、彈窗之間的從屬關系。

這個映射做得是否符合用戶的使用習慣，就看設計師的功力了。

比如大部分藝術創意類工作的目标都沒有那麼精确，所以任務也就經常是非線性的：用戶總是需要調整一下這個滑杆，不太滿意，然後又去調一下那個參數。

而不是像填表單、編輯表格那樣，打開頁面之前心裡就想好了：這裡要從0調成10，這個按鈕給它擰開，這個項目給它删了。

因此工具性産品或者創意生産類産品都采用工作台的模式，使用非模态彈窗或者幹脆不使用彈窗，從而允許用戶多線程、多維度地自由工作。

同理，設計師會把一般來說用戶不需要也沒辦法同時處理的、具有邏輯上從屬關系的任務，做成具有父子級關系、或者一定展示順序的頁面（或者彈窗），而不會把這些東西全部一起呈現給用戶。

交互設計師的其中一項基本工作是将頁面的信噪比維持在一定的區間内、提供給用戶他們當下需要的信息。假如一件事情沒那麼急迫，那麼就沒必要把它招呼到用戶面前。

2. 從屬關系的實現方式與問題

即然頁面/彈窗之間可以具有從屬關系，那麼我們如何在頁面中體現這種從屬關系？它們各自有什麼特征與問題？我這裡總結了3種常規的表現形态，我們一項一項地盤點它們各自的問題。

3. 操作彈窗的“彈窗疊彈窗”

“彈窗疊彈窗”，或者“父子級彈窗”是一種古老的交互形式，在PC應用程序設計場景下，所有的任務都在彈窗的前身——窗口或窗體（window）下完成，因此窗口相互重疊是不可避免的。

應用程序端的窗口重疊有兩種情況：物理上的重疊與層級上的重疊。

用戶在windows和mac或者其他操作系統上可以打開多個窗口，但用戶不可能同時和所有的窗口互動，因此窗口擁有的一項特性：當存在多個窗口時，隻有最頂層的窗口是正在與用戶互動的窗口，稱為“活動窗口/當前窗口 active window”。用戶的輸入焦點、鍵控都僅對當前活動窗口生效。

我們從這種設計中可以發現在窗口物理上有重疊的情況下，系統雖然允許用戶快速切換窗口，但事實上限制了每次和用戶交互的窗口。

同時，在桌面端上也允許存在從屬于某個主彈窗的次級彈窗。這種“次級彈窗”更類似于網頁端所講的“模态彈窗”，如果你不關閉它就無法與其父級彈窗交互，所以我把這種彈窗的重疊稱之為“層級上的重疊”。

雖然“彈窗疊彈窗”這種設計形式曆史悠久，但是問題也頗多。其中最明顯的兩個問題如下：

1. 彈窗層級過多，不容易找到可交互的活動窗口
2. 多層嵌套彈窗的生效模式比較反直覺，并且經常在網頁端被錯誤應用

第一個問題我相信大部分用過windows的人多少碰見過。windows的次級窗口（ owned window ）可以随意拖動，位置并不固定，而且部分windows版本中并不展示在底部欄taskbar上，所以有時并不容易一眼發現到底應該操作哪裡。

因此Mac改進了它的次級窗口樣式，使其緊貼父級窗口的标題欄，這樣窗口的從屬關系比較明确，一眼容易發現可操作的位置。

類似的問題在網頁端上也比較容易出現。當彈窗層級過多，而當前最頂層的模态彈窗容器又比較小時，頁面噪音就過多了。

這個時候用戶就要費好大的勁兒從一堆彈窗中找到最頂層那個的可交互彈窗，不說交互體驗如何，視覺上就不太簡潔，也就丢失了彈窗“引導用戶注意力”的基本價值。

第二個問題其實發生得很普遍。舉個例子，假如你現在在做一款人力資源管理系統，現在有一個“編輯員工角色”的彈窗長成這樣：

前端一看哎呀太好了，我們剛好之前做了一個“新增角色”彈窗，直接往這個“編輯員工角色”彈窗上一放就解決問題了，甚至還不打斷用戶的工作流，我看體驗非常好：

此時假如用戶點擊“确認新增”，就對輸入的字段進行校驗，沒問題了那麼角色就在後端保存上了。

此時回到上一級“編輯員工角色”彈窗，用戶立刻就能在“角色”下拉框中找到自己剛剛新增的角色，但美中不足的是假如用戶在“編輯員工角色”彈窗上點擊“取消”，那隻是取消了對員工角色的編輯，角色的新增操作已經生效了。好像沒什麼問題是吧？

然後我們舉第二個例子：假如我們作為HR正在新增一群員工，每個新員工可以有自己的花名和備注，但我們也可以現在不填，等以後再說。新增員工的彈窗長這樣：

假如花名和備注因為填寫頻率不太高，所以被放在了二級彈窗上，那麼：

現在點一下“确定”，前端校驗仍然可以做，但員工徐莉莉的花名和員工備注隻是在彈窗上暫存，除非用戶在“新增員工”彈窗上點一下“确認新增”，否則這批新員工的數據都不會提交後端保存（畢竟員工花名和備注大概率是和員工姓名存在一張表上的選填字段）。

上面兩個例子講到這裡不難發現，雖然它倆看起來長得一模一樣，但是數據的提交方式卻存在差異。當出現這種問題時，就非常難以簡潔地和用戶解釋為什麼類似的交互形式造成了截然不同的後果。

一般來講，我們做父子級彈窗 延遲生效模式時，（不清楚什麼叫延遲生效模式也請看前篇）采用第2個例子數據提交方式，即子級彈窗的數據僅作暫存，當父級彈窗提交時才一起生效；另外假如存在第1個例子的情況時，一般以導航的形式打開新的網頁窗口引導用戶前往“新增角色”模塊進行操作，而避免和第2個例子造成混淆。

但總體而言，應該盡量在網頁上避免操作彈窗疊操作彈窗的設計方式，并且完全杜絕2級以上操作彈窗的重疊，因為大部分用戶很難理解這其中的彎彎繞繞。

4. 流程彈窗/多級彈窗

流程彈窗的曆史和多級彈窗其實都是在同一個彈窗容器上做内容的變化，它倆的差異是：

• 流程彈窗有步驟上的順序（上一步、下一步），并且一般與延遲生效模式搭配，在最後一步統一提交信息。
• 多級彈窗沒有步驟上的順序，且往往與即時生效模式搭配（盡量避免與延遲生效模式搭配，否則會存在與彈窗疊彈窗一樣的問題）

不管你用哪一種彈窗類型，注意彈窗隻有一個容器，因此右上角的“X”是對流程/多級彈窗起全局作用的關閉按鈕。近年來B端/工具型産品的形态愈發複雜，多級彈窗也變成了一個比較常規的設計方式，建議大家花點時間搞搞清楚。

比如說飛書的【分享】功能，就有這麼一個非模态的、介于context menu和dialog之間的東西，也符合我們【層級高于頁面、容器是方形】的彈窗定義。

5. 連續彈窗

一般不存在多個不同的操作彈窗銜接在一起，但是因為種種原因，連續給用戶彈多個反饋/再确認彈窗還是挺常見的。我們在這裡就簡短地帶過一下這種情況。總體而言，我把連續彈反饋彈窗分成兩種類型：

把用戶當大傻子型：意圖用多重再确認來阻止用戶進行一件事情（一般是卸載軟件），我們都知道這體驗很差，假如用戶體驗并不是你的産品主要的考量點，那麼當我沒說。

絕大部分的場景下，合理設置再确認彈窗能夠避免99%的誤觸，雖然亦有意見表示用戶可能日常關閉各種彈窗已經形成了肌肉記憶，隻有一次的再确認彈窗可能順手就被關閉了，可能并沒有起到防錯的作用。

所以極少數誤觸造成問題比較嚴重的場景下，可以用輸入文字等方式提高再确認彈窗的操作成本，但絕大多數産品的絕大多數場景隻需要1個常規的再确認彈窗就夠了。

産品各幹各的型：當一個模塊有多個産品經理負責時很容易出現這種情況，每個産品都提出了自己的再确認措施，并且各調各的接口，每個彈窗的觸發規則都有點差别。

那麼這種情況就需要交互去協調同一個産品的不同再确認彈窗彈出邏輯，盡量把這些彈窗的重點信息整合在一個彈窗上，并且優先展示阻斷性的問題，建議、不那麼急迫的事情優先級适當往後調。

到這裡彈窗篇徹底寫完了，非常感謝大家的支持。

本文由 @白話說交互 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自unsplash，基于 CC0 協議

,

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

查看全部