備註
此設計指南已針對 Windows 7 建立，但尚未更新較新版本的 Windows。 大部分指引仍適用原則，但簡報和範例不會反映我們 目前的設計指導方針。
Windows 7 的錯誤訊息會警示使用者已發生的問題。 相反地，警告訊息會警示用戶未來可能造成問題的情況。 您可以使用強制回應對話框、就地訊息、通知或氣球來呈現錯誤訊息。
典型的強制回應錯誤訊息。
有效的錯誤訊息會通知用戶發生問題、說明發生問題的原因，並提供解決方案，讓使用者可以修正問題。 使用者應該執行動作或變更其行為，因為出現錯誤訊息。
撰寫良好且實用的錯誤訊息對於高品質的用戶體驗至關重要。 撰寫不佳的錯誤訊息會導致產品滿意度低，而且是可避免技術支援成本的主要原因。 不必要的錯誤訊息會中斷使用者的流程。
注意： 與 對話框、 警告訊息、 確認、 標準圖示、 通知和 版面配置 相關的指導方針會顯示在個別文章中。
這是正確的使用者介面嗎？
若要決定，請考慮下列問題：
- 使用者介面 （UI） 是否呈現已發生的問題？ 如果沒有，則訊息不是錯誤。 如果使用者收到未來可能造成問題之條件的警示，請使用警告訊息。
- 問題是否可以避免，而不會造成混淆？ 如果是，請改為避免問題。 例如，使用限制為有效值的控件，而不是使用可能需要錯誤訊息的不受限制的控件。 此外，按兩下時停用控制件會導致錯誤，只要很明顯為何停用控件。
- 問題是否可以自動修正？ 如果是，請處理問題並隱藏錯誤訊息。
- 使用者是否可能會執行動作或變更其行為，因為訊息的結果？ 如果沒有，條件不會證明中斷用戶是正當的，因此最好隱藏錯誤。
- 當用戶主動使用其他程式時，問題是否相關？ 如果是，請考慮使用 通知區域圖示來顯示問題。
- 問題是否與目前的用戶活動無關，它不需要立即用戶動作，而且使用者可以自由忽略它嗎？ 如果是，請改用 動作失敗通知 。
- 問題與主要視窗內背景工作的狀態有關嗎？ 如果是，請考慮使用 狀態列顯示問題。
- 主要目標使用者IT專業人員嗎？ 如果是，請考慮使用替代的意見反應機制，例如 記錄檔 專案或電子郵件警示。 IT 專業人員強烈建議記錄檔用於非重要資訊。
設計概念
錯誤訊息不佳的特性
應該毫不奇怪，有許多令人惱火、無益和撰寫不善的錯誤訊息。 而且，由於錯誤訊息通常會使用強制回應對話框來呈現，因此它們會中斷使用者的目前活動，並要求在允許用戶繼續之前予以認可。
問題的一部分是，有許多方法可以做錯。 請考慮下列來自錯誤訊息大廳恥辱的範例：
不必要的錯誤訊息
不正確：
來自 Windows XP 的這個範例可能是有史以來最差的錯誤訊息。 它表示程式無法啟動，因為 Windows 本身正在關閉。 使用者對此或甚至想要執行這項作沒有任何作用（畢竟使用者選擇關閉 Windows）。 藉由顯示此錯誤訊息，Windows 會防止自己關閉！
問題： 錯誤訊息本身是問題。 除了關閉錯誤訊息之外，使用者不會執行任何動作。
主要原因： 報告所有錯誤案例，不論用戶的目標或觀點為何。
建議的替代方案： 不要回報使用者不關心的錯誤。
「成功」錯誤訊息
不正確：
此錯誤訊息是用戶選擇不要在程式移除後立即重新啟動 Windows 所產生。 從用戶的觀點來看，程式移除成功。
問題： 用戶的觀點沒有錯誤。 除了關閉錯誤訊息之外，使用者不會執行任何動作。
主要原因： 從用戶的觀點成功完成工作，但從卸載程式的觀點來看失敗。
建議的替代方案： 請勿針對用戶認為可接受的條件回報錯誤。
完全無用的錯誤訊息
不正確：
使用者了解發生錯誤，但不知道錯誤是什麼或該怎麼做。 不，沒關係！
問題： 錯誤訊息不會提供特定問題，而且用戶無法對此執行任何動作。
主要原因： 最有可能是程序錯誤處理不佳。
建議的替代方案： 在程式中設計良好的錯誤處理。
無法理解的錯誤訊息
不正確：
在此範例中，問題陳述很清楚，但補充說明完全令人費解。
問題： 問題陳述或解決方案難以理解。
主要原因： 從程式代碼的觀點來說明問題，而不是用戶的問題。
建議的替代方案： 撰寫目標使用者可以輕鬆地瞭解的錯誤訊息文字。 提供用戶實際可執行的解決方案。 設計程式的錯誤訊息體驗沒有程式設計人員在現場撰寫錯誤訊息。
過度通訊的錯誤訊息
不正確：
在此範例中，錯誤訊息顯然會嘗試說明每個疑難解答步驟。
問題： 太多資訊。
主要原因： 提供太多詳細數據，或嘗試在錯誤訊息中說明複雜的疑難解答程式。
建議的替代方案： 避免不必要的詳細數據。 此外，請避免疑難解答員。 如果需要疑難解答員，請專注於最有可能的解決方案，並透過連結至 [說明] 中的適當主題來說明其餘部分。
不必要的嚴厲錯誤訊息
不正確：
程式找不到物件很難聽起來很災難性。 假設這是災難性的，為什麼可以做出回應？
問題： 節目的語氣是不必要的嚴厲或戲劇性的。
主要原因： 問題是由於從程序的觀點來看，出現災難性的錯誤。
建議的替代方案： 根據用戶的觀點仔細選擇語言。
責怪使用者的錯誤訊息
不正確：
為什麼讓用戶覺得自己是罪犯？
問題： 錯誤訊息的片語方式是指責用戶發生錯誤的方式。
主要原因： 不區分使用者的片語，而不是問題。
建議的替代方案： 將焦點放在問題上，而不是導致問題的使用者動作，視需要使用被動語音。
愚蠢的錯誤訊息
不正確：
在此範例中，問題陳述相當具有諷刺意性，而且不會提供任何解決方案。
問題： 錯誤訊息語句，這些語句是愚蠢或非 sequitor。
主要原因： 建立錯誤訊息而不注意其內容。
建議的替代方案： 撰寫並檢閱您的錯誤訊息。 檢閱錯誤時，請考慮內容和用戶的心態。
程序設計人員錯誤訊息
不正確：
在此範例中，錯誤訊息指出程式中有 Bug。 此錯誤訊息只對程式設計人員有意義。
問題： 旨在協助程式開發人員尋找 Bug 的訊息會保留在程式的發行版中。 這些錯誤訊息對用戶沒有任何意義或值。
主要原因： 使用一般UI向自己發出訊息的程式設計人員。
建議的替代方案： 開發人員必須有條件地編譯所有這類訊息，使其自動從產品的發行版本中移除。 不要浪費時間嘗試對用戶進行這類錯誤理解，因為他們唯一的對像是程式設計人員。
呈現錯誤訊息不佳
不正確：
此範例有許多常見的簡報錯誤。
問題： 在錯誤訊息簡報中取得所有詳細數據錯誤。
主要原因： 不知道並套用錯誤訊息指導方針。 不使用寫入器和編輯器來建立和檢閱錯誤訊息。
錯誤處理的本質是，許多錯誤很容易犯錯。 意識到大多數錯誤資訊可能是恥辱大廳的提名人，這令人不安。
良好錯誤訊息的特性
與先前的錯誤範例相反，良好的錯誤訊息有：
- 問題。 指出發生問題。
- 原因。 說明發生問題的原因。
- 解決方案。 提供解決方案，讓使用者可以修正問題。
此外，良好的錯誤訊息會以下列方式呈現：
- 相關。 此訊息會顯示使用者所關心的問題。
- 可行。 用戶應該執行動作或變更其行為，做為訊息的結果。
- 使用者中心。 此訊息描述目標使用者動作或目標的問題，而不是程式代碼不滿意的問題。
- 短。 訊息盡可能短，但不會較短。
- 清楚。 訊息會使用純文本語言，讓目標使用者可以輕鬆地了解問題和解決方案。
- 特定。 此訊息描述使用特定語言的問題，並提供相關物件的特定名稱、位置和值。
- 有禮貌。 用戶不應該受到指責或感到愚蠢。
- 罕見。 不常顯示。 經常顯示的錯誤訊息是錯誤的設計標誌。
藉由設計您的錯誤處理體驗來具有這些特性，您可以將程式的錯誤訊息保留在 「恥辱錯誤訊息大廳」外。
避免不必要的錯誤訊息
錯誤訊息通常不是錯誤訊息。 許多錯誤都可以透過更好的設計來避免，而且錯誤訊息通常有更好的替代方案。 通常最好避免錯誤，而不是報告錯誤。
要避免的最明顯錯誤訊息是無法採取動作的錯誤訊息。 如果使用者可能會關閉訊息而不執行或變更任何動作，請省略錯誤訊息。
有些錯誤訊息可以排除，因為它們不是使用者觀點的問題。 例如，假設使用者嘗試刪除已在刪除過程中的檔案。 雖然從程式代碼的觀點來看，這可能是非預期的案例，但使用者不會考慮此錯誤，因為其預期結果已達成。
不正確：
因為動作從用戶的觀點來看成功，因此應該排除此錯誤訊息。
如需另一個範例，假設用戶明確取消工作。 針對用戶的觀點，下列條件不是錯誤。
不正確：
因為動作從用戶的觀點來看成功，因此也應該排除此錯誤訊息。
有時候，您可以專注於用戶的目標而不是技術來消除錯誤訊息。 這樣做時，請重新考慮錯誤到底是什麼。 用戶的目標或程式滿足目標的問題嗎？ 如果使用者的動作在真實世界中有意義，它也應該在軟體中有意義。
例如，假設在電子商務程式中，用戶嘗試使用搜尋來尋找產品，但常值搜尋查詢沒有相符專案，而且所需的產品已缺貨。 從技術上說，這是錯誤，但不是提供錯誤訊息，而是程式可以：
- 繼續搜尋最符合查詢的產品。
- 如果搜尋有明顯的錯誤，請自動建議更正的查詢。
- 自動處理常見的問題，例如拼字錯誤、替代拼字，以及不相符的複數和動詞案例。
- 指出產品何時在庫存中。
只要使用者的要求合理，設計良好的電子商務程序應該傳回合理的結果，而不是錯誤。
另一個避免錯誤訊息的好方法，是先防止問題。 您可以藉由：
- 使用限制控制件。 使用限制為有效值的控制件。 清單、滑桿、複選框、單選按鈕和日期和時間選擇器等控件受限於有效值，而文本框通常不是而且可能需要錯誤訊息。 不過，您可以限制文字框只接受特定字元，並接受最大字元數。
- 使用限制的互動。 針對拖曳作業，允許使用者只放下有效的目標。
- 使用停用的控件和功能表項。 當使用者可以輕鬆地推算控件或功能表項停用的原因時，停用控件和功能表項。
- 提供良好的預設值。 如果使用者可以接受預設值，則不太可能進行輸入錯誤。 即使使用者決定變更值，預設值也會讓使用者知道預期的輸入格式。
- 使事情只是工作。 如果使用者不必要或自動執行工作，則不太可能犯錯。 或者，如果使用者犯了小錯誤，但他們的意圖很清楚，問題會自動修正。 例如，您可以自動更正次要格式問題。
提供必要的錯誤訊息
有時候您確實需要提供錯誤訊息。 使用者犯錯、網路和裝置停止運作、找不到或修改對象、無法完成工作，而且程式有 Bug。 在理想情況下，這些問題的發生頻率較低，例如，我們可以設計軟體來防止許多類型的用戶錯誤，但防止所有這些問題並不現實。 當其中一個問題確實發生時，有用的錯誤訊息可讓使用者快速回到自己的腳上。
常見的信念是錯誤訊息是最差的用戶體驗，應該以所有成本避免，但說使用者混淆是最差的體驗，應該以各種成本避免更準確。 有時候，成本是有用的錯誤訊息。
請考慮停用的控制件。 大部分時候，很明顯為什麼停用控件，因此停用控件是避免錯誤訊息的絕佳方式。 不過，如果控件停用的原因並不明顯，該怎麼辦？ 用戶無法繼續，而且沒有意見反應可判斷問題。 現在使用者停滯不前，必須推算問題或取得技術支援。 在這種情況下，最好讓控件保持啟用，並改為提供有用的錯誤訊息。
不正確：
為什麼此處停用 [下一步] 按鈕？ 最好是啟用它，並藉由提供有用的錯誤訊息來避免使用者混淆。
如果您不確定是否應該提供錯誤訊息，請從撰寫您可能會提供的錯誤訊息開始。 如果使用者可能執行動作或變更其行為，請提供錯誤訊息。 相反地，如果使用者可能會關閉訊息而不執行或變更任何動作，請省略錯誤訊息。
設計良好的錯誤處理
雖然製作良好的錯誤訊息文字可能具有挑戰性，但有時不可能沒有來自程式的良好錯誤處理支援。 請考慮此錯誤訊息：
不正確：
機會是，問題確實未知，因為程式的錯誤處理支援缺乏。
雖然這可能是一個非常糟糕的錯誤訊息，但它更有可能反映基礎程序代碼缺乏良好的錯誤處理，因此沒有關於問題的特定資訊。
若要建立特定、可採取動作、以使用者為中心的錯誤訊息，程式的錯誤處理程式碼必須提供特定、高階的錯誤資訊：
- 每個問題都應該指派唯一的錯誤碼。
- 如果問題有數個原因，程式應該盡可能判斷特定原因。
- 如果問題具有參數，則必須維護參數。
- 低階問題必須以足夠高的層級處理，以便從用戶的觀點呈現錯誤訊息。
良好的錯誤訊息不只是UI問題，它們是軟體設計問題。 良好的錯誤訊息體驗不是稍後可被攔截的內容。
疑難解答 （以及如何避免它）
使用單一錯誤訊息回報數個不同原因的問題時，針對結果進行疑難解答。
不正確：
正確：
當回報單一錯誤訊息時發生數個問題時，疑難解答結果。
在下列範例中，無法移動專案，因為專案已經移動或刪除，或拒絕存取。 如果程式可以輕易判斷原因，為什麼要讓用戶負擔判斷特定原因？
不正確：
嗯，這是哪一個？ 現在用戶必須進行疑難解答。
程式可以判斷存取是否遭到拒絕，因此應該以特定錯誤訊息回報此問題。
正確：
由於有特定原因，就不需要疑難解答。
只有在無法判斷特定原因時，才使用具有多個原因的訊息。 在此範例中，程式很難判斷專案是否已移動或刪除，因此可能會在這裡使用具有多個原因的單一錯誤訊息。 不過，使用者不太可能在意，例如，他們無法移動已刪除的檔案。 針對這些原因，甚至不需要錯誤訊息。
處理未知的錯誤
在某些情況下，您真的不會知道問題、原因或解決方案。 如果隱藏錯誤是不明智的，最好是預先瞭解缺乏資訊，而不是提出問題、原因或可能不對的解決方案。
例如，如果您的程式有未處理的例外狀況，則適合下列錯誤訊息：
如果您無法隱藏未知的錯誤，最好是預先瞭解缺乏資訊。
另一方面，如果大部分時間可能有説明，請提供特定且可採取動作的資訊。
如果網路連線通常是問題，則此錯誤訊息適用於未知的錯誤。
判斷適當的訊息類型
視強調和片語而定，某些問題可能會呈現為錯誤、警告或資訊。 例如，假設網頁無法根據目前的 Windows Internet Explorer 組態載入未簽署的 ActiveX 控制項：
- 錯誤。 「此頁面無法載入未簽署的 ActiveX 控制件。」（片語為現有問題。
- 警告 「此頁面可能無法如預期般運作，因為 Windows Internet Explorer 未設定為載入未簽署的 ActiveX 控制件。」或「允許此頁面安裝未簽署的 ActiveX 控件？ 從不受信任的來源這樣做可能會損害您的計算機。（兩者都片語為可能導致未來問題的條件。
- 資訊。 「您已設定 Windows Internet Explorer 封鎖未簽署的 ActiveX 控制件。」（片語為事實陳述。
若要判斷適當的訊息類型，請將焦點放在使用者需要知道或採取行動的問題最重要的層面。 一般而言，如果問題阻止用戶繼續，您應該將它顯示為錯誤;如果使用者可以繼續，請將它顯示為警告。 根據該焦點製作 主要指令 或其他對應的文字，然後選擇符合文字的圖示（標準 或其他）。 主要指令文字和圖示應該一律相符。
錯誤訊息呈現
Windows 程式中大部分的錯誤訊息都是使用強制回應對話框來呈現（如本文中的大多數範例所示），但還有其他選項：
- 就地
- 氣球
- 通知
- 通知區域圖示
- 狀態列
- 記錄檔 （適用於以 IT 專業人員為目標的錯誤）
將錯誤訊息放在強制回應對話框中的優點是要求使用者立即注意和認可。 不過，如果不需要注意，這也是其主要缺點。
您真的需要中斷使用者，讓他們可以按兩下 [關閉] 按鈕嗎？ 如果沒有，請考慮使用強制回應對話框的替代方案。
當用戶在繼續之前必須立即認可問題，但通常選擇不佳時，強制回應對話框是絕佳的選擇。 一般而言，您應該偏好使用最輕量型的簡報，以做好工作。
避免過度通訊
一般而言， 使用者不會讀取，他們會掃描。 文字越多，文字就越難掃描，使用者可能根本不會閱讀文字。 因此，請務必將文字減少到其基本資訊，並在必要時使用漸進式揭露和說明連結來提供其他資訊。
有許多極端範例，但讓我們看看一個更典型的範例。 下列範例具有良好錯誤訊息的大部分屬性，但其文字並不簡潔，而且需要閱讀動機。
不正確：
此範例是良好的錯誤訊息，但會過度溝通。
所有這些文字都真正說什麼？ 如下所示：
正確：
此錯誤訊息基本上具有相同的資訊，但更為簡潔。
藉由使用 [說明] 提供詳細數據，這個錯誤訊息會呈現 反轉金字塔樣式 。
如需有關過度通訊的指導方針和範例，請參閱 使用者介面文字。
如果您只做八件事
- 設計程式以進行錯誤處理。
- 請勿提供不必要的錯誤訊息。
- 藉由提供必要的錯誤訊息來避免使用者混淆。
- 請確定錯誤訊息會提供問題、原因和解決方案。
- 請確定錯誤訊息是相關、可採取動作、簡短、清楚、特定、禮貌和罕見的。
- 從使用者的觀點設計錯誤訊息，而不是程序的觀點。
- 避免在疑難解答中涉及使用者，針對每個可偵測的原因使用不同的錯誤訊息。
- 使用最輕量型的呈現方法，以妥善執行工作。
使用模式
錯誤訊息有數種使用模式：
| 標籤 | 價值 |
|---|---|
|
系統問題 作系統、硬體裝置、網路或程序失敗或未處於執行工作所需的狀態。 |
使用者可以解決許多系統問題：
在此範例中，程式找不到執行使用者工作的相機。 
在此範例中，必須開啟執行工作所需的功能。 |
|
檔案問題 找不到使用者起始之工作所需的檔案或資料夾、已在使用中，或沒有預期的格式。 |
在此範例中，找不到檔案或資料夾，因此無法刪除。 
在此範例中，程式不支援指定的檔案格式。 |
|
安全性問題 用戶沒有存取資源的許可權，或有足夠的許可權可執行使用者起始的工作。 |
在此範例中，用戶沒有存取資源的許可權。 
在此範例中，用戶沒有執行工作的許可權。 |
|
工作問題 執行使用者起始的工作有特定問題（不是系統、找不到檔案、檔案格式或安全性問題）。 |
在此範例中，剪貼簿數據無法貼到 Paint 中。 
在此範例中，用戶無法安裝軟體升級。 |
|
使用者輸入問題 使用者輸入的值不正確或與其他使用者輸入不一致。 |
在此範例中，用戶輸入了不正確的時間值。 
在此範例中，使用者輸入的格式不正確。 |
指導方針
簡報
- 請視需要使用工作對話框 ，以達到一致的外觀和版面配置。 工作對話框需要 Windows Vista 或更新版本，因此不適合舊版 Windows。 如果您必須使用消息框，請將主要指令與補充指令區隔開兩個換行符。
使用者輸入錯誤
-
盡可能防止或減少使用者輸入錯誤，方法是：
- 使用限制為有效值的控制件。
- 單擊時停用控件和功能表項會導致錯誤，只要控件或功能表項停用的原因很明顯。
- 提供良好的預設值。
不正確：
在此範例中，未受限制的文字框會用於限制輸入。 請改用滑桿。
- 針對內容相關的使用者輸入問題，使用無模式錯誤處理（就地錯誤或氣球）。
- 在文本框或文本框失去焦點之後，針對偵測到的非關鍵單一點使用者輸入問題使用氣球。氣球 不需要可用的螢幕空間，或顯示就地訊息所需的動態配置。 一次只顯示一個氣球。 因為問題並不重要，因此不需要錯誤圖示。 當單擊、解決問題或逾時之後，氣球就會消失。
在此範例中，氣球表示在控件中仍存在輸入問題。
- 針對延遲的錯誤偵測使用就地錯誤， 通常是按下認可按鈕找到的錯誤。 （請勿針對立即認可的設定使用 就地錯誤 。一次可能會有多個就地錯誤。 使用一般文字和 16x16 像素錯誤圖示，盡可能直接將它們放在問題旁邊。 除非使用者認可且找不到其他錯誤，否則就地錯誤不會消失。
在此範例中，藉由按下認可按鈕，就地錯誤會用於找到的錯誤。
- 針對所有其他問題使用強制回應錯誤處理（工作對話框或消息框）， 包括涉及多個控件的錯誤，或是按下認可按鈕找到非內容或非輸入錯誤的錯誤。
- 回報使用者輸入問題時，請使用不正確的數據，將輸入焦點設定為第一個控件。 視需要將控件捲動到檢視中。 如果控件是文字框，請選取整個內容。 應該一律清楚錯誤訊息所參考的內容。
- 請勿清除不正確的輸入。 相反地，請保留它，讓使用者可以看到並更正問題，而不需再開始。
- 例外： 清除不正確的密碼和 PIN 文字框，因為使用者無法有效地更正遮罩輸入。
故障排除
- 避免建立疑難解答問題。 請勿依賴單一錯誤訊息來回報有數個不同的可偵測原因的問題。
- 針對每個可偵測的原因，使用不同的錯誤訊息（通常是不同的補充指示）。 例如，如果檔案因為數個原因而無法開啟，請針對每個原因提供個別的補充指示。
- 只有在無法判斷特定原因時，才使用具有多個原因的訊息。 在此情況下，請以修正問題的可能性呈現解決方案。 這麼做可協助使用者更有效率地解決問題。
圖示
強制回應錯誤訊息對話框沒有標題列圖示。 標題列圖示會作為主要視窗和次要視窗之間的視覺區別。
使用錯誤圖示。 例外狀況：
如果錯誤是使用強制回應對話框或氣球顯示的使用者輸入問題，請勿使用圖示。 這樣做與 Windows 令人鼓舞的語氣相反。 不過，就地錯誤訊息應該使用小型錯誤圖示（16x16 像素）來清楚識別它們為錯誤訊息。
在這些範例中，使用者輸入問題不需要錯誤圖示。
在此範例中，就地錯誤訊息需要一個小錯誤圖示，才能清楚地將其識別為錯誤訊息。
如果問題適用於具有圖示的功能（而非使用者輸入問題），您可以使用功能圖示搭配錯誤重疊。 如果您這樣做，也請使用功能名稱做為錯誤的主體。
在此範例中，功能圖示具有錯誤重疊，而功能是錯誤的主旨。
請勿針對錯誤使用警告圖示。 這通常是為了讓簡報感覺不那麼嚴重。 錯誤不是警告。
不正確：
在此範例中，警告圖示不正確地用來讓錯誤感覺較不嚴重。
如需更多指導方針和範例，請參閱 標準圖示。
漸進式洩漏
- 使用 [顯示/隱藏詳細數據漸進式洩漏] 按鈕，在錯誤訊息中隱藏進階或詳細資訊。 這麼做可簡化一般使用方式的錯誤訊息。 請勿隱藏所需的信息，因為使用者可能找不到它。
在此範例中，漸進式洩漏按鈕可協助使用者向下切入到想要的更詳細數據，或若不這麼做，請簡化UI。
- 除非確實有更多詳細數據，否則請勿使用 [顯示/隱藏詳細數據]。 不要只以更詳細的格式重新整理現有的資訊。
- 請勿使用 [顯示/隱藏詳細數據] 來顯示說明資訊。 請改用 [說明] 連結。
如需標籤指導方針，請參閱 漸進式洩漏控件。
不要再顯示此訊息
- 如果錯誤訊息需要此選項，請重新考慮錯誤及其頻率。 如果它具有良好錯誤的所有特性（相關、可作且不常），則使用者不應該隱藏它。
如需詳細資訊，請參閱 對話框。
預設值
- 選取最安全、最不具破壞性或最安全的回應做為預設值。 如果安全性不是因素，請選取最有可能或方便的命令。
幫助
- 設計錯誤訊息以避免需要說明。 一般而言，除非解決方案需要數個步驟，否則使用者不應該閱讀外部文字來瞭解並解決問題。
- 請確定說明內容相關且有説明。 它不應該是錯誤訊息的詳細資訊，而是應該包含超出錯誤訊息範圍的實用資訊，例如在未來避免問題的方法。 請勿提供說明連結，只是因為您可以。
- 使用特定、簡潔、相關的說明連結來存取說明內容。 請勿針對此目的使用命令按鈕或漸進式洩漏。
- 針對您無法進行特定且可採取動作的錯誤訊息，請考慮提供在線說明內容的連結。 如此一來，您可以為使用者提供可在程序發行後更新的其他資訊。
如需更多指導方針，請參閱 說明。
錯誤碼
- 針對您無法進行特定且可採取動作的錯誤訊息，或它們受益於 [說明]，請考慮也提供錯誤碼。 使用者通常會使用這些錯誤碼來搜尋因特網以取得其他資訊。
- 一律提供問題和解決方案的文字描述。 不要只視錯誤碼而定。
不正確：
在此範例中，錯誤碼會用來做為解決方案文字的替代專案。
- 為每個不同的原因指派唯一的錯誤碼。 這樣做可避免進行疑難解答。
- 選擇可在因特網上輕鬆搜尋的錯誤碼。 如果您使用 32 位代碼，請使用十六進位表示法搭配前置 「0x」 和大寫字元。
正確：
1234
0xC0001234
不正確：
-1
-67113524
- 使用 [顯示/隱藏詳細資料] 來顯示錯誤碼。 片語為錯誤碼：
<error code>。
在此範例中，錯誤碼可用來補充可從進一步資訊獲益的錯誤訊息。
音效
- 請勿隨附有音效或嗶聲的錯誤訊息。 這樣做是令人不安和不必要的。
- 例外： 如果問題對計算機作至關重要，則播放「重大停止」音效，而且用戶必須立即採取動作，以防止嚴重後果。
文字
一般
- 拿掉多餘的文字。 在標題、主要指示、補充指示、命令鏈接和認可按鈕中尋找它。 一般而言，在指示和互動式控件中保留全文檢索，並從其他地方移除任何備援。
- 使用以使用者為中心的說明。 在使用者動作或目標方面描述問題，而不是軟體對什麼不滿意的問題。 使用目標使用者瞭解和使用的語言。 避免技術術語。
不正確：
正確：
在這些範例中，正確的版本會說出用戶的語言，而不正確的版本過於技術性。
-
請勿使用下列單字：
- 錯誤、失敗（請改用為「問題」）
- 請將「失敗」改為「無法」
- 非法、無效、不正確的 （改用不正確）
- 中止、結束、終止（改用停止）
- 災難性的致命（改用嚴重）
這些詞彙是不必要的，與 Windows 令人鼓舞的語氣背道而馳。 正確使用時，錯誤圖示會充分傳達有問題。
不正確：
正確：
在不正確的範例中，「災難性」和「失敗」一詞是不必要的。
- 請勿使用歸咎於使用者或隱含用戶錯誤的片語。 避免在措辭中使用你和你的。 雖然通常慣用主動語態，但當使用者是主詞且使用主動語態可能讓他們感到被責怪時，請使用被動語態。
不正確：
正確：
不正確的範例會使用作用中的語音來責怪使用者。
- 具體明確。 避免模糊的措辭，例如語法錯誤和非法作業。 提供相關物件的特定名稱、位置和值。
不正確：
找不到檔案。
磁碟已滿。
超出範圍的值。
字元無效。
裝置無法使用。
使用特定名稱、位置和值，這些問題會更容易解決。
- 請勿在嘗試特定時提供可能不太可能的問題、原因或解決方案。 除非問題、原因或解決方案可能正確，否則請勿提供問題、原因或解決方案。 例如，最好說發生未知的錯誤比可能不正確的東西還要好。
- 請避免「請」一詞， 除非在要求使用者不方便（例如等候）或軟體時，將責任歸咎於情況。
正確：
請稍候 Windows 將檔案複製到您的電腦。
- 只有在錯誤訊息中才使用「抱歉」這個字，這會導致用戶發生嚴重問題 （例如，數據遺失或無法使用計算機）。 如果程式正常運作期間發生問題，請勿道歉（例如，如果使用者需要等候找到網路連線）。
正確：
很抱歉，Fabrikam 備份偵測到無法復原的問題，並已關閉以保護您電腦上的檔案。
- 請參閱使用其簡短名稱的產品。 請勿使用完整的產品名稱或商標符號。 除非使用者將公司名稱與產品建立關聯，否則請勿包含公司名稱。 請勿包含程式版本號碼。
不正確：
正確：
在不正確的範例中，會使用完整的產品名稱和商標符號。
- 在物件名稱周圍使用雙引號。 這麼做可讓文字更容易剖析，並避免可能令人尷尬的語句。
- 例外： 完整檔案路徑、URL 和功能變數名稱不需要以雙引弧括住。
正確：
在此範例中，如果物件名稱不是以引弧括住，則錯誤訊息會混淆。
- 避免使用物件名稱啟動句子。 這樣做通常很難剖析。
- 請勿將所有大寫字母都使用驚嘆號或單字。 驚嘆號和大寫字母讓人覺得你在對使用者大喊大叫。
如需更多指導方針和範例，請參閱 樣式和音調。
標題
- 使用標題來識別錯誤來源的命令或功能。 例外：
- 如果許多不同的命令顯示錯誤，請考慮改用程式名稱。
- 如果該標題會備援或與主要指令混淆，請改用程序名稱。
- 請勿使用標題來說明或摘要主要 指示的目的問題。
不正確：
在此範例中，標題不正確地用來說明問題。
- 使用標題樣式大寫，而不結束標點符號。
主要指示
- 使用主要指示，以清楚、簡單、特定語言來描述問題。
- 僅簡潔地使用單一完整句子。 將主要指示剖析為基本資訊。 如果您的程式或使用者是程式或使用者，則可以將主旨保留隱含。 如果您能簡潔地這麼做，請納入問題的原因。 如果您必須進一步說明任何內容，請使用補充指示。
不正確：
在此範例中，整個錯誤訊息會放在主要指令中，讓您難以閱讀。
- 如果有涉及的物件，請指定其名稱。
- 避免將完整檔案路徑和 URL 放在主要指令中。 相反地，請使用簡短名稱（例如檔名），並將完整名稱（例如檔案路徑）放在補充指示中。 不過，如果錯誤訊息不需要補充指令，您可以將單一完整檔案路徑或URL放在主要指令中。
在此範例中，只有檔名位於主要指令中。 完整路徑位於補充指示中。
- 如果內容明顯，請勿提供完整的檔案路徑和 URL。
在此範例中，使用者正在從 Windows 檔案總管重新命名檔案。 在此情況下，不需要完整的檔案路徑，因為從內容中很明顯。
- 盡可能使用目前的時態。
- 使用句子樣子大寫。
- 如果指令是語句，請勿包含最後的句點。 如果指示是問題，請包含最終問號。
主要指示範本
雖然片語沒有嚴格的規則，但請儘可能嘗試使用下列主要指示範本：
- [選擇性主體名稱] 無法 [執行動作]
- [選擇性主體名稱] 無法 [執行動作]，因為 [reason]
- [選擇性主體名稱] 無法 [執行動作] 至 “[物件名稱]”
- [選擇性主體名稱] 無法 [執行動作] 至 “[物件名稱]”，因為 [reason]
- [resource] 不足以 [執行動作]
- [主體名稱] 沒有 [目的] 所需的 [物件名稱]
- [裝置或設定] 已關閉，以便 [不想要的結果]
- [裝置或設定] 未 [可用 | 找到 | 已開啟 | 已啟用]
- “[物件名稱]” 目前無法使用
- 使用者名稱或密碼不正確
- 您沒有存取 「[物件名稱]」 的許可權
- 您沒有 [執行動作] 的許可權
- [程式名稱] 已發生嚴重問題，必須立即關閉
當然，請視需要變更主要指示，以語法正確且符合主要指示指導方針。
補充指示
- 使用補充指示來：
- 提供問題的其他詳細數據。
- 說明問題的原因。
- 列出使用者可以採取以修正問題的步驟。
- 提供防止問題重新發生的措施。
- 盡可能提出實用的實用解決方案，讓使用者可以修正問題。 不過，請確定建議的解決方案可能會解決問題。 不要藉由建議可能但不可能的解決方案來浪費用戶的時間。
不正確：
在此範例中，雖然問題及其建議的解決方案可能，但不太可能。
- 如果問題是使用者輸入的不正確值，請使用補充指示來說明正確的值。 用戶不應該從另一個來源判斷此資訊。
- 如果可以從問題陳述中微不足道地推斷，請勿提供解決方案。
在此範例中，不需要補充指示;解決方案可以從問題語句中簡單地推斷出來。
- 如果解決方案有多個步驟，請依照應該完成的步驟順序呈現這些步驟。 不過，請避免多步驟解決方案，因為使用者難以記住兩三個以上的簡單步驟。 如果需要更多步驟，請參閱適當的說明主題。
- 保持補充指示簡潔。 僅提供使用者需要知道的內容。 省略不必要的詳細數據。 目標是最多三個句子的中長度。
- 若要避免使用者在執行指示時發生錯誤，請將結果放在動作之前。
正確：
若要重新啟動 Windows，請按兩下 [確定]。
不正確：
按兩下 [確定] 以重新啟動 Windows。
在不正確的範例中，使用者更有可能不小心按兩下 [確定]。
- 除非這樣做是問題最可能的解決方案之一，否則不建議連絡系統管理員。 請針對真正只能由系統管理員解決的問題，保留這類解決方案。
不正確：
在此範例中，最有可能的問題是使用者的網路連線，因此不值得連絡系統管理員。
- 不建議連絡技術支援。 連絡技術支援以解決問題的選項一律可供使用，而且不需要透過錯誤訊息升級。 相反地，請專注於撰寫實用的錯誤訊息，讓使用者不需要連絡技術支援就能解決問題。
不正確：
在此範例中，錯誤訊息錯誤地建議連絡技術支援。
- 使用完整的句子、句子樣式大寫和結尾標點符號。
認可按鈕
- 如果錯誤訊息提供解決問題的命令按鈕或命令連結，請遵循 對話框的個別指導方針。
- 如果程式因錯誤而必須終止，請提供 [結束程式] 按鈕。 為了避免混淆，請勿針對此目的使用 Close。
- 否則，請提供 [關閉] 按鈕。 請勿對錯誤訊息使用OK，因為此措辭表示問題正常。
- 例外： 如果您的錯誤報告機制具有固定標籤，請使用 [確定]。
文件資料
參考錯誤時：
- 請參閱錯誤的主要指示。 如果主要指示很長或詳細，請摘要說明。
- 如有必要，您可能會將錯誤訊息對話框視為訊息。 只有在程序設計和其他技術檔中，才能參考為錯誤訊息。
- 可能的話，請使用粗體格式化文字。 否則，只有在需要防止混淆時，才將文字放在引號中。
例： 如果您收到 磁碟驅動器訊息中沒有CD光碟 ，請在磁碟驅動器中插入新的CD光碟，然後再試一次。