確認

確認是強制回應對話框，詢問使用者是否要繼續執行動作。

一般確認。

確認具有下列基本特性：

• 它們會顯示為使用者起始之動作的直接結果。
• 他們確認使用者想要繼續進行動作。
• 它們是由簡單的問題和兩個以上的回應所組成。

當動作要求使用者做出相關且不同的選擇時，確認最有用，且稍後無法進行。 這種選擇通常牽涉到使用者不明顯的一些風險元素，但風險對確認並不重要。 這些元素是必要的，才能證明回應強制回應對話框的中斷。

相反地，警告訊息 呈現未來可能造成問題的條件。 其基本特性是，它們涉及風險：

• 它們牽涉到可能遺失下列一或多個專案：
  • 寶貴的資產，例如數據遺失或財務損失。
  • 系統存取或完整性。
  • 隱私權或機密資訊的控制權。
  • 用戶的時間（大量，例如30秒以上）。
• 他們有意想不到的或意外的後果。
• 他們現在需要正確的處理，因為錯誤無法輕易修正，甚至可能無法復原。

如果確認涉及風險，也可以將其視為警告。 因此，也會套用警告訊息指導方針。

注意： 與 對話框、錯誤訊息、版面配置，以及 警告訊息 相關的指導方針會在個別的文章中呈現。

這是正確的使用者介面嗎？

若要決定，請考慮下列問題：

• 使用者被問及要繼續執行有兩個以上回應的動作嗎？ 如果沒有，訊息不是確認。
• UI 是否顯示發生錯誤或問題？ 如果是，請改用 錯誤訊息。
• 繼續動作是否需要使用者做出沒有適當預設值的選擇？ 如果是，可能是適當的確認。
• 是否有替代設計可免除確認的需求？ 確認的需求有時表示設計缺陷。 通常有一個更好的設計替代方案，不需要確認。
• 使用者是否即將執行有風險的動作？ 如果是，如果動作有重大後果或無法輕易復原，則確認是適當的。
• 用戶即將放棄工作嗎？ 若是如此，請勿確認。 假設使用者瞭解未完成工作的後果。
• 動作是否有使用者可能不知道的後果？ 如果是，可能是適當的確認。
• 假設目前的內容，使用者是否可能會執行錯誤動作？ 如果是，可能是適當的確認。
• 使用者是否經常執行動作？ 如果是，請考慮替代設計。 頻繁的確認很煩人，而且幾乎沒有價值，因為使用者不考慮就學會回應。
• 動作是否具有安全性影響？ 如果是，即使先前的測試指出否則，仍可能需要確認。

設計概念

不必要的確認令人惱火

第一次建立的 Windows 確認無疑看起來像這樣：

原始令人惱火的確認。

這是一個非常糟糕的開始。 如果您希望使用者討厭您的程式，只要在整個過程中灑下這樣的確認即可。 若要瞭解原因，請考慮用戶的觀點。 使用者只是要求依照確認的定義執行動作，因此除非意外按下或按下某個專案，否則用戶當然想要繼續。

不僅不必要的確認令人惱火，而且對保護使用者免於錯誤並不有效。 使用者快速發現程式何時有不必要的確認，而其自然響應是儘快關閉它們，通常不需要閱讀。 因此，這類確認會多做一點，而不只是在這些工作中新增額外的步驟。

請勿使用確認，只是因為使用者有可能犯錯。 相反地，當用來確認具有重大或非預期後果的動作時，確認最有效。 良好的確認永遠不會指出顯而易見的：他們應該傳達使用者需要注意的一些事項，才能繼續。 只有當動作真正需要時，才會使用它們，例如只有在有值得儲存的變更時，才要求使用者儲存變更。 這樣做只會要求使用者注意真正值得注意。

對於其他類型的確認，通常有比強制使用者回答問題更好的設計替代方案。

請考慮設計替代方案

以下是一些設計替代方案，可消除例行確認的需求：

