先來了解一下什么是模態彈窗？

模態彈窗會打斷用戶的操作行為，強制用戶必須進行操作，否則不可以進行其他操作。看看模態彈窗都長啥樣吧！

一、常見的網頁模態彈窗

第1種彈窗提示信息，只有一個確認按鈕，只有提示的作用。有返回值，但返回結果一般不太重要。

第2種彈窗選擇按鈕，讓用戶選擇確定或取消，然后會進入到不同的處理步驟，需要有返回值。

第3種彈窗輸入內容，向用戶提問，并要求在彈窗中輸入文字，然后返回輸入的內容。

二、某些瀏覽器提供禁止模態彈窗功能，直接在瀏覽器設置中修改即可，甚至還可以自動返回值，使操作不因彈窗而中斷。

三、彈窗一般都是由javascript代碼產生的，在項目管理器中可以設置禁用javascript，這樣彈窗代碼將不會被執行了，不彈窗也不存在返回值，會影響所有javascript腳本執行。但它不會影響項目管理器中的javascript代碼執行。

四、自動檢測模態彈窗，并關閉彈窗。這種方法適用于所有的第三方程序窗口，可以控制瀏覽器以外的應用程序窗口。設定檢測頻率，按窗口標題識別彈窗，可以強制關閉彈窗或向彈窗發送鍵盤事件。使用這種方法時，彈窗最多存活一個檢測周期，往往一閃而過。

五、重載彈窗函數Alert，如下圖所示，不但可以阻止彈窗，還可以獲得彈窗顯示的內容。

六、重載confirm函數，如下圖所示，不但可以阻止彈窗，還可以直接選擇確定還是取消。

七、重載prompt函數，如下圖所示，不但可以阻止彈出輸入框，還可以把輸入的內容直接寫在代碼中。

Vuejs項目中，我們想實現這樣一個功能，當有模態框處于顯示狀態，按下瀏覽器的后退按鈕或者后退快捷鍵，不離開當前頁面，而是關閉最頂層的模態框，這是增強用戶體驗的一種設計，那么該如何實現呢？

在這里，我們以Vue3中的element-plus UI庫講解，眾所周知，常用的模態框有3種，分別是：自定義對話框，消息提示框，抽屜；我們的實現原理是，當路由導航之前，查找頁面中的模態框DOM元素，調用關閉按鈕的單擊方法來關閉模態框；原理是不是很簡單？

接下來，我們看代碼實現。首先，我們創建一個模塊文件modal.js，文件名大家可以隨便起。

然后，我們定義getAllModals函數，通過審查元素，我們得知對話框和抽屜的容器元素都有el-overlay類，我們就通過這個類進行查找，刪選出可見的模態框容器元素。數組的構造函數方法from用于將迭代器或類數組對象轉化為真正的數組。

/** @returns {HTMLDivElement[]} 所有可見的模態框容器元素 */
const getAllModals = () => {
  return Array.from(document.body.querySelectorAll('.el-overlay'))
    .filter(_ => window.getComputedStyle(_, null).display !== 'none')
}

接下來，我們定義closeModal函數，用于關閉模態框，返回true，表示成功關閉了一個模態框。后面，我們會使用這個返回值來決定導航的邏輯。

/** @param {HTMLDivElement} el */
const closeModal = el => {
  if (el) {
    /** @type {HTMLButtonElement} */
    const btnClose = el.querySelector('.el-dialog__close, .el-drawer__close')
    if (btnClose) {
      btnClose.click()
      return true
    }
  }
}

接下來，我們定義closeTopModal函數，用于關閉處于頂層的模態框，我們通過zIndex判斷模態框的層疊次序。

export const closeTopModal = () => {
  return closeModal(
    getAllModals()
      .reduce((t, _) => t ? +t.style.zIndex > +_.style.zIndex ? t : _ : _, null)
  )
}

接下來，我們定義closeAllModals函數，用于關閉所有模態框，用戶登錄狀態發生變化的時候會用到。

export const closeAllModals = () => getAllModals().forEach(closeModal)

