Windows 7 中的錯誤訊息

注意

此設計指南是針對 Windows 7 所建立，尚未針對較新版本的 Windows 進行更新。 大部分的指導方針仍以原則方式套用，但簡報和範例不會反映 我們目前的設計指導方針。

Windows 7 中的錯誤訊息會警示使用者已發生的問題。 相反地，警告訊息會警示使用者未來可能造成問題的條件。 您可以使用強制回應對話方塊、就地訊息、通知或氣球來呈現錯誤訊息。

典型的強制回應錯誤訊息。

有效的錯誤訊息會通知使用者發生問題、說明發生原因，並提供解決方案，讓使用者可以修正問題。 使用者應該執行動作，或因錯誤訊息而變更其行為。

撰寫良好的實用錯誤訊息對於品質使用者體驗至關重要。 撰寫不佳的錯誤訊息會導致產品滿意度偏低，而且是可避免技術支援成本的前置原因。 不必要的錯誤訊息會中斷使用者的流程。

注意： 與 對話方塊、 警告訊息、 確認、 標準圖示、 通知和 版面配置 相關的指導方針會顯示在不同的文章中。

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

若要決定使用時機，請考量下列問題：

• 使用者介面 (UI 是否) 呈現已經發生的問題？ 如果沒有，則訊息不是錯誤。 如果使用者收到未來可能造成問題的條件警示，請使用警告訊息。
• 問題是否可以避免，而不會造成混淆？ 如果是，請改為防止問題。 例如，使用限制為有效值的控制項，而不是使用可能需要錯誤訊息的未限制控制項。 此外，按一下時停用控制項會導致錯誤，只要控制項停用的原因就明顯。
• 是否可以自動校正問題？ 如果是，請處理問題並隱藏錯誤訊息。
• 使用者是否可能會執行動作或變更其行為，因為訊息的結果？ 如果沒有，則條件不會證明中斷使用者，因此最好隱藏錯誤。
• 當使用者主動使用其他程式時，問題是否相關？ 如果是，請考慮使用 通知區域圖示來顯示問題。
• 問題是否與目前使用者活動無關，是否需要立即使用者動作，而且使用者可以自由忽略它嗎？ 如果是，請改用 動作失敗通知 。
• 問題與主要視窗中背景工作的狀態有關嗎？ 如果是，請考慮使用 狀態列來顯示問題。
• 主要目標使用者是 IT 專業人員嗎？ 如果是，請考慮使用替代的意見反應機制，例如 記錄檔 專案或電子郵件警示。 IT 專業人員強烈建議記錄檔用於非重要資訊。

設計概念

錯誤訊息不佳的特性

應該不會令人意外，許多令人不小心、無説明且撰寫不佳的錯誤訊息。 由於錯誤訊息通常會使用強制回應對話方塊來呈現，因此會中斷使用者的目前活動，並要求在允許使用者繼續之前予以認可。

問題的一部分是有許多方式可以執行錯誤。 請考慮來自錯誤訊息大廳的下列範例：

不必要的錯誤訊息

不正確：

來自 Windows XP 的這個範例可能是最差的錯誤訊息。 它表示程式無法啟動，因為 Windows 本身正在關機。 使用者無法對此執行任何動作，甚至想要在使用者選擇關閉 Windows 之後， (執行此) 動作。 而且藉由顯示此錯誤訊息，Windows 會防止自己關閉！

問題： 錯誤訊息本身是問題。 除了關閉錯誤訊息之外，使用者不會執行任何動作。

前置原因： 報告所有錯誤案例，不論使用者的目標或觀點為何。

建議的替代方法： 不要回報使用者不關心的錯誤。

「成功」錯誤訊息

不正確：

此錯誤訊息是由使用者選擇不要在程式移除之後立即重新開機 Windows 所產生。 從使用者的觀點來看，程式移除成功。

問題： 使用者的觀點沒有錯誤。 除了關閉錯誤訊息之外，使用者不會執行任何動作。

前置原因： 工作已從使用者的觀點成功完成，但從卸載程式的觀點來看失敗。

建議的替代方法： 請勿針對使用者認為可接受的條件回報錯誤。

完全無用的錯誤訊息

不正確：

使用者瞭解發生錯誤，但不知道錯誤是什麼或該怎麼做。 否，沒關係！

問題： 錯誤訊息不會提供特定問題，而且使用者無法執行任何動作。

前置原因： 程式最有可能的錯誤處理不佳。

建議的替代方法： 在程式中設計良好的錯誤處理。

無法理解的錯誤訊息

不正確：

在此範例中，問題陳述清楚，但補充說明完全不小心。

問題： 問題陳述或解決方案不合理。

前置原因： 從程式碼的觀點來說明問題，而不是使用者。