• 防止錯誤。 設計工作，使重大錯誤難以意外執行。 例如，在實體上將破壞性命令與其他命令分開，而且需要多個動作才能完成。
• 提供復原。 提供還原動作的功能。 例如，刪除Microsoft Windows 中的檔案通常不需要確認，因為已刪除的檔案可以從回收站復原。 請注意，如果動作很容易執行，只要讓使用者重做動作就已足夠。
• 提供意見反應。 讓不想要的結果變得明顯。 如果使用者在犯錯時沒有意識到，單獨提供復原就不足。 例如，直接作的效果（例如拖放作業）應該一律很明顯。
• 假設可能的結果，但很容易變更。 如果您不確定使用者想要什麼，但有可能、安全且安全的選擇、假設該選擇、清楚說明發生的情況，以及使用作功能表輕鬆變更。 例如，Microsoft Word 假設使用者想要正確拼字。 如果它辨識拼錯字，而且知道可能正確的拼字，Word 會自動進行更正，但允許使用者還原。
• 完全排除選擇。 如果選擇不重要，使用者就不在乎。 最好 簡化程式，並排除選擇。

進行確認需要思考

若要確認有值，用戶必須瞭解不繼續的原因。 有時候，原因很明顯，因為當使用者關閉含有尚未儲存之變更的檔時：

在此範例中，確認的原因很明顯。

在其他情況下，原因可能不太明顯。

選擇對話框的認可按鈕標籤時，一般指導方針 是選擇特定回應主要指示的標籤。 這會導致有效率的決策，因為用戶必須讀取最少量的文字才能繼續。 不過，這項效率目標對於確認可能會適得其反。 請考慮下列範例：

不正確：

使用卸載按鈕進行確認的

在此範例中，正確的回應需要思考。

如果您在使用者提供 Uninstall 命令之後立即顯示此確認，則用戶的回應可能是「我當然要卸載！使用者將會按兩下 [卸載]，而不需再考慮一下。

為了確認，我們不希望使用者做出匆匆、情緒化的決策。 為了鼓勵使用者思考他們的回應，我們需要提供一個小決策速度顛簸。 實際作時，最好是仔細詞組認可按鈕來執行這項作。 例如，我們可以使用其他語言來指出有理由不繼續。

更好：

在此範例中，「無論如何」會新增至認可按鈕標籤，表示確認會提供不繼續的原因。

如果這種方法不實用，我們可以使用 [是/否] 認可按鈕。

也更好：

使用是/否按鈕

在此範例中，使用 [是/否] 認可按鈕會強制使用者至少讀取主要指令。

提供所有資訊

如果您要提出問題，您必須為使用者提供足夠的資訊，以智慧方式回答該問題。 請考慮 Windows XP 的 [確認檔案取代] 對話框：

[Windows XP 確認檔案取代] 對話方塊。

此確認是否提供使用者可能需要回答問題的所有資訊？ 在回答之前，請考慮最常見的使用者案例：

• 複製 （或移動） 另一個檔案，取代現有的檔案。
• 保留現有的檔案，而不複製或移動另一個檔案。
• 保留或複製較新的檔案（最上層案例）。
• 保留現有的檔案或複製另一個檔案，視檔案內容和大小等準則而定。
• 保留現有的檔案，並使用不同的名稱複製另一個檔案。
• 如果發生錯誤或非預期，請取消作業。

使用者可以按兩下 [是] 和 [案例 2]，按兩下 [否] 來達成案例 1。 他們可藉由比較檔案日期並按兩下適當的按鈕來達成案例 3，但請注意判斷較新的檔案需要多少想法，然後判斷適當的按鈕，特別是最常見的案例。

案例 4、5 和 6 也出人意料地困難。 檔案大小會四捨五入，因此，例如，無法判斷這些檔案的大小是否相同，或即使檔案相同。 圖示適用於用來開啟檔案的應用程式，因此使用者必須開啟檔案來檢查和比較其內容。 擁有檔案內容的縮圖對於回答問題會更有用。

Windows Vista 的複製檔案確認會藉由提供更多資訊並新增選項來保留這兩個檔案，以更好地處理這些案例：

Windows Vista 複製檔案確認。

提供特定且有用的資訊