接下來，我們定義closeMsgBox函數，用于關閉消息提示框，返回true，表示成功關閉了一個消息提示框。后面，我們會使用這個返回值來決定導航的邏輯。

export const closeMsgBox = () => {
  const el = document.body.querySelector('.el-overlay.is-message-box')
  if (el) {
    const visible = window.getComputedStyle(el, null).display !== 'none'
    if (visible) {
      /** @type {HTMLButtonElement} */
      const btnClose = el.querySelector('.el-message-box__headerbtn')
      if (btnClose) {
        btnClose.click()
        return true
      }
    }
  }
}

該模塊文件的最后，我們定義closeMsgBoxAndModalAll函數，用于關閉所有打開的消息提示框和模態框。

export const closeMsgBoxAndModalAll = () => {
  closeMsgBox()
  closeAllModals()
}

現在，我們可以轉向路由模塊文件了，我們對router的beforeEach導航守衛進行攔截，如果成功關閉了一個任意類型的模態框，那么阻止頁面跳轉。

router.beforeEach((to, from, next) => {
 if (closeMsgBox() || closeTopModal()) {
    return next(false)
  }
  next()
})

實現起來就是這么簡單，不是嗎？我以后有時間會分享更多的Web開發技術內容，歡迎大家閱讀，學習！若大家有更好的解決方案，也歡迎分享出來，共同進步，謝謝！

輯導語：Web端的設計規則有很多，設計內容也十分豐富，本篇文章作者分享了Web端彈框設計需要掌握的要點，從多個方面講述了有關彈框設計的內容，一起來學習一下，希望對你有幫助。

臺灣相較于大陸地區，互聯網發展相對較晚，用戶使用習慣較受海外市場影響。公司后臺數據顯示PC端用戶明顯高于移動端用戶，換句話說用戶更習慣于大屏上用到產品，大屏除了PC端還有iPad或其他屏幕端口。

Web端內容很多設計規則需要重新定義，而不是簡單從一端移到另外一端，以下關于彈框的內容是我踩坑總結，希望能給大家一點幫助。

一、彈窗的定義

定義：中斷用戶當前操作并對其作出補充，或中斷用戶當前操作并對其作出反饋。

彈窗，是一種“展現于頁面之上的一種信息容器”，在x、y軸的平面空間之外擴展了頁面的深度，它是一種比頁面更靈活的信息容器。

常見的彈框一般包含一個蒙版，一個主體及一個關閉入口，常見于網頁及移動端。其好處是讓用戶更聚焦，且不用離開當前頁面，更快更容易完成任務。

二、功能分類

以彈窗功能和用途可分為：任務類（引導操作）、內容反饋、信息展示三大類。模態彈窗一般是屬于任務類型的，比如賬號登錄、刪除某個信息等等

1. 內容反饋類型

用戶操作用戶界面時，系統給出相應的內容反饋，在設計師設計界面時常用到“通知提示”、“全局提示”、“氣泡確認框”三種類型作為消息反饋。

它的“非模態”在于用戶操作后不打斷用戶的情況下及時地顯示出來，明確告知用戶的一些反饋結果，幫助用戶更加有效的完成界面中的復雜任務。

如下圖谷歌郵箱右下角的通知提示，明確告知兩個按鈕的使用含義，決定權在于用戶，同時不影響用戶其它操作

2. 信息提示類型

存在的意義是及時有效的幫助用戶完成任務目標，不需要用戶做特殊動作或者轉換模式，就能看到和理解這些反饋，從而提高任務的操作效率和可理解程度。信息提示常常用到“文字提示”、“氣泡”、“警告提示”三種形式展現給用戶。如下圖的客服氣泡提示對應用戶想解決問題的相關路徑：

“非模態”彈窗中的“信息提示”類型通常都需要進行指定動作操作后出現，比如編輯好內容后點擊發送，通常會有發送成功的提醒。另外當系統中出現一些成功、失敗、錯誤、警示就需要“警告提示”告訴用戶；其中“文字提示”、“氣泡”它需要用戶懸停在某個焦點時出現，移除才消失，后面我也會講解到。

三、按體系分類

彈窗體系分為模態彈框與非模態彈框兩種，模態彈框和非模態彈框最大的區別就是是否強制用戶交互。