建議的替代方法： 撰寫目標使用者可以輕鬆地瞭解的錯誤訊息文字。 提供使用者實際可執行檔解決方案。 設計程式的錯誤訊息體驗沒有程式設計人員在現場撰寫錯誤訊息。

過度分配的錯誤訊息

不正確：

在此範例中，錯誤訊息顯然會嘗試說明每個疑難排解步驟。

問題： 太多資訊。

前置原因： 提供太多詳細資料，或嘗試在錯誤訊息中說明複雜的疑難排解程式。

建議的替代方法： 避免不必要的詳細資料。 此外，請避免疑難排解員。 如果需要疑難排解員，請專注于最可能的解決方案，並透過連結至 [說明] 中的適當主題來說明其餘部分。

不必要的嚴重錯誤訊息

不正確：

程式無法尋找物件很難聽起來很嚴重。 假設它是重大的，為什麼回應沒問題？

問題： 程式的語調不必要或非常嚴重。

前置原因： 問題是因為從程式的觀點來看，出現嚴重錯誤的錯誤。

建議的替代方法： 根據使用者的觀點仔細選擇語言。

歸責使用者的錯誤訊息

不正確：

為什麼讓使用者覺得是犯罪？

問題： 錯誤訊息會以要求使用者進行錯誤的方式進行片語。

前置原因： 不區分的片語著重于使用者的行為，而不是問題。

建議的替代方法： 將焦點放在問題上，而不是視需要使用被動語音的使用者動作。

Silly 錯誤訊息

不正確：

在此範例中，問題聲明相當具名，而且不會提供任何解決方案。

問題： 錯誤訊息語句，這些語句是無聲或非 sequitor。

前置原因： 建立錯誤訊息而不需注意其內容。

建議的替代方法： 讓寫入器製作並檢閱您的錯誤訊息。 檢閱錯誤時，請考慮內容和使用者的想法。

程式設計人員錯誤訊息

不正確：

在此範例中，錯誤訊息指出程式中有錯誤。 此錯誤訊息只對程式設計人員有意義。

問題： 旨在協助程式開發人員發現 Bug 的訊息會保留在程式的發行版本中。 這些錯誤訊息對使用者沒有意義或值。

前置原因： 使用一般 UI 自行建立訊息的程式設計人員。

建議的替代方法： 開發人員必須有條件地編譯所有這類訊息，使其自動從產品的發行版本中移除。 請勿浪費時間嘗試對使用者進行類似這種理解的錯誤，因為其唯一的物件是程式設計人員。

錯誤訊息呈現不佳

不正確：

此範例有許多常見的簡報錯誤。

問題： 在錯誤訊息簡報中取得所有詳細資料錯誤。

前置原因： 不知道並套用錯誤訊息指導方針。 不使用寫入器和編輯器來建立和檢閱錯誤訊息。

錯誤處理的本質是讓其中許多錯誤很容易發生。 請注意，大部分的錯誤訊息可能都可能是聖地大會的名詞。

良好錯誤訊息的特性

相較于先前的錯誤範例，良好的錯誤訊息有：

• 問題。 指出發生問題。
• 原因。 說明發生問題的原因。
• 方案。 提供解決方案，讓使用者可以修正問題。

此外，良好的錯誤訊息會以下列方式呈現：

• 相關。 訊息會顯示使用者關心的問題。
• 可行。 使用者應該執行動作或變更其行為，作為訊息的結果。
• 使用者置中。 此訊息會根據目標使用者動作或目標來描述問題，而不是程式碼不滿意的問題。
• 簡短。 訊息盡可能短，但不會縮短。
• [清除]。 此訊息使用純文字，讓目標使用者可以輕鬆地瞭解問題和解決方案。
• 特定。 此訊息描述使用特定語言的問題，並提供涉及之物件的特定名稱、位置和值。
• 禮貌。 使用者不應該受到責責或覺得很錯錯。
• 罕見。 不常顯示。 經常顯示的錯誤訊息是錯誤的設計符號。

藉由將錯誤處理體驗設計為具有這些特性，您可以將程式的錯誤訊息保留在 [錯誤訊息大廳] 中。

避免不必要的錯誤訊息

錯誤訊息通常不是錯誤訊息。 許多錯誤可以透過更好的設計來避免，而且錯誤訊息的替代方式通常更好。 通常最好避免發生錯誤，而不是報告錯誤。

要避免的最明顯錯誤訊息是無法採取動作的錯誤訊息。 如果使用者可能會關閉訊息而不執行或變更任何動作，請省略錯誤訊息。

有些錯誤訊息可以排除，因為它們不是使用者的觀點的問題。 例如，假設使用者嘗試刪除已在刪除過程中的檔案。 雖然這可能是來自程式碼觀點的非預期案例，但使用者不會考慮此錯誤，因為達到所需的結果。

