編輯導讀：彈窗是吸引注意力的一種方式，不管是PC端還是移動端都廣泛使用。本文作者從互動設計的角度，對彈窗進行分析，與你分享。

上期我們小聊了一下彈窗的定義與使用的常見場景，本期我們來聊點實際的：彈窗的內容佈局，本來本期想把常見的兩種彈窗問題：彈窗的從屬關係（彈窗疊彈窗）、彈窗的流程關係（連續彈窗）都講一遍，但寫完基本佈局以後發現字數超了，所以彈窗這個話題從2期變成3期了。

一、彈窗的基本佈局

以車為例，假如我們把“車”這種物體身上的零部件分成兩種：一種叫基本零件、另一種叫附件。基本零件（比如發動機）是所有車都必須要有的、沒有它車就開不起來，甚至就不能叫車。而附件（比如座椅、天窗），這些東西可有可無，每一樣車的配置可能都不太一樣。比如車裝上鏟子就是剷車，裝上車箱就是貨車。

在做規範時，做控制元件的邏輯和組裝車是很類似的：控制元件的內容佈局也有基本零件和附件。基本零件的差異決定了不同彈窗型別（這種差異是比較大的、場景性的差異）；而附件的差異則決定了同類型彈窗的擴充套件性（也就是你定義的這型別彈窗，極限狀態下最多能支撐什麼樣的場景）。

按上一篇文章從互動的角度講講彈窗（上）來講，觸達、資訊展示、操作彈窗各自的基本零件可以畫成這樣：

△也沒多難

畫成這樣了以後我們可以發現，就算是支援複雜場景的大彈窗，其實骨架結構也是簡單的。以JIRA這個操作彈窗為例：

△jira真的很愛大彈窗

接下來我們就按照彈窗的基本框架佈局來一項項地拆解彈窗的基本零件與常見附件，複雜問題展開講，簡單問題就簡單過：

相對簡單的

：容器、標題、關閉方式

比較複雜的

：內容區、主操作按鈕

附件

：“不再提醒”

二、彈窗的容器

容器也就是彈窗尺寸，雖然在做規範的時候彈窗尺寸一般是UI去定義的，但作為互動我們也需要思考一些事情：

彈窗的尺寸需要和內容適配

。正常情況下，彈窗應該是不需要縱向滾動的（當然橫向滾動就更應該避免了）。假如你的彈窗尺寸需要滾動一下才能展示全資訊，應該先考慮它是不是過小。

大彈窗和全頁面、不同尺寸彈窗之間，應該有

明確的界限

。互動需要去界定什麼樣的資訊量是彈窗容納的極限，超過這個“極限”那麼彈窗這種控制元件就無法承載、需要使用其他的展示形式。

三、彈窗的標題

彈窗必有標題，能不能寫清楚彈窗標題，算是區分合格互動設計師與還差點意思的互動設計師的試金石。其實這事情說複雜也不復雜，只有2個事情需要注意：

（1）假如這個彈窗是由使用者主動觸發的，那麼彈窗標題應該與使用者觸發彈窗的操作按鈕

同名，或者至少有相同的關鍵字

。此時彈窗是使用者操作後的反饋，使用者需要透過彈窗的標題來確認自己是否進入了正確的模組、進行了正確的操作。

（2）彈窗標題與內容區說明文字要

各有分工

。一般來講，彈窗標題簡單陳述問題、詢問行為或者作出行為建議。內容區的說明文字展開來解釋出現問題的原因，以及操作後的後果。

當然文案，或者更時髦的說法：UX writing，是一門很大的學問，甚至可以支撐起一個職位。所以這裡講的兩條規則只是最為基礎的原則，不能涵蓋所有的文案要求（比如你要是做國際化，那麼標題和正文的首字母大小寫、加句號不加句號都需要考慮）。另外，B端的文案規範有時候也無法推廣向C端營銷類設計，因此本篇暫時不做更多討論。

四、彈窗的關閉方式

我之前寫了一整篇文章來說明彈窗的關閉方式：【PC設計】彈窗為什麼需要兩個關閉按鈕？，總體而言：

作為一個非常底層的控制元件，彈窗（或者說窗體）應該兼顧大部分使用者的不同習慣，來保持整個系統有比較好的可用性。因此，