如果您要詢問問題，請確定使用者了解問題以及替代回應的影響。 請考慮此 Windows Internet Explorer 安全性確認：

確認的螢幕快照

模糊的安全性確認。

此確認會詢問用戶無法以智慧方式回答的問題。 使用者已要求 Windows Internet Explorer 顯示頁面，而且此訊息會透過文字的措辭隱含地建議，並將 [否] 反白顯示為默認選擇。

頁面構成的特定安全性問題尚未充分說明，因此無法清楚繼續的風險。 確認中有哪些資訊會導致使用者按兩下 [否] ？ 由於郵件模糊不清，確認不太可能阻止用戶繼續，但會讓他們對這樣做感到不好。

若要讓此確認很有用，它必須提供可能導致使用者決定不繼續的詳細資訊特定資訊。 一般而言，針對確認中的每個回應，請考慮需要該回應的案例，並確定提供足夠的資訊供用戶選擇。 提供選擇，而不是兩難點。

如何判斷是否需要確認

思考案例，以及選擇每個回應的可能性，建議有系統的方式判斷是否需要確認。 如果使用者可能選取所有回應，則確認是必要的且有用。 不過，如果只有一個回應可能（例如 98% 的時間），確認顯然是不必要的，應該移除。 請注意，與安全性、法律和安全問題相關的確認可能是例外狀況。

是否需要此確認？ 使用者是否會選取 [否] ？ 這是可能的，但非常不可能。 應該移除此確認。

如果您只做三件事...

1. 請確定您的確認確實是必要的。 應該有一個合法和明確的理由不繼續，有時使用者不會有機會。

2. 如果確認的原因並不明顯，請選擇鼓勵使用者思考其回應的認可按鈕。 一般而言，這是藉由將確認詞組描述為是或否，並提供完全解釋性或是/否答案來完成。

3. 請考慮所有案例，並提供以智慧方式回答問題所需的資訊。

使用模式

確認有數種使用模式：

用法	例
例程確認 確認使用者想要繼續進行例行的低風險動作。	這些確認通常片語為「您確定...嗎？」，而且通常不會再顯示此訊息複選框，以將他們的煩惱降到最低。 例程確認的範例。 注意： 此模式通常是不必要的，而且應該避免。
風險動作確認 確認使用者想要繼續進行有一些風險且無法輕易復原的動作。	因為這些確認有風險，所以這些確認通常會有警告圖示。 具風險動作確認的範例。
非預期的結果確認 確認使用者想要繼續進行具有非預期或非預期後果的動作。	除了提出問題外，這些確認還指出了意外的後果。 因為它們有意外的後果，所以這些確認通常會有警告圖示。 非預期的結果確認範例。 不過，此模式要求後果確實非預期。 不正確： 後果在這裡，因此這是例行確認。
澄清 釐清使用者想要如何繼續進行可能模棱兩可或非預期後果的動作。	拖放作業可能會導致釐清作業是否可能誤譯作業的效果。 確認[一律儲存在結束時？] 的螢幕快照 釐清的範例。 注意：應避免 此模式，因為最好設計動作，而不會產生模棱兩可的結果，並假設最可能想要的結果。
安全性確認 確認使用者想要繼續進行安全性後果的動作。	安全性確認的範例。
Ulterior 動機確認 提供動作的相關信息，但將它顯示為確認。	雖然這些對話框會顯示為確認，但他們真正的目標是使用者教育或功能廣告。 ulterior 動機確認的範例。 注意： 不建議使用此模式，因為通常有較佳、更直接的替代方案。 例如，動畫 是顯示原因與效果之間關聯性的最佳方式。

指引

常規

• 只有在有重大變更時，才使用「儲存變更」確認。 請勿確認使用者未直接進行的變更，例如自動檔重新格式化。

不正確：

當用於使用者未變更的空白電子郵件或檔時，這個範例不正確。

圖示

• 確認不會使用標題列圖示。