不正確：

由於動作從使用者的觀點來看成功，因此應該排除此錯誤訊息。

例如，假設使用者明確取消工作。 針對使用者的觀點，下列條件不是錯誤。

不正確：

由於動作從使用者的觀點來看成功，因此也應該排除此錯誤訊息。

有時候可以藉由專注于使用者的目標而非技術來消除錯誤訊息。 如此一來，請重新考慮錯誤是什麼。 使用者的目標或您的程式是否能夠滿足這些目標的問題？ 如果使用者的動作在真實世界中很合理，在軟體中也應該合理。

例如，假設在電子商務程式中，使用者嘗試使用搜尋來尋找產品，但常值搜尋查詢沒有相符專案，而且所需的產品已不足。 技術上，這是錯誤，但不會提供錯誤訊息，程式可以：

• 繼續搜尋最符合查詢的產品。
• 如果搜尋有明顯的錯誤，請自動建議更正的查詢。
• 自動處理常見的問題，例如拼字錯誤、替代拼字，以及不相符的複數和動詞案例。
• 指出產品何時會存貨。

只要使用者的要求合理，設計良好的電子商務計畫應該傳回合理的結果而非錯誤。

避免錯誤訊息的另一個絕佳方式是避免第一次發生問題。 您可以透過下列方式防止錯誤：

• 使用受限制的控制項。 使用限制為有效值的控制項。 清單、滑杆、核取方塊、選項按鈕和日期和時間選擇器等控制項受限於有效值，而文字方塊通常不是而且可能需要錯誤訊息。 不過，您可以將文字方塊限制為只接受特定字元，並接受最大字元數。
• 使用受限制的互動。 針對拖曳作業，允許使用者只卸載有效的目標。
• 使用停用的控制項和功能表項目。 當使用者可以輕鬆地推斷控制項或功能表項目停用的原因時，請停用控制項和功能表項目。
• 提供良好的預設值。 如果使用者可以接受預設值，則不太可能發生輸入錯誤。 即使使用者決定變更值，預設值仍可讓使用者知道預期的輸入格式。
• 讓事情正常運作。 如果使用者不必要或自動執行工作，則較不可能會犯錯。 或者，如果使用者犯了小錯誤，但其意圖很明顯，則會自動修正問題。 例如，您可以自動校正次要格式問題。

提供必要的錯誤訊息

有時候，您真的需要提供錯誤訊息。 使用者發生錯誤、網路和裝置停止運作、找不到或修改物件、無法完成工作，而且程式有 Bug。 在理想情況下，這些問題會較不常發生，例如，我們可以設計軟體來防止許多類型的使用者錯誤，但無法實際防止所有這些問題。 當其中一個問題確實發生時，有用的錯誤訊息會讓使用者快速回到自己的腳上。

常見的信念是錯誤訊息是最差的使用者體驗，應該避免所有成本，但表示使用者混淆是最差的體驗，而且應該避免所有成本。 有時候，成本是有用的錯誤訊息。

請考慮停用的控制項。 在大部分情況下，停用控制項的原因很明顯，因此停用控制項是避免錯誤訊息的絕佳方式。 不過，如果控制項停用的原因並不明顯，該怎麼辦？ 使用者無法繼續，而且沒有意見反應可判斷問題。 現在使用者停滯，必須推論問題或取得技術支援。 在這種情況下，最好讓控制項保持啟用狀態，並改為提供有用的錯誤訊息。

不正確：

為什麼這裡停用 [下一步] 按鈕？ 最好讓它保持啟用狀態，並藉由提供有用的錯誤訊息來避免使用者混淆。

如果您不確定是否應該提供錯誤訊息，請從撰寫您可能會提供的錯誤訊息開始。 如果使用者可能執行動作或變更其行為，請提供錯誤訊息。 相較之下，如果使用者可能關閉訊息而不執行或變更任何動作，請省略錯誤訊息。

設計良好的錯誤處理

雖然製作良好的錯誤訊息文字可能很困難，但有時不可能，而不需要程式良好的錯誤處理支援。 請考慮此錯誤訊息：

不正確：

可能的原因是，問題真的是未知的，因為程式的錯誤處理支援缺少。

雖然這是撰寫得很差的錯誤訊息，但更可能反映基礎程式碼缺少良好的錯誤處理，但沒有任何已知問題的特定資訊。

若要建立特定、可採取動作、使用者中心的錯誤訊息，程式的錯誤處理常式代碼必須提供特定的高階錯誤資訊：

• 每個問題都應該指派唯一的錯誤碼。
• 如果問題有數個原因，程式應該盡可能判斷特定原因。
• 如果問題有參數，則必須維護參數。
• 低階問題必須以足夠高階的方式處理，以便從使用者的觀點呈現錯誤訊息。