模態彈框會打斷用戶的當前操作流程，如果用戶不在彈框上操作，那么其余功能都使用不了；而非模態彈框僅僅是用于提醒用戶，用戶可以忽視繼續操作。

1. 模態彈框

模態彈框出現時，直到用戶明確與內容做出回應，才能消失。常見的有對話框、抽屜等。它的視覺層級非常高，屬于不操作不消失類型。

• 優勢：可以很好的獲取的用戶的視覺焦點，簡單易操作、承載的信息量有較大的彈性空間；
• 劣勢：浮層彈窗給主操作流程造成較強的割裂，降低整個頁面瀏覽的流暢度。也正是這個原因很多產品為了減少用戶跳出率使用模態彈框非常謹慎；
• 適用場景：適用于主流程步驟中需要分支任務行為的場景。

新的花瓣web端不登錄彈框不消失，除非點擊右上角關閉鍵或者點擊后面蒙層。

2. 非模態化的

從出現到停留消失的時間大約3-5秒，用戶可以不用做出任何操作，繼續與頁面內容進行交互，是一種極輕量的弱彈框，不影響用戶體驗。

• 優勢：同時進行多個操作，阻斷性弱；
• 劣勢：學習成本高，容易產生混亂，誤操作概率高；
• 適用場景：適用于理解難度大、多任務處理情況有較高的要求的場景。

上面警示提示時，下面【我已閱讀并同意語雀服務協議】是可操作的。

簡單講，模態彈窗就是當前必須完成后，才能繼續下一步；非模態彈窗隨時可關可不關，不影響當前任務。

3. 非模態彈框存在的意義

“內容反饋”及“信息提示”這兩種類型都統稱為“信息反饋”，因為它們兩種類型很相似，都屬于非模態彈框。“信息反饋”存在的意義是及時有效的目的幫助用戶完成任務目標，其中“有效”包含了“提供有用的信息反饋，提高任務的操作效率和可理解程度”。

1）有用

有用的「信息反饋」：

• 回應操作結果：告訴用戶剛剛做了什么，之前的操作導致現所處的狀態，讓用戶感受到一切都在掌握之中；
• 操作路徑指導：告訴用戶哪些過程正在進行中，下一步需要做什么，及時告訴這一步哪些地方操作有誤。

2）效率

提高用戶的操作效率：

• 操作行為反饋：在不打斷用戶行為操作的前提下提供良好的反饋機制，用戶看到反饋后可繼續操作當前頁面；
• 提前告知錯誤：在用戶出現錯誤之前及時制止，盡量避免出現錯誤后才的告知用戶；
• 減少系統報錯：減少用戶出錯率，設計師必須清楚不出錯不代表用戶總是正確的，而是杜絕「自以為是」地糾錯用戶錯誤，正確引導用戶形成良好的操作環境。

四、彈框的組成元素

彈框的組成元素主要包含以下幾類：

• 窗體容器（必要）：信息內容的主要載體；
• 圖標：一般跟著標題；
• 標題：標明彈框的目的/主題信息（簡單的信息確認常常沒有標題）；
• 提示文本（必要）：可以有多種信息展示，從一行文案到各種復雜的操作集合都可容納；
• 功能按鈕（必要）：供用戶選擇，一般不超過2個 （常見一個確定按鈕，一個取消按鈕）；
• 關閉按鈕：關閉彈框按鈕，并非取消鍵，關閉按鈕是最為常規的操作，主要是每一個用戶對于它都足夠的熟悉。因此建議不需要改變關閉按鈕的位置，一般會有在彈窗內與彈窗外兩種形式可供大家進行選擇；
• 蒙層：提醒用戶蒙層后面內容不可操作，聚焦當前彈窗內容（常見于模態彈框）。

五、非模態彈框的樣式框架對照表

1. 文字提示

做為輔助類解釋說明，常用做解釋該功能特點，常做為鼠標的懸浮提示。