建議在右上角新增“x”作為關閉操作性彈窗的最短路徑

，並且佐以鍵控、點選遮罩等多種關閉方式；除非要求使用者明確表態（比如要求同意協議）

當然，更便捷的關閉方式代表著更多的誤觸，如何平衡可用性和誤觸，就要根據具體場景具體分析了。

五、內容區與主操作按鈕

這兩個東西不能分開來講，它們是彈窗設計裡最複雜、最經常出體驗問題的部分。理解了內容區與主操作的關係，才能真正理解彈窗的設計。

1. 內容區與操作的層級關係

做B端產品時，設計系統的穩定是非常重要的一件事。構成設計系統穩定的重要因素之一，就是控制元件的操作模式的穩定和一致性。這個部分屬於設計中比較難以量化驗證的地方，就算做得很好，也可能並不能從業務資料上找到特別正向的反饋；但要是做得不好，整個設計系統（至少是互動系統）的邏輯會很快地被複雜的業務摧毀崩潰。設計系統一旦不能自圓其說，那就沒有系統可言了。因此為了避免這種情況，做互動還是需要定義一下控制元件的基本層級關係和邏輯。

彈窗的底欄層級高於內容區

：底部操作欄上的主操作按鈕承載著全域性操作，它的行為對彈窗整體生效、可能會導致彈窗關閉；而內容區的操作只對內容區生效，並不會導致彈窗關閉。這意味著做互動的時候，需要在樣式上為全域性按鈕、內容區按鈕作出區分，以免使用者產生困惑。

比如說假如我們是一箇中學老師，現在正在新增一個班級列表，班級列表裡有所有同學的名字：

到此為止內容區與操作的關係都還是清晰的，但一旦我們為彈窗加入導航控制元件——tab，那有些人可能就搞不清楚了。

首先我們在做彈窗的時候，

要儘量降低彈窗的層級結構和內容複雜度

，儘量把使用者完成任務的關鍵資訊一開始就展示出來，避免使用者在彈窗裡四處探索。但假如說因為任務的因素非得在彈窗上加tab的話，還是需要記住：屬於彈窗內容區的tab的層級低於彈窗操作區。

在windows/mac的應用程式中，這個問題可以被官方規範提供的group box元件解決——可以理解為把內容區從彈窗上“框”了起來，在視覺上創造出內容區和操作按鈕之間的層級差異。但是由於當前網際網路整體的設計趨勢傾向於減少層級、扁平化，所以在日常做設計時往往不再能使用這種視覺上的處理方式，只能做互動的人自己心裡清楚。

還是以新增班級為例，假如存在一個按鈕讓我們按一下就能上傳班級列表的excel，但是excel裡有些名字可以讀取出來，有些名字包含特殊符號（比如，、…），需要人為修改一下，那麼這個彈窗也許就會這麼做：

這個時候跳轉到到“讀取失敗”tab，底部欄的主按鈕仍然存在——即使你可以給表單設定一些提交限制，要求讀取失敗的專案沒有被手動修改的時候，不允許點選“新增”按鈕。

反過來說，正因為彈窗的操作區層級比內容區高，並且tab是一個導航控制元件而非選擇控制元件，因此tab+彈窗的潛臺詞是

“點選操作按鈕後，所有tab中的內容都會被提交，即使有些內容當前沒有展示出來”

，而不是“只有選中的tab會生效”。因此，假如你需要讓使用者在彈窗上作出選擇，就不要使用tab等導航控制元件，而可以選擇單選框/多選框這種典型的選擇控制元件（或者蘋果的segemented control這樣有點像導航的選擇器）。

比如說我們在新增班級彈窗上給使用者提供了兩個功能：手動新增或批次新增兩者的內容區樣式不一樣，那麼畫出來則是：

值得注意的是，這個層級關係只能應用在彈窗上，在網頁全頁面上往往存在層級高於操作按鈕的全域性導航。

2. 內容區與操作的對映關係

有的時候，彈窗會提供多種操作選項，並且每種操作選項都會有大段的說明文字。