良好的錯誤訊息不只是 UI 問題，它們是軟體設計問題。 良好的錯誤訊息體驗不是稍後可以攔截的內容。

疑難排解 (以及如何避免)

使用單一錯誤訊息回報數個不同原因的問題時，針對結果進行疑難排解。

不正確：

正確：

使用單一錯誤訊息回報數個問題時，針對結果進行疑難排解。

在下列範例中，無法移動專案，因為該專案已經移動或刪除，或拒絕存取。 如果程式可以輕鬆地判斷原因，為什麼會對使用者造成負擔來判斷特定原因？

不正確：

正確，這是哪一項？ 現在使用者必須進行疑難排解。

程式可以判斷存取是否遭到拒絕，因此應該以特定的錯誤訊息回報此問題。

正確：

有特定原因，就不需要進行疑難排解。

只有在無法判斷特定原因時，才使用具有多個原因的訊息。 在此範例中，程式很難判斷專案是否已移動或刪除，因此可能會在這裡使用具有多個原因的單一錯誤訊息。 不過，使用者不太可能在意，例如，他們無法移動已刪除的檔案。 針對這些原因，甚至不需要錯誤訊息。

處理未知的錯誤

在某些情況下，您真正不會知道問題、原因或解決方案。 如果隱藏錯誤並不明智，最好是預先瞭解缺少資訊，而不是呈現問題、原因或可能不正確的解決方案。

例如，如果您的程式有未處理的例外狀況，則適用下列錯誤訊息：

如果您無法隱藏未知的錯誤，最好是預先瞭解缺少資訊。

另一方面，如果可能大部分時間都很有説明，請提供特定且可採取動作的資訊。

如果網路連線通常發生問題，這個錯誤訊息適用于未知的錯誤。

判斷適當的訊息類型

視強調和片語而定，某些問題可能會顯示為錯誤、警告或資訊。 例如，假設網頁無法根據目前的 Windows Internet Explorer 設定載入未簽署的 ActiveX 控制項：

• 錯誤。 「此頁面無法載入未簽署的 ActiveX 控制項。」 (片語為現有問題。)
• 警告。 「此頁面可能無法如預期般運作，因為 Windows Internet Explorer 未設定為載入未簽署的 ActiveX 控制項。」或「允許此頁面安裝未簽署的 ActiveX 控制項？ 從不受信任的來源這麼做可能會危害您的電腦。」 (這兩個片語都視為可能導致未來問題的條件。)
• 資訊。 「您已將 Windows Internet Explorer 設定為封鎖未簽署的 ActiveX 控制項」 (Phrased 為 fact.)

若要判斷適當的訊息類型，請專注于使用者需要知道或採取行動之問題最重要的層面。 一般而言，如果問題封鎖使用者繼續，您應該將它顯示為錯誤;如果使用者可以繼續，請將它呈現為警告。 根據該焦點製作 主要指令 或其他對應的文字，然後選擇圖示 (標準 或其他符合文字的) 。 主要指令文字和圖示應該一律相符。

錯誤訊息簡報

Windows 程式中大部分的錯誤訊息都是使用強制回應對話方塊來呈現 (，如同本文) 中大部分的範例，但還有其他選項：

• 就地
• 汽球
• 通知
• 通知區域圖示
• 狀態列
• 針對以 IT 專業人員為目標的錯誤記錄檔 ()

將錯誤訊息放在強制回應對話方塊中的好處是要求使用者立即注意和通知。 不過，如果不需要注意，這也是其主要缺點。

您真的需要中斷使用者，才能按一下 [關閉] 按鈕嗎？ 如果沒有，請考慮使用強制回應對話方塊的替代方案。

當使用者在繼續之前必須立即認可問題，但通常是不佳的選擇時，強制回應對話方塊是很好的選擇。 一般而言，您應該偏好使用最輕量型的簡報，以妥善執行工作。

避免過度認可

一般而言， 使用者不會讀取，他們會掃描。 文字越多，文字掃描越困難，使用者可能完全不會讀取文字。 因此，請務必減少文字到其基本資訊，並在必要時使用漸進式揭露和說明連結來提供其他資訊。

有許多極端的範例，但讓我們看看一個更典型的範例。 下列範例具有良好錯誤訊息的大部分屬性，但其文字並不簡潔，而且需要動機才能閱讀。

不正確：

此範例是良好的錯誤訊息，但過度認可。

此文字真正說出什麼？ 就像這樣：

正確：

此錯誤訊息基本上具有相同的資訊，但更簡潔。

藉由使用 [說明] 提供詳細資料，此錯誤訊息具有 反轉的金字塔圖呈現樣式 。

如需過度通訊的指導方針和範例，請參閱 使用者介面文字。

如果您只執行八件事

