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

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

一、彈窗的基本布局

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

在做規(guī)范時，做控件的邏輯和組裝車是很類似的：控件的內容布局也有基本零件和附件。基本零件的差異決定了不同彈窗類型（這種差異是比較大的、場景性的差異）；而附件的差異則決定了同類型彈窗的擴展性（也就是你定義的這類型彈窗，極限狀態(tài)下最多能支撐什么樣的場景）。

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

△也沒多難

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

△jira真的很愛大彈窗

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

• 相對簡單的：容器、標題、關閉方式
• 比較復雜的：內容區(qū)、主操作按鈕
• 附件：“不再提醒”

二、彈窗的容器

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

• 彈窗的尺寸需要和內容適配。正常情況下，彈窗應該是不需要縱向滾動的（當然橫向滾動就更應該避免了）。假如你的彈窗尺寸需要滾動一下才能展示全信息，應該先考慮它是不是過小。
• 大彈窗和全頁面、不同尺寸彈窗之間，應該有明確的界限。交互需要去界定什么樣的信息量是彈窗容納的極限，超過這個“極限”那么彈窗這種控件就無法承載、需要使用其他的展示形式。

三、彈窗的標題

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

（1）假如這個彈窗是由用戶主動觸發(fā)的，那么彈窗標題應該與用戶觸發(fā)彈窗的操作按鈕同名，或者至少有相同的關鍵字。此時彈窗是用戶操作后的反饋，用戶需要通過彈窗的標題來確認自己是否進入了正確的模塊、進行了正確的操作。

（2）彈窗標題與內容區(qū)說明文字要各有分工。一般來講，彈窗標題簡單陳述問題、詢問行為或者作出行為建議。內容區(qū)的說明文字展開來解釋出現問題的原因，以及操作后的后果。

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

四、彈窗的關閉方式

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

作為一個非常底層的控件，彈窗（或者說窗體）應該兼顧大部分用戶的不同習慣，來保持整個系統有比較好的可用性。因此，建議在右上角添加“x”作為關閉操作性彈窗的最短路徑，并且佐以鍵控、點擊遮罩等多種關閉方式；除非要求用戶明確表態(tài)（比如要求同意協議）

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

五、內容區(qū)與主操作按鈕

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

1. 內容區(qū)與操作的層級關系

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

彈窗的底欄層級高于內容區(qū)：底部操作欄上的主操作按鈕承載著全局操作，它的行為對彈窗整體生效、可能會導致彈窗關閉；而內容區(qū)的操作只對內容區(qū)生效，并不會導致彈窗關閉。這意味著做交互的時候，需要在樣式上為全局按鈕、內容區(qū)按鈕作出區(qū)分，以免用戶產生困惑。

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

到此為止內容區(qū)與操作的關系都還是清晰的，但一旦我們?yōu)閺棿凹尤雽Ш娇丶猼ab，那有些人可能就搞不清楚了。

首先我們在做彈窗的時候，要盡量降低彈窗的層級結構和內容復雜度，盡量把用戶完成任務的關鍵信息一開始就展示出來，避免用戶在彈窗里四處探索。但假如說因為任務的因素非得在彈窗上加tab的話，還是需要記?。簩儆趶棿皟热輩^(qū)的tab的層級低于彈窗操作區(qū)。

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

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

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

反過來說，正因為彈窗的操作區(qū)層級比內容區(qū)高，并且tab是一個導航控件而非選擇控件，因此tab+彈窗的潛臺詞是“點擊操作按鈕后，所有tab中的內容都會被提交，即使有些內容當前沒有展示出來”，而不是“只有選中的tab會生效”。因此，假如你需要讓用戶在彈窗上作出選擇，就不要使用tab等導航控件，而可以選擇單選框/多選框這種典型的選擇控件（或者蘋果的segemented control這樣有點像導航的選擇器）。

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

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

2. 內容區(qū)與操作的映射關系

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

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

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

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

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

甚至，假如這個任務以效率為第一標準并且規(guī)范定義的比較寬松，我們還可以省略“下一步”按鈕，直接將點擊生效的熱區(qū)放置在內容區(qū)上：

同理，優(yōu)化操作按鈕的文案也能幫助用戶消化內容區(qū)與操作按鈕之間的映射關系。比如說這種再確認彈窗：

習慣上來講我們會將一個彈窗的積極操作（確認、提交、更改…）修改為與彈窗標題或內容區(qū)聯系性更強、更符合場景的說法，比如說打印機的“打印”彈窗，操作按鈕寫作“打印”而不寫作“確認”。這樣做的好處也是幫助用戶減少反應的時間。

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

3. 操作按鈕與附件

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

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

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

最常見的彈窗附件是“不再提示”按鈕，選中后提交彈窗，則這個彈窗就在用戶或者設備維度不再出現了。這個操作常規(guī)上用checkbox實現，并且放在彈窗內容區(qū)/操作區(qū)都可以接受。需要額外注意的有這么幾點：

（1）對于觸達彈窗來說，點擊“知道了”“立即開通”都能算是對彈窗的一種表態(tài)，因此選中“不再提示”以后，點擊任何一個主要操作彈窗都應該不再展示。而相比之下，選中“不再提示”后又點擊“x”就意味比較含糊了，考慮到一般“不再提示”選框都不做默認選中，因此這里選中很有可能是用戶有強意愿，所以點“x”彈窗也不展示也說得過去。

但對于操作彈窗來說，“取消”是全局性的消極操作。在任何情況下，用戶點擊“取消”的含義都是“放棄彈窗上的一切已完成操作并且退出彈窗”，所以這里只要用戶點擊了“取消”，無論是否選中“不再提示”，都應該視作選擇未生效。雖然這樣做在具體場景內有違背用戶預期的可能，但為了全局交互規(guī)則的一致性，這樣是更合理的。

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

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

本文由 @白話說交互 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議