目前有不少產品，在對一些普通的字段進行解釋說明時，特別喜歡使用帶遮罩的模態彈窗，需要用戶點擊才能關閉，嚴重阻礙用戶當前操作，這種設計是屬于不合理的。因為這樣簡單的解釋說明，用非模態彈窗來展現，用戶只需要懸停就能快速預覽相關內容，還可以快速離開（移開觸發區的圖標，或點擊空白區域）。

2. 通知提示

常用于系統級通知的被動提醒 ，通知彈窗主要是為了將一些重要信息通知給用戶

3. 警告提示

長文本提示建議增加標題，表示提示的類型或主題，用戶可快速理解主要內容，內容建議不超過 4 行。

Alert 默認四種類型的提示（這里顏色是固定的，比如付款成功一般是綠色，用戶已經產生這種認知，設計時不要用新的樣式讓用戶重新學習，人性是懶惰的），分別是：

• 普通提示 info：用于展示背景條件、政策信息、規范要求、當前狀態等客觀內容；
• 成功提示 success：用于展示已完成操作的成功狀態；
• 警告提示 warning：用于展示可能會導致某種后果的警示性文本；
• 錯誤提示 error：用于展示當前操作或者整體狀態有錯誤，提示用戶修正或展示錯誤相關信息。

提示框有描邊和填充這兩種變體可以使用，以便匹配不同的設計風格。

標準（默認）是淺色填充無邊框，填充（filled）是深色填充，描邊（outlined）只有邊框無填充。

注意：

1. 避免出現 “你”，“你的”，“我”，“我的” 這類詞語，因為這類詞匯有時候會給人生疏和趾高?昂的感受；
2. 不用刻意避免在警告框中使用消極負面的文案。?戶知道警告框彈出是出現了問題和危險的情況。

4. 全局提示

位置一般在頁面頂端，常出現在用戶操作后的反饋，頁面最上層浮動展示，暗示全局性。全局提示和警示提示狀態一樣默認有5種狀態，其中多一條loading狀態 。例如當我在語雀上編輯好文章發布成功后，發布成功會有個全局提示的提醒，這樣做為用戶的我知道目前是處于什么狀態。

5. 氣泡提示

鼠標 Hover/Click 時，可用于承載更多信息/輕量型的操作。

6. 氣泡確認框

點擊元素，彈出氣泡確認框，氣泡確認框不對父級頁面造成影響，或者僅會父級頁面造成部分影響，摹客首次登錄進去提示每個icon功能，但不影響后面面板的操作。

六、模態彈框的樣式框架對照表

1. 通知公告類彈窗

營銷彈框、公告通知彈框、提示類消息彈框都屬于通知公告類的“模態彈窗”，特點就是一般不需要用戶具體操作，當然某些場景也需要用戶簡單輸入的操作，但這些操作往往不復雜。

如果用戶將其關閉或者點擊“確認”等按鈕即代表用戶已經接收到該消息，彈窗就完成了它的任務。

適用通知公告類彈框的場景（通常是重要的信息，需要加強用戶關注度）：

• 輕量型的頁面，可以快速回到原來的界面；
• 相對比較獨立，與原來的頁面互不干擾，完全不影響原來頁面的整體布局；
• 比較適合簡單的一次性操作就能解決的內容。

1）營銷彈框

出于公司運營目標為提高曝光率和營收，或便于拉新和轉化。該框會在該網站加載出來后第一時間就會出現在你面前，直到手動關閉，不然不可操作其它。即便是他們產品運營知道這種方式比較遭人煩，也不得不如此，利益大于一切價值。

2）公告通知彈框

主要是為了將一些重要信息通知用戶，一般在用戶登錄后第一時間談粗，避免用戶錯過。這些信息一般來自一些被觸發的事件，或者來自應用開發者的信息。如果這些信息比較重要，在應用的通知中心也會保留這類重要或者高級別的通知，以便用戶查看回顧。例如摹客首次登錄有個更新提醒通知通過后版本更新內容，方便用戶知道。

3）提示類消息彈框（包含對話框）

模擬系統的消息提示框而實現的一套模態對話框組件，常用與消息提示、確認消息和提交內容。

確定取消語言文字描述、標題文字描述。

4）對話框