1. 設計程式以進行錯誤處理。
2. 請勿提供不必要的錯誤訊息。
3. 藉由提供必要的錯誤訊息來避免使用者混淆。
4. 請確定錯誤訊息提供問題、原因和解決方案。
5. 請確定錯誤訊息與相關、可採取動作、簡短、清楚、特定、合理且罕見。
6. 從使用者的觀點設計錯誤訊息，而不是程式的觀點。
7. 請避免在疑難排解時涉及使用者，針對每個可偵測的原因使用不同的錯誤訊息。
8. 使用最輕量表示方法，以妥善執行作業。

使用模式

錯誤訊息有數種使用模式：

標籤	值
系統問題 作業系統、硬體裝置、網路或程式失敗或未處於執行工作所需的狀態。	使用者可以解決許多系統問題： 您可以開啟裝置、重新連線裝置，以及插入媒體來解決裝置問題。 藉由檢查實體網路連線，以及執行 網路診斷和修復，即可解決網路問題。 您可以藉由變更程式選項或重新開機程式來解決程式問題。 在此範例中，程式找不到執行使用者工作的相機。 在此範例中，必須開啟執行工作所需的功能。
檔案問題 找不到使用者起始之工作所需的檔案或資料夾、已在使用中，或沒有預期的格式。	在此範例中，找不到檔案或資料夾，因此無法刪除。 在此範例中，程式不支援指定的檔案格式。
安全性問題 使用者沒有存取資源的許可權，或有足夠的許可權可執行使用者起始的工作。	在此範例中，使用者沒有存取資源的許可權。 在此範例中，使用者沒有執行工作的許可權。
工作問題 執行使用者所起始的工作有特定問題， (系統、找不到檔案、檔案格式或安全性問題) 。	在此範例中，剪貼簿資料無法貼到 Paint 中。 在此範例中，使用者無法安裝軟體升級。
使用者輸入問題 使用者輸入的值不正確或與其他使用者輸入不一致。	在此範例中，使用者輸入了不正確的時間值。 在此範例中，使用者輸入的格式不正確。

指導方針

簡報

• 每當適當時，請使用工作對話方塊 來達成一致的外觀和版面配置。 工作對話方塊需要 Windows Vista 或更新版本，因此不適合舊版 Windows。 如果您必須使用訊息方塊，請將主要指令與補充指令分開，並加上兩個分行符號。

使用者輸入錯誤

• 盡可能避免或減少使用者輸入錯誤，方法是：
  • 使用限制為有效值的控制項。
  • 按一下時停用控制項和功能表項目會導致錯誤，只要控制項或功能表項目停用的原因就明顯。
  • 提供良好的預設值。

不正確：

在此範例中，未受限制的文字方塊用於限制輸入。 請改用滑杆。

• 針對內容使用者輸入問題，使用無模式錯誤處理 (就地錯誤或球) 。
• 在文字方塊或文字方塊失去焦點之後，針對偵測到的非重要單一點使用者輸入問題使用方塊。方塊 不需要可用的螢幕空間，或顯示就地訊息所需的動態配置。 一次只顯示一個方塊。 因為問題並不重要，所以不需要任何錯誤圖示。 按一下時、問題解決時，或逾時之後，方塊會消失。

在此範例中，批註方塊表示在控制項中仍發生輸入問題。

• 針對延遲的錯誤偵測使用就地錯誤， 通常是按一下認可按鈕找到的錯誤。 (請勿針對立即認可的設定使用 就地錯誤 。) 一次可能會有多個就地錯誤。 使用一般文字和 16x16 圖元錯誤圖示，盡可能將它們直接放在問題旁邊。 除非使用者認可且找不到其他錯誤，否則就地錯誤不會消失。

在此範例中，就地錯誤是用於按一下認可按鈕找到的錯誤。

• 針對所有其他問題使用強制回應錯誤處理 (工作對話方塊或訊息方塊) ， 包括涉及多個控制項的錯誤，或是按一下認可按鈕找到非內容或非輸入錯誤的錯誤。
• 回報使用者輸入問題時，請使用不正確的資料，將輸入焦點設定為第一個控制項。 如有必要，將控制項捲動至檢視。 如果控制項是文字方塊，請選取整個內容。 它應該一律很明顯地指出錯誤訊息。
• 請勿清除不正確的輸入。 相反地，請保留它，讓使用者可以看見並更正問題，而不需開始。
  • 例外： 清除不正確的密碼和 PIN 文字方塊，因為使用者無法有效地更正遮罩輸入。

疑難排解