• 確認的內容區域圖示是以其設計模式為基礎：

  模式	圖示
  例程確認	沒有圖示。
  風險動作確認	警告圖示。
  非預期的結果確認	如果有風險，請使用警告圖示;如果有的話，請使用功能圖示;否則，不顯示任何圖示。
  澄清	如果確認涉及檔，請使用檔的縮圖;否則，如果有的話，請使用功能圖示，或沒有圖示。
  安全性確認	警告圖示。
  Ulterior 動機確認	沒有圖示。

• 請勿針對例行問題使用警告圖示。 這樣做與 Windows 令人鼓舞的 語氣相反，並讓您的程式感覺就像是危險的活動。 假設使用者在工作完成之前瞭解取消工作的後果。

不正確：

在此範例中，會使用警告圖示來詢問例行問題。

認可按鈕

• 如果確認的原因很明顯或可以自行解釋，請使用主要指令的特定回應。

在此範例中，確認的原因很明顯，因此 Save 和 Don't save work well.

• 否則，請使用 [是] 和 [否] 按鈕進行確認回應。 這麼做可讓用戶在回應之前先進行確認。 請勿使用 [確定] 和 [取消] 進行確認。

正確：

在此範例中，使用 [是/否] 認可按鈕會強制使用者至少讀取主要指令。

不正確：

在此範例中，使用OK/Cancel會混淆。

• 若要關閉程式或重新啟動 Windows，請使用主要指令的特定回應。 若要防止任何誤解，請勿針對此目的使用 Close 或 Yes/No。

正確：

立即重新啟動視窗的螢幕快照

不正確：

[是] 按鈕的螢幕快照

在不正確的範例中，是用來重新啟動 Windows。

命令連結

• 如需釐清模式，請考慮使用命令連結來清除替代專案。

可接受 ：

更好：

使用命令連結

在較好的範例中，命令連結會讓替代專案清楚。

• 先呈現最常用的命令連結。 產生的順序應該大致遵循使用的可能性，但也具有邏輯流程。
• 如果命令連結需要進一步說明，提供補充說明。 補充說明說明用戶為何可能想要選擇選項，或選擇選項時會發生什麼事。

如需更多指導方針和範例，請參閱 命令連結。

預設值

• 確認的預設回應是以其設計模式為基礎：

  模式	默認回應
  例程確認	進行。
  風險動作確認	不要繼續（或安全選擇）。
  非預期的結果確認	如果後果很大，請不要繼續;否則，請繼續進行。
  澄清	最有可能的回應。
  安全性確認	不要繼續。
  Ulterior 動機確認	進行。

不要再顯示此訊息

• 僅針對例程和特意式確認模式使用此選項。 對於其他模式，如果需要資訊，應該一律顯示它。
• 請勿提供此選項來證明顯示不必要的確認。 請改為擺脫確認。

不正確：

仍然不正確：

在這些範例中，新增 [不要再顯示此訊息] 選項並不會修正不必要的確認。

如需詳細資訊，請參閱 對話框。

大量作業

• 如需適用於大量作業的確認，請提供將確認套用至整個作業的選項。

此範例有大量作業的選項。

• 在大量作業中消除或延後確認。

不正確：

在此範例中，Windows XP 中的 Windows 檔案總管會在大量檔案移動期間確認每個唯讀檔案。 最好只複製只讀檔案而不詢問，或延後處理這些檔案，並在工作結束時顯示確認。

漸進式洩漏

• 如果您必須在確認訊息中包含進階資訊，請使用漸進式洩漏按鈕來顯示它（例如，「顯示詳細數據」）。 這麼做可簡化一般使用方式的確認。 請勿隱藏所需的信息，因為使用者可能找不到它。
• 除非確實有更多詳細數據，否則請勿使用「顯示詳細數據」。 不要只以不同的格式重新整理現有的資訊。

如需標籤指導方針，請參閱 漸進式洩漏。

用戶帳戶控制

• 請勿使用使用者帳戶控制 （UAC） 提高許可權 UI 作為確認的替代專案。 如果動作需要確認，請使用個別對話方塊。 在 提高許可權 UI期間，用戶必須專注於他們是否開始工作，以及程式是否值得信任。
• 在提高許可權 UI 之前顯示確認。 這麼做可消除不必要的提高許可權。