對話框強調了用戶與計算機進行對話的過程，是疊加在應用主窗口上的彈出框，一般在對話中它會給出消息或要求輸入。當對話完成后，即可關閉對話框。說人話就是，對話框一般需要用戶進行操作，當用戶輸入或者點擊“確認”、“取消”等按鈕時，計算機會根據指令進行工作，這是一個人機“對話”的過程，因此稱之為“對話框”。

2. 操作配置彈框

簡單配置（表單內容少，操作清晰）。

“簡單”意義上的彈窗可以理解為只有平鋪的表單讓你選擇或輸入，交互清晰明了。比如創建項目、更改名稱等操作。

3. 標簽頁彈框

有些應用的功能配置中有很多復雜的屬性，操作配置的彈窗無法滿足需求，需要更精細分層歸納。它的優點是合理利用了空間布局，讓信息層級更清晰易懂，使用起來更加高效。

標簽頁彈窗的設計需要找到信息之間的因果關系，單個彈窗中的標簽頁不宜過多，一般不超過五個，如果多余5個標簽，建議將其改為豎向顯示。

4. 分步彈框

分布彈框是分布表單的衍生品，與標簽頁彈框接近，區別是分步彈框需要上一步完成才能進行下一步，主要特點頭部會有進度條告知當前進度和后續還有需要幾個步驟完成操作，另外一點是頁腳上常常會有下一步、上一步兩個選項供用戶進行選擇。

5. 抽屜

抽屜指的是從當前界面的“上下左右”側邊滑出相應的表單內容完成相應操作，之前的內容不丟失。

• 優勢：承載的信息量有較大的彈性空間。
• 劣勢：由于信息集中在一側，導致視覺焦點不穩定，如果長時間工作，會產生不平衡的感覺。
• 適用場景：適用于當前任務流中插入臨時任務的場景。

抽屜式彈框常見4種樣式，表格中出現較多，通常會以側滑的形式出現，有加遮罩層的，也有不加遮罩層的模態彈窗（不加遮罩層方便方便用戶進行對比、參照和檢閱相關內容，同時并不會影響用戶對界面其他區域的操作）。

6. 頁面跳轉

頁面跳轉后的新開頁面是當前頁面保留，新的內容在新頁面中呈現。常見的頁面跳轉方式有直接跳轉、左右跳轉、上下跳轉、翻轉跳轉、聯動性跳轉、放大縮小跳轉（iOS微信公眾號浮窗）、搜索框跳轉。

其中直接跳轉是最原始最直接的跳轉方式，在web端很常見，實現難度和維護成本都很低。在設計時需要考慮好其中的關聯性，從而做出最合適的設計。

從頁面承載的內容看，新建頁面＞抽屜式彈框＞對話框。

• 優勢：信息承載能力強；有利于用戶對業務流程有更清晰的認識，從而使得主流程的操作流暢度高。
• 劣勢：及時性反饋較低，頁面連貫性明顯小于對話框和抽屜式
• 適用場景：適用于特別重要的功能表單的填寫場景。

但是我們不能單一從頁面內容量的多少來確定使用哪種形式。通常內容的深度較深最好采用抽屜式，內容寬度較寬則彈框形式更為合理，新建頁面適合寬度與深度同時較大的產品中

本著孜孜不倦的學習心態，這次梳理也是因為在工作中遇到2個小問題。

1）模態彈框是不是一定有黑色透明蒙層，沒有蒙層時屬于什么性質彈框？

這時候我各種渠道搜索之后發現有些大佬說蒙層是模態彈框的標志，并沒講原因，這種說法完全不能接受。我在使用過程中碰到過沒有蒙層的彈框，存在即合理好奇心驅使我去問了研發和產品同學，最后得出結論根據用戶使用場景不同，對蒙層的設計也不同。

原來是隨著產品對彈窗的使用，也會有需求采用不透明度為0的蒙層，最小化打斷用戶的操作的不良體驗；但是要注意在一個產品系統中蒙層不透明度的使用應該統一，這個需要規范定統一的不透明度避免產品各個地方不統一的情況。