• 避免建立疑難排解問題。 請勿依賴單一錯誤訊息來回報有數個不同可偵測原因的問題。
• 針對每個可偵測的原因，請使用不同的錯誤訊息 (通常有不同的補充指示) 。 例如，如果因為數個原因而無法開啟檔案，請針對每個原因提供個別的補充指示。
• 只有在無法判斷特定原因時，才使用具有多個原因的訊息。 在此情況下，請依修正問題的可能性來呈現解決方案。 這麼做可協助使用者更有效率地解決問題。

圖示

• 強制回應錯誤訊息對話方塊沒有標題列圖示。 標題列圖示是用來做為主要視窗與次要視窗之間的視覺區別。

• 使用錯誤圖示。 例外狀況：

  • 如果錯誤是使用強制回應對話方塊或批註方塊顯示的使用者輸入問題，請勿使用圖示。 這樣做是與鼓勵的 Windows 語調相反。 不過，就地錯誤訊息應該使用小型錯誤圖示， (16x16 圖元) 明確地將它們識別為錯誤訊息。

    

    

    在這些範例中，使用者輸入問題不需要錯誤圖示。

    

    在此範例中，就地錯誤訊息需要一個小錯誤圖示，才能清楚地將其識別為錯誤訊息。

• 如果問題適用于具有圖示 (，而不是使用者輸入問題) 的功能，您可以使用功能圖示搭配錯誤重迭。 如果您這樣做，也請使用功能名稱作為錯誤的主體。

  

  在此範例中，功能圖示有錯誤重迭，而功能是錯誤的主旨。

• 請勿針對錯誤使用警告圖示。 這通常是為了讓簡報感覺較不嚴重。 錯誤不是警告。

  不正確：

  

  在此範例中，警告圖示不正確地用來使錯誤感覺較不嚴重。

如需更多指導方針和範例，請參閱 標準圖示。

漸進式揭露

• 使用 [顯示/隱藏詳細資料漸進式揭露] 按鈕，隱藏錯誤訊息中的進階或詳細資訊。 這麼做可簡化一般使用方式的錯誤訊息。 請勿隱藏所需的資訊，因為使用者可能找不到它。

在此範例中，漸進式揭露按鈕可協助使用者向下切入，以取得更多詳細資料，或如果不想這麼做，請簡化 UI。

• 請勿使用 [顯示/隱藏詳細資料]，除非確實有更多詳細資料。 不要只以更詳細的格式重新整理現有的資訊。
• 請勿使用顯示/隱藏詳細資料來顯示說明資訊。 請改用說明連結。

如需標籤指導方針，請參閱 漸進式揭露控制項。

不要再顯示此訊息

• 如果錯誤訊息需要此選項，請重新考慮錯誤及其頻率。 如果其具有良好錯誤的所有特性， (相關、可採取動作且不常) ，則使用者不應該隱藏錯誤。

如需更多指導方針，請參閱 對話方塊。

預設值

• 選取最安全、最不具破壞性或最安全的回應作為預設值。 如果安全性不是因素，請選取最可能或方便的命令。

說明

• 設計錯誤訊息以避免需要說明。 使用者通常不需要讀取外部文字來瞭解並解決問題，除非解決方案需要數個步驟。
• 請確定 [說明] 內容相關且有用。 它不應該是錯誤訊息的詳細資訊，而是應該包含超出錯誤訊息範圍的實用資訊，例如在未來避免問題的方法。 請勿只提供說明連結，因為您可以這麼做。
• 使用特定、簡潔且相關的說明連結來存取說明內容。 請勿針對此目的使用命令按鈕或漸進式洩漏。
• 對於您無法進行特定且可採取動作的錯誤訊息，請考慮提供線上說明內容的連結。 如此一來，您可以為使用者提供可在程式發行之後更新的其他資訊。

如需更多指導方針，請參閱 說明。

錯誤碼

• 對於您無法進行特定且可採取動作的錯誤訊息，或它們受益于 [說明]，請考慮也提供錯誤碼。 使用者通常會使用這些錯誤碼來搜尋網際網路以取得其他資訊。
• 請一律提供問題和解決方案的文字描述。 請勿只依賴錯誤碼來達到此目的。

不正確：

在此範例中，錯誤碼會用來取代解決方案文字。

• 為每個不同原因指派唯一的錯誤碼。 這樣做可避免進行疑難排解。
• 選擇可在網際網路上輕鬆搜尋的錯誤碼。 如果您使用 32 位代碼，請使用具有前置 「0x」 和大寫字元的十六進位標記法。

正確：

1234

0xC0001234

不正確：

-1

-67113524

• 使用 [顯示/隱藏詳細資料] 來顯示錯誤碼。 片語為錯誤碼： <error code> 。

在此範例中，錯誤碼可用來補充可受益于進一步資訊的錯誤訊息。

音效

• 請勿隨附具有音效或嗶聲的錯誤訊息。 這麼做是 jarring 和 unnecessary。
  • 例外： 如果問題對電腦作業很重要，且使用者必須立即採取動作，以避免嚴重後果，則播放重大停止音效。