發簡訊

常規

• 拿掉多餘的文字。 尋找標題、主要指示、補充指示、內容區域、命令鏈接和認可按鈕中的備援文字。 一般而言，在指示和互動式控件中保留全文檢索，並從其他地方移除任何備援。
• 請勿在文字中使用「警告」或「警告」。 如果使用者需要謹慎作，請改用警告圖示來指出這一點。

不正確：

磁碟區格式確認

在此範例中，「警告」一詞是不必要的。

標題

• 使用標題來識別確認的來源命令或功能。 異常：
  • 如果確認是由許多不同的命令顯示，請考慮改用程式名稱。
  • 如果該標題會備援或與主要指令混淆，請改用程序名稱。

不過，如果確認是來自長時間執行的工作，而且可能會在工作啟動之後顯示良好，請一律使用 命令或功能來清楚識別內容。

• 不要使用標題來說明在對話中要做什麼， 這是主要指示的目的。
• 如果新增清楚，請使用 Confirm 一詞來啟動標題。
• 針對具風險的動作確認，您可以新增涉及額外強調的物件名稱。

在此範例中，要格式化的磁碟驅動器會包含在標題中。

• 使用 標題樣式大寫，而不結束標點符號。

主要指示

• 確認的主要指示是以其設計模式為基礎：

  模式	主要指示
  非預期的結果確認	表示非預期的結果。 例外狀況： 如果詢問使用者是否想要繼續的問題明確表示非預期的結果，請改為詢問問題。 在此範例中，要求用戶繼續充分傳達動作的後果。
  所有其他	詢問單一問題，以判斷使用者是否要繼續。

• 僅簡潔地使用單一完整句子。 將主要指示移除至基本資訊。 如果您必須進一步說明任何內容，請使用補充指示。

• 如果涉及物件，請指定其完整名稱。

• 使用正片語。 正面片語讓使用者更容易瞭解。

正確：

您要啟用檔案和印表機共用嗎？

不正確：

您要停用檔案和印表機共用嗎？

不過，即使命令是負片語，片語也必須符合相關聯的命令;因此，例如，使用 disable 來確認 Disable 命令。

• 雖然片語沒有嚴格的規則，但 這些常見的確認片語具有指示的內涵：

  短語	內涵
  您確定要 [執行動作] 嗎？	確認使用者要求的直接結果。
  您要 [執行動作] 嗎？	確認使用者要求的副作用。
  您要 [選取結果] 嗎？	需要澄清。
  [執行動作]？	沒有內涵。

• 針對有風險的動作確認，請使用永久字詞來指出無法復原動作。

永久刪除確認的

在此範例中，「永久」表示無法復原動作。

• 使用 句子樣式大寫。

補充指示

• 確認的補充指示是以其設計模式為基礎：

標籤	價值
模式	補充指示
非預期的結果確認	詢問單一問題，以判斷使用者是否要繼續。
所有其他	說明使用者可能不想繼續的任何非明顯原因。 這類原因包括： 可能遺失下列一或多個專案： 寶貴的資產，例如數據遺失或財務損失。 系統存取或完整性。 隱私權或機密資訊的控制權。 無法復原的動作。

• 請勿以稍微不同的措辭重複主要指令。 相反地，如果沒有更多要新增，請省略補充指示。
• 針對非預期的後果確認，請考慮使用字詞來簡潔地指出，如果使用者忽略主要指示，則沒有理由繼續。 如需詳細資訊，請參閱設計概念。
• 使用完整的句子、句子樣式大寫和結尾標點符號。

文件

參考確認時：

• 如果標題是確認的特定標題，請參閱其標題的確認（也就是，不是程式名稱）：否則，請依其主要指示加以參考。
• 如有必要，您可能會將確認對話方塊視為訊息。
• 使用確切的文字，包括其大寫。
• 可能的話，請使用粗體格式化文字。 否則，只有在需要防止混淆時，才將文字放在引號中。

範例：在 [複製檔案] 訊息中，按兩下較新的檔案。