谷歌郵件非常典型案例，當窗口最大化時，產品認定為用戶專注寫郵件不想被打擾場景，所以父級頁面加上蒙層不可操作，視覺聚焦當前彈框操作窗口；當新郵件窗口默認模式時，產品判斷用戶可能是寫郵件場景，同時可能需要翻閱或查找以往郵件，這時候父級頁面操作完全不受影響。

可以說明蒙層取決于當前操作是否需要參照父級頁面，如果填表需要參考父級頁面可以不需要蒙層，反之相反。

我寫日報時候覺得非常便利，有時候需要查看昨天日報，看看計劃今日是否完成，以便提交今天日報。如果這時候父級頁面不可操作，我需要多4-5步把昨天內容復制過來，這無疑是非常累贅的操作。

2）為什么有的模態彈框右上角沒有關閉鍵？當彈框下面有確認和取消鍵可關閉彈框時，右上角關閉鍵多余能否去掉？

關于這個問題不知道大家伙有沒有觀察到，早期win電腦的彈框右上角都有固定位置的關閉按鈕，發展到目前有些產品設計右上角保留關閉鍵，有些產品設計省去關閉鍵了，那么它們存在或消失的邏輯是什么呢？

上圖花瓣和Pinterest的彈框中，點擊蒙層都可關閉，同時花瓣右上角有關閉按鈕，這樣看來關閉按鈕似乎多余了。

我們再看上圖中的案例，對于這種表單頁，右下角取消鍵以及右上角的關閉都可以關閉彈框，導致存在兩個關閉鍵我認為有以下幾點：

1. 視覺平衡（只針對彈框，這個原因占比很小）；
2. 符合用戶習慣（由傳統win操作轉移，對于不需要的操作習慣性關閉，而不是取消）；
3. 交互一致性：出于一致性原則，整個產品彈框右上角都有關閉按鈕；
4. 提高無障礙訪問：這個理解有點類似鍵盤上esc鍵，退出當前操作，在沒有確認和取消按鈕時，這個關閉鍵就至關重要。

不同場景的理解：

對話框的「關閉」是對于彈窗頁面的一種反饋，它的含義是「關閉當前彈窗，暫對彈窗內容暫時不做處理」；而彈框里面「取消」是對彈框內容的反饋

比如對話框給用戶，問是否要加入活動？如果用戶還沒想清楚，不想現在決定，點否表示拒絕不合適的，關閉彈窗就表示我現在不做決定。從操作上關閉和取消鍵判斷是一致的，用戶沒有激活活動。

七、交互細節思考

1. 選擇：用對話框還是抽屜

與“對話框”對比，“抽屜”在使用場景也有它的優劣勢。

• 優勢：“抽屜”的頁面空間更大，它能夠承載更多的內容、信息，它與主頁面親密度更高；
• 劣勢：“抽屜”的靈活度比較低，比如“對話框”可以根據業務的內容多少去變化它的寬度與高度，而抽屜只能橫向/縱向降低尺寸。
• 一致性：例如某產品彈出的表單大多較長，采用抽屜組件，為了保持體驗的一致性，個別短表單也可以同樣采用抽屜。

“抽屜”適用范圍更小，大部分場景下都用在較復雜的表單及字段較多詳情頁。

“抽屜”在Web端的應用中可分為：a. 內容展示、b. 表單編輯這兩大類型。

注釋：

操作確認、信息提示、操作反饋場景：在需要用戶暫停當前操作、即刻處理時，使用模態彈框。

需要和父級頁面內容相互參照：使用無遮罩的非模態抽屜，便于查看和操作。

需要在父級頁面中快速選擇切換：使用無遮罩的非模態抽屜。在下面父頁面露出的部分上進行與抽屜內容和位置都無關的操作，且不是點擊空白區域時，抽屜不用自動消失。

疊放：是指在一個對話框/抽屜上面疊加放置更多對話框/抽屜。不建議對話框上疊放對話框，但抽屜組件支持多層抽屜，即在抽屜內打開新的抽屜，用以解決多分支任務的復雜狀況。

八、如何設計出合理的彈框

1. 前提條件

優秀彈窗不管從視覺設計層面還是從文案邏輯層面都需要清晰簡潔易懂，在彈出時需要考慮目標用戶是否理解，以及盡量降低用戶的其它操作。