Text

一般

• 移除備援文字。 在標題、主要指示、補充指示、命令連結和認可按鈕中尋找。 一般而言，在指示和互動式控制項中保留全文檢索，並從其他位置移除任何備援。
• 使用使用者中心說明。 根據使用者動作或目標來描述問題，而不是軟體不滿意的問題。 使用目標使用者瞭解和使用的語言。 避免技術術語。

不正確：

正確：

在這些範例中，正確的版本會說出使用者的語言，而不正確的版本則過度技術。

• 請勿使用下列單字：
  • 錯誤、失敗 (改用問題)
  • 無法使用 (無法改為使用)
  • 不合法、無效、不正確的 (改用不正確)
  • 中止、終止、終止 (請改用 stop)
  • 嚴重、嚴重 (改用嚴重)

這些詞彙不必要，與 Windows 的鼓勵語調相反。 正確使用時，錯誤圖示會充分傳達發生問題。

不正確：

正確：

在不正確的範例中，「重大」和「失敗」詞彙是不必要的。

• 請勿使用片語來責指使用者或表示使用者錯誤。 避免在片語中使用您和您的 。 雖然使用中語音通常是慣用的，但當使用者是主旨時，請使用被動語音，而且在使用中語音時，可能會對錯誤感到受到責責。

不正確：

正確：

不正確的範例會使用作用中的語音來歸責使用者。

• 具體。 避免模糊的文字，例如語法錯誤和不合法的作業。 提供涉及之物件的特定名稱、位置和值。

不正確：

找不到檔案。

磁碟已滿。

超出範圍的值。

字元無效。

裝置無法使用。

使用特定名稱、位置和值，這些問題會更容易解決。

• 請勿提供可能不太可能發生的問題、原因或嘗試特定解決方案。 除非可能正確，否則請勿提供問題、原因或解決方案。 例如，比起可能不正確的錯誤，最好是發生未知的錯誤。
• 請避免「請」這個字， 除非要求使用者執行不方便 (，例如等待) 或軟體對情況造成責任。

正確：

Windows 將檔案複製到您的電腦時，請稍候。