還是拿學校老師新增班級做例子：校園網新上線了一個功能叫“智慧新增班級”，這個選項可以根據你的身份，自動檢測你帶的學生並填充到表格裡，你只需要把他們對應的班級標註出來就好了，不需要一個個手動填寫學生姓名，非常方便，所以推薦老師使用。但由於系統還不是很完善，因此只能檢測到高中部和小學部的學生，帶初中部學生的老師，還是需要手動新增班級。

假如非要用彈窗來做新建方式的選擇入口，並且還按照我們之前的彈窗基本結構來處理，那麼有些人可能會做成：

這個案例和諾曼《設計心理學》裡那個爐灶與旋鈕的案例不謀而合。這樣設計的劣勢是，使用者從讀完內容區的文字，到去操作區進行行為，需要在心裡先做一個判斷——我是高中小學部還是初中部的老師？然後再做一個對映——高中/小學部點這個“智慧新增”、初中部點這個“手動新增”。一來一去反應時間就變長了、出錯機率也更高。

因此，我們可以在這個案例上增強文案與選擇器的親密性，讓使用者做出判斷的瞬間就可以完成操作，無需再做一次對映：

甚至，假如這個任務以效率為第一標準並且規範定義的比較寬鬆，我們還可以省略“下一步”按鈕，直接將點選生效的熱區放置在內容區上：

同理，最佳化操作按鈕的文案也能幫助使用者消化內容區與操作按鈕之間的對映關係。比如說這種再確認彈窗：

習慣上來講我們會將一個彈窗的

積極操作（確認、提交、更改…）修改為與彈窗標題或內容區聯絡性更強、更符合場景的說法，

比如說印表機的“列印”彈窗，操作按鈕寫作“列印”而不寫作“確認”。這樣做的好處也是幫助使用者減少反應的時間。

但另一方面，彈窗的消極操作（一般是取消或退出，注意消極/退出操作不等於破壞性操作，比如刪除）的文案是不會修改的。這樣做是為了讓使用者無論在什麼場景下，都能感知到“取消”是一個無害的、不會造成嚴重後果的安全退出方式（和彈窗右上角的x一樣）。

3. 操作按鈕與附件

理想狀態下操作按鈕只有2個，但實際情況是多種多樣的，所以有時候操作區也可能有超過2個按鈕。

我個人把3個操作按鈕作為彈窗操作區的上限，假如超過3個按鈕，那麼就應該思考是不是去掉操作區，直接把按鈕放在內容區裡，以便幫助使用者合理地判斷自己應該按哪個按鈕。

當存在3個按鈕時，按鈕的擺放規則可以根據自己平臺的特性決定，並沒有通行的規則（但一般會將破壞性按鈕放在主操作按鈕的對側）。假如弄不清楚使用者的主要訴求，不用在多個按鈕中非要選一個推薦操作。

最常見的彈窗附件是“不再提示”按鈕，選中後提交彈窗，則這個彈窗就在使用者或者裝置維度不再出現了。這個操作常規上用checkbox實現，並且放在彈窗內容區/操作區都可以接受。需要額外注意的有這麼幾點：

（1）對於觸達彈窗來說，點選“知道了”“立即開通”都能算是對彈窗的一種表

態

，因此選中“不再提示”以後，點選任何一個主要操作彈窗都應該不再展示。而相比之下，選中“不再提示”後又點選“x”就意味比較含糊了，考慮到一般“不再提示”選框都不做預設選中，因此這裡選中很有可能是使用者有強意願，所以點“x”彈窗也不展示也說得過去。

但對於操作彈窗來說，“取消”是全域性性的消極操作。在任何情況下，使用者點選“取消”的含義都是“

放棄彈窗上的一切已完成操作並且退出彈窗

”，所以這裡只要使用者點選了“取消”，無論是否選中“不再提示”，都應該視作選擇未生效。雖然這樣做在具體場景內有違背使用者預期的可能，但為了全域性互動規則的一致性，這樣是更合理的。

（2）有些人比較傾向於把“不再提示”做成操作按鈕。我個人其實不太理解這種做法。

假如這個彈窗具有使用者價值，那麼就持續彈好了，沒必要設定“只彈一次”的限制；假如這個彈窗純粹是商業化行為，那按鈕文案寫成“我知道了”，直接修改按鈕的彈出邏輯即可，也沒必要告訴使用者錯過這次機會以後就不提示了。

本文由 @白話說互動 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議