假想我正在玩游戲或看直播、突然來了個騷擾電話全屏幕覆蓋（傳統來電），我會以最快的速度掛掉電話，回到游戲中發現已領盒飯，這個就相當尷尬了。

即便來電是多么的理所當然，但心里必定是非常不痛快的。如果來電以彈窗的形式占據屏幕很小區域是不是就給了用戶足夠反應時間及緩沖時間呢？

2. 設計目的

理解彈框設計前提后，下一步需要明確設計目標。

設計師應該理解產品需求，分別產品側（能給產品帶來什么？產品如何期望？是否合理？能得到什么樣的結果）？

從用戶側（能給用戶帶來什么？滿足什么樣的需求？避免什么損失）？

分析為什么要加彈窗，然后將分析的結果轉化為設計目標，以確保彈窗根據不同的需求，以適合的樣式呈現給用戶。

其次，在得到設計目標后，同樣需要從設計側、技術側思考彈窗組件的一致性。

從設計角度，團隊所有成員需要對該組件有清晰且統一的認知，了解組件的使用場景，以確保不會錯用、濫用，提升效率。

站在技術角度，一致性的常用彈窗組件，便于開發做組件封裝后續復用，大大提高開發效率。

這里我強調下我們接到業務訴求明確到控件時，作為設計師該如何判斷和溝通訴求的合理性：

首先接到需求后，執行不是第一步，我們首先需要判斷業務的首要目標和具體訴求是否統一，具體訴求是否是完成目標的最佳解決方案？

例如舉例的業務目標：“減少用戶跳出帶來的流失”——先確定流失的的根本原因是否由跳出導致，原有流程中跳出的目的是什么，改變承載介質是否能達成原有目的？確定以上信息便于我們同步業務根本需求，從而判斷訴求的合理性，同時明確設計側可發力點。然后才是如何輸出平衡業務目標與用戶體驗的有效方案。

3. 需要注意的點

1）文案表述

因彈窗本身承載內容有一定的局限性，固文案一定要簡潔且精確，能用一句話說清楚的就不要過于啰嗦，容器的空間有限且用戶的耐性也有限。

2）標題字體

另外文案的標題往往比正文大2px或4px，具體看自己公司字體規范，比如新建表單、刪除信息、修改內容等，前面不同標題對應不同的功能場景，都是為了用戶方便理解。

3）確定與確認

我們先講講彈窗中常常容易被忽視也容易搞混淆的「確認」和「確定」，它們常常與「取消」按鈕搭配使用，從表面的中文上看他們很接近，所以造成很多設計師把二者混合著用。

4）彈出的時機及頻率

針對運營彈窗，如果彈出的時間不對或過于頻繁，可能會造成用戶反感，所以需要把握好彈出時機及頻率。

例如包圖網VIP，如果用戶每次進入應用都看到彈出提醒，確實又沒有購買商品的意愿，總是被彈窗打斷真的就很煩，并且彈框后也套著彈框。若我需要下載素材需要關閉2次才能找素材，相信你進入該網站也會反感。

那么可以適當將提醒彈窗設置為每日首次進入應用時提示、每累計進入應用5次后提示或者即將到期提示等，總之，需要控制在大部分用戶的可接受范圍內。

5）盡量避免彈框上再加彈框

要盡量避免在彈框上再彈一層彈框，多層層蒙版會讓用戶覺得負擔很重，當然早期win多模態彈框采用位置錯誤，在產品中盡量避免使用。

如果有多個彈框一同出現該怎么辦呢？

一是要做好多種內容層級的排序，二是不同類的內容盡量區分場景改用輕量彈框或者交互重新梳理，還有多個彈窗同時出現的時候，頁面的彈窗疊加在一起，無論是視覺還是感受都會非常差，建議慎重使用。

6）抽屜頁面上可以更深一步操作彈出彈框或再疊加一個抽屜

九、如何優化彈框用戶體驗

1.彈框尺寸如何定

我們開始設計一個彈框時，首先解決的問題是確定彈框尺寸。