• 只有在導致使用者 (嚴重問題的錯誤訊息中，才使用「很抱歉」這個字 ，例如資料遺失或無法使用電腦) 。 例如，如果使用者需要等候) 找到網路連線，則不要在程式正常運作期間發生問題， (。

正確：

很抱歉，Fabrikam Backup 偵測到無法復原的問題，並已關閉以保護您電腦上的檔案。

• 請參閱使用其簡短名稱的產品。 請勿使用完整的產品名稱或商標符號。 除非使用者將公司名稱與產品建立關聯，否則請勿包含公司名稱。 請勿包含程式版本號碼。

不正確：

正確：

在不正確的範例中，會使用完整的產品名稱和商標符號。

• 在物件名稱周圍使用雙引號。 這麼做可讓文字更容易剖析，並避免潛在的令人不快的語句。
  • 例外： 完整檔案路徑、URL 和功能變數名稱不需要以雙引號括住。

正確：

在此範例中，如果物件名稱不是以引號括住，則錯誤訊息會令人混淆。

• 避免使用物件名稱啟動句子。 這樣做通常很難剖析。
• 請勿將所有大寫字母使用驚嘆號或單字。 驚嘆號和大寫字母會讓您覺得您正在使用者說出。

如需更多指導方針和範例，請參閱 樣式和音調。

標題

• 使用標題來識別錯誤的來源命令或功能。 例外狀況：
  • 如果許多不同的命令顯示錯誤，請考慮改用程式名稱。
  • 如果該標題會重複或與主要指令混淆，請改用程式名稱。
• 請勿使用標題來說明或摘要 主要指示的目的問題。

不正確：

在此範例中，標題不正確地用來說明問題。

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

主要指示

• 使用主要指示，以清楚、純文字的特定語言來描述問題。
• 簡潔地只使用單一的完整句子。 將主要指示向下剖析為基本資訊。 如果您的程式或使用者是程式或使用者，您可以讓主旨保持隱含。 如果可以簡潔地這麼做，請包含問題的原因。 如果您必須進一步說明任何內容，請使用補充指示。

不正確：

在此範例中，整個錯誤訊息會放在主要指令中，使其難以閱讀。

• 如果涉及物件，請指定其名稱。
• 避免將完整檔案路徑和 URL 放在主要指令中。 相反地，請使用簡短名稱 (，例如檔案名) ，並將完整名稱放在 (，例如補充指示中的檔案路徑) 。 不過，如果錯誤訊息不需要補充指示，您可以將單一完整檔案路徑或 URL 放在主要指令中。

在此範例中，只有檔案名位於主要指令中。 完整路徑位於補充指示中。

• 如果內容明顯，請勿提供完整的檔案路徑和 URL。

在此範例中，使用者正在從 Windows 檔案總管重新命名檔案。 在此情況下，不需要完整的檔案路徑，因為從內容中很明顯。

• 盡可能使用現成時態。
• 使用句型大寫。
• 如果指令是 語句，請勿包含最終句點。 如果指示是問題，請包含最終問號。

主要指示範本

雖然片語沒有嚴格的規則，但請盡可能嘗試使用下列主要指示範本：

• [選擇性主體名稱] 無法 [執行動作]
• [選擇性主體名稱] 無法 [執行動作]，因為 [reason]
• [選擇性主體名稱] 無法 [執行動作] 至 「[物件名稱]」
• [選擇性主體名稱] 無法 [執行動作] 為 「[object name]」，因為 [reason]
• 沒有足夠的 [resource] 無法 [執行動作]
• [主體名稱] 沒有 [目的] 所需的 [物件名稱]
• [裝置或設定] 已關閉，因此 [不想要的結果]
• [裝置或設定] 未 [可用 | 找到 | 已開啟 | 已啟用]
• 「[物件名稱]」 目前無法使用
• 使用者名稱或密碼不正確
• 您沒有存取 「[物件名稱]」 的許可權
• 您沒有 [執行動作] 的許可權
• [程式名稱] 發生嚴重問題，必須立即關閉

當然，視需要進行變更，讓主要指示以文法正確且符合主要指示指導方針。

補充指示

• 使用補充指示來：
  • 提供問題的其他詳細資料。
  • 說明問題的原因。
  • 列出使用者可以採取以修正問題的步驟。
  • 提供量值以防止問題重新發生。
• 可能的話，建議實用的解決方案，讓使用者可以修正問題。 不過，請確定建議的解決方案可能會解決問題。 建議可能但不可能的解決方案，不要浪費使用者的時間。

不正確：

在此範例中，雖然問題及其建議的解決方案可能，但不太可能。

• 如果問題是使用者輸入的值不正確，請使用補充指示來說明正確的值。 使用者不需要從另一個來源判斷這項資訊。
• 如果無法從問題陳述中推論，請勿提供解決方案。

在此範例中，不需要補充指示;解決方案可以從問題語句中簡單推論。

• 如果解決方案有多個步驟，請依照步驟完成的順序呈現這些步驟。 不過，請避免使用多步驟解決方案，因為使用者難以記住兩或三個以上的簡單步驟。 如果需要更多步驟，請參閱適當的說明主題。
• 保持補充指示簡潔。 只提供使用者需要知道的內容。 省略不必要的詳細資料。 目標為長度中等的三個句子。
• 若要避免使用者在執行指示時發生錯誤，請將結果放在動作之前。

正確：

若要重新開機 Windows，請按一下 [確定]。

不正確：

按一下 [確定] 重新開機 Windows。

在不正確的範例中，使用者更可能會意外按一下 [確定]。

• 除非這樣做是問題最可能的解決方案之一，否則不建議連絡系統管理員。 針對真正只能由系統管理員解決的問題，保留這類解決方案。

不正確：

在此範例中，最有可能是使用者網路連線的問題，因此不值得連絡系統管理員。

• 不建議連絡技術支援。 連絡技術支援以解決問題的選項一律可供使用，而且不需要透過錯誤訊息升級。 相反地，請專注于撰寫有用的錯誤訊息，讓使用者不需要連絡技術支援就能解決問題。

不正確：

在此範例中，錯誤訊息不正確地建議連絡技術支援。

• 使用完整的句子、句子樣式大寫，以及結束標點符號。

認可按鈕

• 如果錯誤訊息提供解決問題的命令按鈕或命令連結，請遵循 對話方塊中的個別指導方針。
• 如果程式必須因錯誤而終止，請提供 [結束程式] 按鈕。 為了避免混淆，請勿針對此目的使用 Close。
• 否則，請提供 [關閉] 按鈕。 請勿將 OK 用於錯誤訊息，因為此字組表示問題正常。
  • 例外： 如果您的錯誤報表機制與 MessageBox API.) 一樣 (固定標籤，請使用 [確定]

文件

參考錯誤時：

• 請參閱錯誤的主要指示。 如果主要指令很長或詳細，請加以摘要。
• 如有必要，您可能會將錯誤訊息對話方塊稱為訊息。 只在程式設計和其他技術檔中參考錯誤訊息。
• 可能的話，請使用粗體格式化文字。 否則，只有在需要以避免混淆時，才將文字放在引號中。

例子： 如果您收到 磁片磁碟機訊息中沒有 CD 光碟，請在磁片磁碟機 中插入新的 CD 光碟，然後再試一次。