上圖可看出市場市面上最小的屏幕是1024×768，那是不是只要在最小分辨率下不錯位不跑偏，在其他分辨率就能安分守己呢？

2. 彈框高度和寬度

那下面我們就以最小分辨率1024×768為基礎開始今天的論證。

• 高度：768-60（或100瀏覽器高度）-40（底部狀態欄）＝628~668 px；
• 寬度：1024px – 約20px(滾動條寬度度) ≈1000px。

由此可以得出彈窗尺寸的界限值：彈窗高度≤620px，寬度≤1000px。

1）彈窗高度不高于瀏覽器內容展示

彈框高度過高，彈框顯示不全，就算滾動條固定到底部也有一部分顯示不出來，影響操作。對話框的大小主要根據內容而定，Web端應用中，一個尺寸無法滿足所有類型的彈窗需求。

抽屜提供穩定的尺寸。提供 S (w=378px) 和 M (w=736px)基礎寬度選項。這兩個尺寸是根據 antd 表單尺寸規范，分別可容納單列和雙列表單，而且保持了使用抽屜時父級頁內容可見的優勢。

2）內容滾動

坑我已經幫大家踩完了，大家在設計抽屜式彈框和父級頁面都是長頁面時，一定要將背景滾動條進行鎖定，不然兩個滾動條的出現，會導致十分混亂。

3. 關閉方式優化

彈窗應至少包含一個以上的關閉方式，常見的彈窗關閉方式有 4 種：

1. 右上角的關閉按鈕；
2. 彈窗底部的“取消”按鈕；
3. 彈窗外的任意區域；
4. 一段時間后自動消失。

彈窗外的任意區域，這種方式一般用于模態彈窗，除了彈窗中的關閉按鈕外，點擊彈窗外的任意區域關閉，這種交互方式上文內容有提到討論過，這里不再贅述。

值得注意的是操作配置類彈窗不建議采用點擊蒙層關閉彈框，極易誤操作導致正在配置中的彈窗被關閉。

4. 模態層優化

方式一：模態層顏色根據產品品牌色定

蒙層顏色可以用色彩傾向偏向品牌的蒙層，這樣整體品牌感知會加強，如上圖蒙層加入了品牌色的色彩傾向，整體品牌感知更強。

方式二：有模態層但不顯示

模態抽屜的遮罩背景層可以降低透明度，也可以是全透明不顯示的，可以更好的展示關聯的信息，點擊抽屜其他處可關閉抽屜，下圖中的模態抽屜就是這樣設計的。點擊右側父級頁面可關閉抽屜。

方式三：去掉模態層

下圖中的抽屜為非模態抽屜，可以根據左側列的切換快速查看右側抽屜內容。

是否去掉模態層根據場景而定，如果抽屜內容與父級頁面關聯，建議去掉模態層，目標是方便用戶操作。如果抽屜內容與父級頁面無關聯，加上蒙層，避免父級內容的干擾，讓用戶視覺更聚焦抽屜內容。

十、內容小結

1. 知己知彼

• 己：我們需要對每種樣式使用方式與注意事項了然于心，這樣在我們設計的時候才能得心用手；
• 彼：對產品的業務需求有所認知，對研發實現方式有一定了解，這時候我們的觀點才會專業，才能有理由說服其它人，從而設計出好用又統一的頁面，實現我們的設計價值。

2. 體驗統一

對于頁面的展示采取哪種樣式有科學說服性解釋，注意交互體驗的一致性，也注意不要為了一致而一致，效率至上，滿足業務需求為第一位。考慮好之間的關聯性，給出最符合用戶心理預期的過渡方式，就可以幫助我們找到最合適的設計。

3. 未來趨勢

互聯網不斷影響著我們的生活，移動端也在引領著設計趨勢，多端體驗的一致性，可以想像將會有一大波移動上的體驗遷徙網頁設計上，未來還會出現更好用且易維護的展現方式。

文章引用：

• PC端彈窗設計十全大補；
• 大廠高手出品！深入了解B端的彈窗設計應用；
• B端彈窗設計指南，超詳細；
• B端內網的彈窗規范——看這篇就夠了。

本文由 @見賢設計筆記 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。