交流是一個不斷學習的平臺,在輕鬆快樂中提高自己
阿新 • • 發佈：2019-02-11
1. 介面規範
1.1. 總體原則
＊ 以使用者為中心。設計由使用者控制的介面，而不是介面控制使用者。
＊ 清楚一致的設計。所有介面的風格保持一致，所有具有相同含義的術語保持一致，且易於理解
＊ 擁有良好的直覺特徵。以使用者所熟悉的現實世界事務的抽象來給使用者暗示和隱喻，來幫助使用者能迅速學會軟體的使用。
＊ 較快的響應速度。
＊ 簡單且美觀。
1.2. 原則詳述
1.2.1. 使用者控制
使用者介面設計的一個重要原則是使用者應該總是感覺在控制軟體而不是感覺被軟體所控制。
＊ 操作上假設是使用者--而不是計算機或軟體--開始動作。使用者扮演主動角色，而不是扮演被動角色。在需要自動執行任務時，要以允許使用者進行選擇或控制它的方式來實現該自動任務。
＊ 提供使用者自定義設定。因為使用者的技能和喜好各不相同，因此他們必須能夠個性化介面的某些方面。Windows為使用者提供了對許多這方面的訪問。您的軟體應該反應不同的系統屬性--例如顏色、字型或其他選項的使用者設定。
＊ 採取互動式和易於感應的視窗，儘量避免使用模態對話方塊，而使用"非模式"輔助視窗。 "模式"是一種狀態，它排除一般的互動，或者限制使用者只能進行特定的互動。當最好使用一個模式或該模式只是可替換的設計時--例如，用於在一個繪圖程式中選定一個特定感覺--請確保該模式是顯然的、可見的，是一個明確的使用者選定的結果，並且容易取消。
＊ 在後臺執行長程序時，保持前臺式互動。例如，當正在列印一個文件，即使該文件不能被改變，使用者也應該可以最小化該視窗。
＊ 諒解。使用者喜歡探索一個介面，並經常從嘗試和錯誤中學習。一個有效的介面允許互動式的發現，它只提供一組合適的選擇，並在使用者可能破壞系統或資料的情況時發出警告。如果可行，還應提供可逆轉或可還原的操作。即使在設計得很好得介面中，使用者也可能犯錯誤。這些錯誤既可以是物理上得（偶然地指向了錯誤的命令或資料），也可以是邏輯上的（對選定哪一個命令或哪些資料做出了錯誤的決定）。有效的設計避免很可能導致錯誤的情況。它還包容潛在的使用者錯誤，並且使使用者易於還原。
1.2.2. 清楚一致的設計
一致允許使用者將已有的知識傳遞到新的任務中，更快地學習新事物，並將更多的注意力集中在任務上。這是因為他們不必花時間來嘗試記住互動中的不同。通過提供一種穩定的感覺，一致使得介面熟悉而又可預測。一致在介面的所有方面都是很重要的，包括命令的名稱、資訊的可視表示，操作行為，以及元素在螢幕和視窗內部的放置。
＊ 相同含義的詞使用統一的術語。比如對於倉庫中存放的物料，不可同時又稱為物品、貨物、備品、產品和材料等等，而統一約定一個稱謂，且此稱謂是使用者熟悉的和易於理解的。
＊ 使用一組一致的命令和介面來展示常見功能。例如，避免一個"複製"命令在一種情況下立刻執行一個操作，但在另一種情況顯示一個對話方塊要求使用者鍵入目標然後才執行。應該使用同樣的命令來執行對使用者來說相似的功能。
＊ 操作環境內的一致。保持Windows提供的互動操作和介面約定之間的高度一致，使用者將能很快熟悉軟體的使用。
＊ 使用隱喻的一致性。如果一個特定的行為更多的是一個不同的事物的特徵，而不是它的隱喻的含義，那麼使用者可能在學習將行為和該事物相關聯時遇到困難。例如，對於放在回收站中的物件而言，焚燒爐和廢紙籮代表不同的模型。
＊ 建立專案保留字。通過建立保留字來明確和統一術語和操作命令。
＊ 提供可視反饋。在後臺執行長程序時（時間超過1～10秒，視具體情況而定），必須提供進度條等資訊指示。
＊ 除非特別必要時，不要提供聲音反饋。在有嚴重的問題發生時，可以使用聲音來提示使用者，但是通常應該允許使用者取消聲音。
＊ 保持文字內容清楚。資訊的表達要言簡意賅，易於理解而又不羅嗦；避免使用冗長的文字給使用者反饋。
1.2.3. 有良好的直覺特徵
＊ 用熟悉的隱喻為使用者的任務提供直接而直觀的介面。通過允許使用者利用他們的知識和經驗，隱喻使得預測和學習基於軟體的表示的行為更加容易。
＊ 在使用隱喻時，不需要將基於計算機的實現侷限在真實世界的對應物上範圍之內。例如，與其基於紙張的對應物不同，Windows桌面上的資料夾可以被用來組織各種物件，例如印表機、計算器、以及其他資料夾。同樣，Windows資料夾可以其真實世界對應物不可能的方式被排序。在介面中使用隱喻的目的是提供一個認知的橋樑；隱喻並不以其自身為最終目的。
＊ 隱喻支援使用者認知而不是記憶。使用者記起與一個熟悉的事物相關聯的意義要比他們記起一個特定命令的名稱要容易得多。
＊ 同常見軟體保持一致性。出色的使用者介面在程式中將實現同用戶以前用過的其它成功軟體一致的動作。
1.2.4. 較快的響應速度
＊ 保持介面能很快對使用者操作作出反應。
＊ 提供快捷鍵。特別對於有大量錄入項的介面，能讓使用者不使用滑鼠即可完成快速資料錄入。在使用者介面中加入一些功能，這些功能可以讓熟練使用者在不同的區域快速的輸入資料。這些功能包括重複功能、快捷鍵、帶有有意義的圖示的按鈕等等，所有這些可以使速度快的使用者可以控制介面並加快資料的輸入。
＊ 除非必要，不要重繪螢幕。
1.2.5. 簡單且美觀
＊ 簡單。介面應該很簡單（不是過分單純化）、易於學習、並且易於使用。它還必須提供對應用程式的所有功能的訪問。在介面中，擴大功能和保持簡單是相互矛盾的。一個有效的設計應該平衡這些目標。支援簡單性的一種方法是將資訊的表示減少到進行充分交流所需的最少資訊。例如，避免命令名和訊息的文字描述。不相關或冗長的句子擾亂了您的設計，使得使用者難以很容易地提取重要資訊。另一個設計簡單而有用的介面的方法是使用自然的對映和語意。介面元素的排列和表示影響它們的意義和關聯。簡單還與熟悉相互關聯。熟悉的事物通常似乎更簡單。儘可能嘗試建立利用使用者已有的知識和經歷的聯絡。您可以使用漸進揭示來幫助使用者管理複雜的事物。"漸進揭示"涉及到仔細的資訊組織，以便只在恰當的時候才顯示資訊。通過隱藏向用戶表達的資訊，您減少了使用者必須處理的資訊數量。例如，您可以使用選單來顯示操作或選擇的列表，還可以使用對話方塊來顯示一組選項。漸進揭示並不意味著對顯示資訊使用非傳統的技術，例如需要一個修飾鍵作為訪問基本功能的唯一方法，或者強迫使用者通過一個更長的分級互動序列。這會使使用者介面更加複雜和麻煩。
＊ 美觀。可視設計是應用程式介面的重要部分。可視屬性提供了非常好的印象，並傳達特定物件的互動行為的重要線索。同時，出現在螢幕上的每一個可視元素也是很重要的，它們可能競爭使用者的注意。提供清楚地促進使用者對錶達的資訊的理解的連貫環境。圖形或可視設計器的技巧對於這一方面是無價的。
1.3. 細節約定
1.3.1. 介面風格
1.3.1.1. 普通外觀
＊ 使用一致性 一致的外觀將使使用者介面更易於理解和使用。使用者介面控制元件看起來應該是一致的。
＊ 使用安排和流程 在西方文化中（包括中國），人們習慣於從左到右，從上到下進行閱讀，因此，應該將重要資訊放在上面和左邊。左上角最容易吸引起人們的注意力。
＊ 使用對齊 通常，使用左對齊來使使用者介面控制元件更易於瀏覽。對於數值文字，應該使用小數點對齊或右對齊。對於非數值文字，應該避免使用右對齊或居中對齊。不必對什麼都使用中間對齊，或者使它們保持對稱形式。在右邊或底部保留空白區域更適合習慣。
＊ 使用分組 將相關的使用者介面控制元件分成組，以體現它們之間的關係。同時，還要顯示相關資訊。將控制元件放在它所作用的物件旁。使用空格、分組框、線條和標籤，或者其它分隔符對使用者介面控制元件進行分組。
＊ 使用強調 使用焦點、位置、分組、層次、啟用/禁用、大小、顏色或者字型等，來將注意力集中在需要首先看到的使用者介面控制元件上。儘量以可視的方式指明使用者接下來應該進行的操作。
＊ 使用可視的提示 儘量使用近似的大小和間距來指出使用者介面控制元件是相似的，而使用不同的大小和間距來指出使用者介面控制元件視是不同的。
＊ 使用空格 使用空格來建立一個"透氣室"，以使窗口布局更易於理解，並且檢視起來更舒服。空格的多少要適當，不要顯得太分散。但是，要避免過多地使用空格。如果可能，儘量使視窗小一些。
＊ 警惕空洞 不要到處貼上公司或產品的名稱及徽標。雖然在啟動屏或"關於"框中出現公司或產品名稱及徽標是完全可以接受的，但其他視窗中的可用空間應該出現其他內容。如果沒有其他內容，那麼應儘量使視窗小一些。
＊ 注意大小 使用使用者介面控制元件的解析度具有獨立性。使用系統規格（使用GetGystemMetrics API 函式）或文字規格（使用GetTextMetrics或GetTextExtentPoint32 API 函式）來確定使用者介面控制元件的大小。任何顯示文字的物件（如對話方塊或定義的文字文件）都應該使用文字規格。
＊ 考慮使用資源或預定義的佈局網格 資源模板或預定義的佈局網格有助於您在不同的視窗之間實現一致性。
注意，下頁所示圖的第二個對話方塊，與第一個不同，它有一個緊湊、從左到右、從上到下的流程，並且，左對齊的標籤很便於瀏覽；通過對齊編輯框並調整其大小，使它顯得更有組織，更加平衡。
1.3.1.2. Windows的可視提示
暗示與使用者只需通過檢視可視提示來確定物件的使用方式的能力有關。在Windows中，請保持使用下面的可視提示：
＊ 可以單擊凸起的專案。
＊ 可以單擊當滑鼠從其上移過時突出顯示的專案。
＊ 不能單擊下凹的專案。
＊ 可以編輯具有白色背景和閃爍垂直條（游標）的專案。
＊ 不能編輯具有灰色背景的專案。
＊ 灰色專案是被禁用的。
＊ 可以拖動凸起的專案。
1.3.1.3. 互動
＊ 儘量提供對所有功能的鍵盤訪問 理想情況下，除了繪圖這樣的圖形功能，其他所有的功能都應該只能通過鍵盤來訪問。
＊ 儘量提供對所有功能的滑鼠訪問 理想情況下，除了文字輸入外，其他所有功能都應該只能通過滑鼠來訪問。
＊ 確保具有明顯後果的操作要求使用者進行明確的選擇* 使用者需要完全明確他將要進行危險性操作或破壞性操作。
＊ 對於使有耗時的操作都給出反饋* 在進行長時間的操作時，要確保有等待游標、進度表或其他的可視反饋。使用者應該能夠取消長時間的操作。如果可以取消未完成的操作，那麼將按鈕標記為"取消"，否則將按鈕標記為"停止"。
＊ 可視的指示模式* 向用戶提供一種可視的反饋，以指出使用者進入一種模式，通常可以通過更改游標或標題欄文字來做到這一點。
＊ 確保單擊和雙擊的一致性* 單擊用於非按鈕選定，而雙擊用於選定並執行預設操作。換句話說，雙擊（在列表框、組合框，或其他接受雙擊的控制元件中）的效果應該與選定控制元件中的一個專案，然後按下Enter鍵的效果一樣。
＊ 滑鼠右鍵僅用於快捷選單* 確保滑鼠右鍵僅用於快捷選單，而不要用於其他用途。
＊ 不要使用滑鼠中鍵* 如果使用者的滑鼠有中鍵，那麼讓使用者使用"控制面板"中的"滑鼠"實用程式自己分配中鍵的行為。
＊ 保持分配的快捷鍵的一致性 組合功能鍵和Ctrl鍵用於快捷鍵。習慣上不將Alt鍵用於組合鍵，業務Alt鍵常常被用於訪問鍵。儘量避免使用Alt鍵和Ctrl鍵，因為這種組合會使快捷鍵非常麻煩，而且也很不方便。
＊ 將快捷鍵作為補充方式* 千萬不要將快捷鍵作為訪問命令的唯一方法。應該讓使用者有更多的明顯選擇。
＊ 避免水平滾動條 與垂直滾動條不同，水平滾動條並不受歡迎，因為它會使專案閱讀起來比較困難。解決的辦法有：儘量使用垂直滾動條、加寬視窗、減小文字的寬度，或者使文字自動換行等。當然，如果確實需要，還可以使用水平滾動條。
1.3.1.4. 程式
＊ 只有主程式窗口才有標題欄圖示、選單欄、工具欄和狀態列* 因為單擊主視窗的工作列按鈕也會啟用二級視窗，所以二級視窗絕對不要顯示在工作列中。二級視窗不要因為使用選單欄、工具欄或狀態列而使其變得複雜。可以使用標題欄圖示來明顯區分主視窗和二級視窗。另外，絕對不要使用預設的 Windows圖示(飄動的視窗圖示)作為視窗圖示。
＊ 簡化預設配置 讓使用者按自己的速度來學習和使用程式。
＊ 應用程式應該使用多文件介面（MDI）或單文件（SDI） 這些程式介面應該與應用程式的使用模式匹配。
＊ 預設情況下，應用程式應該保持為最大化 當應用程式佔用整個螢幕時，常常能夠提高使用者的工作效率。
＊ 實用程式應該使用SDI或對話方塊介面 這些程式介面應該與實用程式的使用模式匹配。對於實用程式，建議不要使用MDI介面，因為管理這些視窗需要付出很多努力。
＊ 實用程式應該在小螢幕範圍內執行 實用程式常常與其他程式一起執行，因此它們需要在小螢幕範圍內執行。實用程式應該有靈活的窗口布局，以適應多種不同的大小。實用程式很少以最大化的形式執行。
＊ 使用實際文件的SDI程式必須支援執行多個例項* 執行多個例項使使用者能夠同時操作多個文件。
＊ 使用"退出"命令終止程式 使用"退出"終止程式；使用"關閉"移走主視窗和非模式對話方塊；使用"取消"移走模式對話方塊。當關閉主視窗並不表示終止程序時，對於主視窗使用"關閉"來代替使用"退出"。例如：關閉印表機狀態視窗不會取消列印任務。
1.3.1.5. 預設
＊ 儲存和恢復使用者選擇 程式應該能夠能夠恢復到其最後退出的狀態。MDI程式應該能夠恢復文件視窗的大小和位置。對話方塊通常應該使用最後輸入的值作為預設值。
＊ 提供適當的預設值 提供提供適當的預設值來減少使用者不必要的操作，從而幫助使用者完成工作。提供最可能使用並給出設定實際使用方式的預設值。通常，最好的預設值是使用者最後輸入的值。
＊ 考慮選擇預設值時的安全性* 不應該將不可恢復或破壞性的操作設定為預設值。不要使用令使用者感到莫名其妙的預設值。
1.3.1.6. 窗體
對話方塊窗體大小盡量不要超過640*460，留20給工作列。並且高和寬（或W寬和高）的比應該大致保持為3:4（或4：3）。一般應該將窗體的"Position"屬性定義為 "poDesktopCenter"，"WindowState"屬性為"wsNormal"，某些主介面設定為"wsMaximized"。 "ShowHint"屬性設為"True"。如果是模式對話方塊，則將"BorderStyle"屬性設定為"bsDialog"。
窗體檔案(*.dfm)儲存為文字格式，以便在VSS中比較不同版本之間的差別。如果窗體大小超過螢幕大小，則在Delphi開發環境中開啟時，大小會有改變，並且影響到執行時刻效果。由於每個人的螢幕大小設定不一樣，有些是1024*768，有些是800*600，因此在設計期間請注意窗體大小，儘量不要超過800*600，以免出現上述問題。
1.3.1.7. 佈局和間距
窗體控制元件佈局和間距儘量保持與Windows標準一致。控制元件與窗體的上、下、左、右邊距為7象素。右下角主命令按鈕之間的間距為6象素，如果主命令按鈕在右上角，之間的間距則為4象素。主命令按鈕一般情況為75×21象素，如果按鈕的文字很長，應該適當加寬按鈕的寬度。如下圖。其它詳細資料請完全參照錯誤！書籤自引用無效。和命令按鈕。
控制元件的"TabOrder"屬性值應該與控制元件排列順序一致，即遵循從上到下、從左到右這樣一個流程。如果在PageControl的多個頁面中存在類似的控制元件，應該儘量使得它們在各個頁面中出現的位置/大小比較一致，以免在頁面間切換時產生閃爍感。 1.3.1.8. 圖示、圖片
不同介面中的同一功能應該使用同樣的圖示和圖片。圖示、圖片的色調、風格儘量保持一致。圖示、圖片的隱喻應能確切表示功能的含義，如果不能，就直接使用文字，以免混淆使用者。如果功能是一個動作時，可能比較難找到確切表示該功能的圖示，這時應該儘量採用此動作相關的名詞做圖示。例如 Windows中的"剪下"功能就是用一把剪刀來表示的。
1.3.1.9. 提示資訊（Hint）
工具欄按鈕應該設定工具提示 "Hint" 屬性。Hint能幫助使用者更方便地理解和使用。詳細資料可以參照工具欄、工具提示。
如果使用了"TSpeedButton"控制元件，並且只有圖示，同樣應對它設定"Hint"屬性。如果不是特殊情況，應儘量避免使用"TSpeedButton"控制元件，而使用"TButton"控制元件代替。
1.3.1.10. 標點符號
在標識控制元件用途的標籤文字（Label）和提示資訊（Hint）中，應使用半形符號。如果是指導性標籤文字（如解釋按鈕功能的句子），則使用全形符號，並且句子應遵循中文標點符號標準。如下圖Microsoft標準對話方塊例子。其他詳細資料可參照靜態文字。
1.3.1.11. 對話方塊
＊ 對話方塊應該在所有視訊模式下都能夠正確顯示 當在VGA模式（640×480）下顯示時，對話方塊應該不超過640×460（留20畫素給工作列）。這將確保對話方塊能夠顯示在所有的視訊模式下。
＊ 確保模式對話方塊的模式* 確保使用具有父視窗的模式對話方塊都提供正確的父視窗控制代碼，而不時提供NULL控制代碼。如果沒有提供父視窗控制代碼，那麼父視窗仍處於活動狀態，因此該對話方塊實際上並不是模式對話方塊。
＊ 不要使用可滾動的對話方塊* 也就是說，不要使用需要滾動條來進行完全檢視的對話方塊。這種對話方塊使用起來非常不方便，並且也時完全不必要的。應該重新設計這種對話方塊。
＊ 不要在作為二級視窗的對話方塊中使用選單欄* 使用這種對話方塊需要付出很多努力。注意，在用作主視窗的對話方塊（如"查詢"實用工具）中，選單欄時可以接受的。還要注意的是，在所有對話方塊中，快捷選單和選單按鈕都是可以接受的。
二級對話方塊不要使用選單欄，但可以使用選單按鈕。 ＊ 不要在作為二級視窗的對話方塊中使用標題欄圖示* 標題欄圖示用於區別主視窗和二級視窗。
＊ 不要在工作列上顯示作為二級視窗的對話方塊* 注意，單擊主視窗的的工作列圖示也將啟用二級視窗。
＊ 對話方塊中使用下頁圖所示的頁面佈局和間距。
＊ 對於相似的對話方塊，使用控制元件位置來強調其相似性。 如果意義相同的同一控制元件出現在一些相似的對話方塊中，那麼它應該顯示在相同的位置。另一方面，應避免將可能會產生混淆的不同控制元件放在同一位置。
＊ 對非模式對話方塊最好使用可停放的對話方塊 可停放對話方塊在功能上與非模式對話方塊是等效的，但其位置設定更為靈活。
＊ 策略地設定輸入焦點 將最初的輸入焦點設定在最可能首先使用的控制元件上。
＊ 在對話方塊標題文字中不要出現省略號 例如，作為選擇"列印選項..."命令結果而顯示地對話方塊的標題應該為"對於選項"。但是，表示命令正在執行過程中選單對話方塊（如"連線到Internet..."對話方塊）是一種例外情況。
＊ 為所有可處理訪問鍵的控制元件分配訪問鍵* 訪問鍵可以使使用者的手保持在鍵盤上，從而使訪問程式更加方便。您可以直接在其標題中為諸如命令按鈕、單選按鈕、複選框等控制元件分配訪問鍵。通過提供靜態文字標籤或帶有訪問鍵、在Tab順序上先於控制元件的組框，您可以為諸如編輯框、列表框、組合框等控制元件分配訪問鍵。在其他情況下不要為組框分配訪問鍵--這會使人產生混淆。"確定"按鈕沒有訪問鍵，因為在作為預設按鈕時，它通過提Enter鍵來選定的。"取消" 按鈕也沒有訪問鍵，因為Esc鍵預覽清除模式對話方塊。如果可能，避免使用小寫的g、j、p、q或y作訪問鍵，也避免使用這些字母前後的字母作為訪問鍵。下劃線不能與這些字母的下行字母分開。當然，訪問鍵必須是唯一的。
＊ 避免使用粗體文字 儘量少使用粗體文字。在Windows 3.1 的對話方塊中，粗體文字用於在舊式的視訊硬體上繪製被禁用的文字（即抖動的灰色文字）。因為現在的視訊硬體可以繪製沒有抖動的灰色文字，所以Windows 為了使外觀更加清潔，現在Windows 在對話方塊中使用正常文字。粗體文字僅用於強調。對於大多數對話方塊不要粗體文字。
＊ 提供環境敏感的幫助 對於複雜的對話方塊，應該為整個對話方塊提供環境敏感的幫助（通過幫助按鈕或F1鍵訪問），或者為個別控制元件提供控制元件特定的幫助（通過"這是什麼？"按鈕或Shift＋F1 鍵來訪問），或者同時提供這兩種幫助。
1.3.1.12. 對話方塊的主要命令按鈕
＊ 將主命令按鈕與對話方塊主體分開* 主命令按鈕包括像"確定"、"取消"、"關閉"、"幫助"、"停止"、"隱藏"，以及其他相關按鈕的等命令按鈕。這種分開使主命令按鈕更易於查詢和識別。
＊ 認真選擇對話方塊的方向 在西方文化中，人們習慣於從左到右、從上到下進行閱讀，因此，將主命令按鈕靠底部或右邊放置更容易被發現。您應該選擇對話方塊的外觀比例與螢幕的外觀比例（通常高與寬的比例為3：4）相似的方向。這將使對話方塊的外觀看起來更加舒服，並且更易於在螢幕上進行定位。如果按鈕具有不同的大小，那麼可以將它們放在對話方塊選單底部。當不能確定時，也可以將按鈕放在底部，因為這種定位方式最為常見，也更易於閱讀。
＊ 將排列在底部的主命令按鈕右對齊 右對齊主命令按鈕適合從左到右的閱讀習慣。當只有一個主命令按鈕時，您或許希望例外地將其居中放置。
右對齊主命令按鈕 ＊ 避免使用多行或多列的主命令按鈕 多行或多列的主命令按鈕對使用者是一個打擊。如果有許多主命令按鈕，那麼注意，通常在右邊排成一列與在底部排成一行相比可以放置更多的按鈕。另外，您可以考慮使用命令選單。如果必須使用很多按鈕，那麼注意使用多行別使用多列的效果好。
＊ 對模式對話方塊，通常提供"確定"和"取消"按鈕* 要使用對話方塊，使用者需要能夠方便地識別前進（使用"確定"按鈕）和後退（使用"取消"按鈕）的方式。您可以使用更明確的按鈕代替"確定"按鈕，但絕對不要在模式對話方塊中替換"取消"按鈕，除非用"停止"來表明正在進行的操作無法取消。
＊ 對於非模式對話方塊或或作為主視窗的對話方塊，提供"關閉"按鈕而不提供"確定"和"取消"按鈕* 將"確定"和"取消"按鈕用於非模式對話方塊或作為主視窗的對話方塊可以使對話方塊看起來像是模式對話方塊。而且，當用於非模式環境中時，"確定"和"取消"時沒有什麼意義的。使用"關閉"按鈕可以消除這種混淆。
＊ 通常將"確定"按鈕排第一，"取消"其次，"幫助"最後* "確定"或其等價按鈕通常作為第一個主命令按鈕。"取消"按鈕應該位於"確定 "的右邊或下面。將"確定"和"取消"按鈕放在一起。"幫助"按鈕應該時最後一個按鈕。如果沒有"確定"按鈕，那麼應該將"取消"按鈕放在"幫助"按鈕的前面。這可以使主命令按鈕更易於查詢和識別。
＊ 確保"取消"按鈕真正用於取消操作* 當取消時，程式的狀態列應該與之前顯示的模式對話方塊完全相同。如果不是這樣，那麼應該用"停止"按鈕來代替"取消"按鈕。模式對話方塊中的"取消"按鈕應該與標題欄中的"關閉"按鈕效果相同。而屬性表是個例外，因為"取消"按鈕不會取消已經應用的更改。
1.3.1.13. 屬性表和屬性頁
＊ 讓屬性頁獨立工作 避免使一個屬性頁的行為或操作受其他屬性頁的限止。使用者不可能發現屬性頁之間的這種獨立關係。在屬性頁的使用順序方面應該沒有限止。使用者應該能夠隨時檢視任意的屬性頁。
＊ 屬性頁的佈局相互獨立 一些屬性頁通常不會佔用同樣大小的空間。佔用空間較小的屬性頁應該與最大的屬性頁的佈局的格式方式不同，因為將會產生額外的空間（見下圖）。
屬性頁的佈局保持獨立，避免居中。 ＊ 用屬性表代替使用帶選項卡的對話方塊 使用屬性表而不使用帶選項卡的對話方塊除了具有一致性之外，沒有什麼明顯的實用性優勢。另外，對於實際顯示物件屬性的對話方塊使用屬性表，而對於其他用途，所有帶選項卡的對話方塊。
＊ 對屬性顯示總採用屬性表，即使僅有一個頁* 採用屬性表能夠明確告訴使用者檢視的使屬性而不是一般的對話方塊。屬性表有一個"應用"按鈕來幫助使用者測試設定。
＊ 絕對不要使用兩行以上的標籤* 最好使用一行標籤，但兩行也是可接受的，兩行以上就太多了，可用級連屬性設定或多個對話方塊代替。
＊ 總為屬性提供"應用"按鈕 再說一次，提供"應用"按鈕幫助使用者對設定進行測試。
＊ 對顯示屬性的屬性表總是在其標題中寫上"屬性"一詞和物件的名稱* 請注意，不是所有的屬性表都是用來顯示屬性的。
＊ 總將命令按鈕放在右邊* 適用於所有頁的命令按鈕必須置於標籤頁區域的外面，而僅適用於單個頁的命令按鈕必須置於該標籤頁的裡面。
1.3.1.14. 嚮導
＊ 對高階的、複雜的或不常用的任務使用嚮導 嚮導對非常高階或複雜的任務十分有用，省去了使用者許多麻煩的操作。當嚮導用於不常用的任務時，其效果最好。對常用任務使用嚮導則顯得大而不當。
1.3.1.15. 控制元件
＊ 儘量採用標準控制元件 儘可能採用標準控制元件（6個最早的控制元件和新的Win32常用控制元件）。採用非標準控制元件的程式與絕大多數Windows程式看起來不一致。只用完全合理時才使用自定義控制元件。
＊ 定製標準控制元件時要小心 改變標準控制元件的標準外觀或行為時一定要小心，這是個常常出錯的地方。
＊ 將無效控制元件置為不可用* 將不適用於當前程式狀態的控制元件置為不可用。
＊ 取消不必要滾動條 儘量使控制元件的尺寸足夠大，避免使用滾動條。
1.3.1.16. 命令按鈕
＊ 採用最小的寬度和標準的高度 帶文字的命令按鈕應該採用50個對話單位（75個畫素點）的最小寬度、14個對話單位(21個畫素點)的標準高度。儘量將不同大小的帶文字命令按鈕的個數控制在兩個以內。對父視窗拖動（owner-draw）按鈕或無文字的按鈕（如"…"），其大小可以任意設定，原則是使命令按鈕外觀簡樸一致。高度大於14個對話單位(21個畫素點)的按鈕看起來不夠專業。儘管不限制命令按鈕的最大寬度，但寬度超過200個對話單位的按鈕使不妥當的。請參閱下圖所示關於命令按鈕的例項。
命令按鈕大小示例 ＊ 針對國際化適當加寬按鈕 儘管50個對話單位（75個畫素點）的寬度是適合英語文字的最小寬度，但對需要針對其他語言進行本地化的程式來說，可能就太小了。對於需要翻譯為其他語言的程式，將命令按鈕的最小寬度定為60個對話單位可能更適合。
＊ 將無效按鈕置為不可用，以取消報錯* 絕對不要使可用的按鈕僅產生一條出錯資訊。
＊ 總採用省略號來表示需要更多資訊* 命令中的省略號表示執行命令時需要更多資訊，而不是簡單的確認。省略號並不表示一定會出現對話方塊。
＊ 絕對不要指定雙擊行為* 使用者意料不到命令按鈕會響應雙擊，因此不可能發現這樣的行為。
命令按鈕大小使用Window標準75x21象素。一般情況下，"確定"和"取消"按鈕的屬性設定如下：
btnOk: TButton
Caption = '確定'
Default = True
ModalResult = mrOk
end
object btnCancel: TButton
Cancel = True
Caption = '取消'
ModalResult = mrCancel
End
"確定"和"取消"按鈕一般被對映為Enter鍵和Esc鍵，因此不應該對它們指定訪問鍵，除此以外的命令按鈕都應該指定一個訪問鍵。如下圖：
主命令按鈕在下 如果主命令按鈕在右上角，應該佈置為這樣。 主命令按鈕在上 如有其他不明，請參照命令按鈕。
如果設計期間未指定"ModalResult"，注意一定要在按鈕的"OnClick" 事件程式碼中為"ModalResult"賦值。
1.3.1.17. 複選框
＊ 用複選框開關選項，用單選按鈕改變模式* 用複選框進行選項的開關操作是很有效的，但如果用來將模式改變為另外一種狀態就難免讓人迷惑了。例如，可用一個複選框來表示是否顯示工具欄，但若用複選框來切換印表機的橫向模式和縱向模式就會使人糊塗，對橫向和縱向模式應該用一組單選按鈕代替。
＊ 避免一組複選框中選項個數超過8個 應該考慮用複選框列表代替，它佔用的空間更少，但複選框列表需要滾動時使用就稍稍麻煩了。儘管控制元件足夠或保持與同一視窗中其他複選框一致時，採用複選框時可取的，但大於8個左右的複選框就未免太多了。
＊ 考慮將修改組的複選框置於應該分組框中 這樣的分組使得複選框之間的關係更為明顯。
＊ 寧可豎向對齊 雖然更合適的情況下采用橫向對齊或直角對齊也是可以接受的，但豎向對齊的一組複選框更易於瀏覽。
1.3.1.18. 單選按鈕
＊ 避免一組單選按鈕中的選項個數超過8個 考慮用列表或組合框代替，它們佔用的空間更少，但要記住控制元件使用更麻煩些。儘管控制元件足夠或保持與同一視窗中其他單選按鈕一致時，採用單選按鈕是可取的，但多於8個的單選按鈕未免太多了。
＊ 避免使用單選按鈕進行開 / 關或是 / 否選擇 用複選框代替。
＊ 總將單選按鈕置於一個分組框中* 由於單選按鈕是一組相互排斥的選項，所以分組框使選擇更為明確。
＊ 寧可豎向對齊 雖然更合適的情況下采用橫向對齊或直角對齊也是可以接受的，但豎向對齊的一組單選按鈕更易於瀏覽。
1.3.1.19. 組合框
＊ 總給組合框提供一個標籤* 必須用標籤來表明組合框的用途。
＊ 使組合框的下拉列表最少有5行長 少於5行的列表就沒有可用的滑塊，不易於滾動。請注意，如果組合框沒有足夠的列項來填滿列表，那麼將自動縮短列表的長度。
＊ 避免組合框的列項少於4 考慮用單選按鈕代替，它們雖然多佔空間，但更易於操作。如果空間更為重要或為了保持與同一視窗中的其它組合框一致時，採用組合框則更為可取。
1.3.1.20. 編輯框
＊ 總給編輯框提供一個標籤* 必須用標籤來標明編輯框的用途。如果標籤在左邊，將標籤文字與編輯框文字垂直對齊。
＊ 避免有輸入限制的編輯框 將編輯框用於使用者對任何文字的輸入或數字編輯框用於數字的編輯。對於輸入受限的情況，使用其他的控制元件，如組合框、列表、滑塊和微調框。對於日期和時間，使用日期和時間拾取控制元件。
＊ 用微調框和瀏覽按鈕使編輯框可視 微調框和瀏覽按鈕是簡單的可視機制，它們幫助使用者在編輯框中進行有效的輸入。避免讓使用者必須輸入。僅對數字編採用帶微調框的編輯框，對於文字，使用組合框代替。
＊ 按期望輸入來設定編輯框的寬度 編輯框的寬度是對期望輸入的可視提示。例如，如果使用者是輸入地址，兩個字元寬的State欄位明顯暗示使用者輸入兩個字元的州名縮寫。如果期望的輸入沒有特別的大小，就選擇與其他編輯框或控制元件一致的寬度。
＊ 總採用數字編輯框用於數字輸入* 當用戶在數字欄位中輸入非數字文字時，不應該有任何出錯訊息。
1.3.1.21. 滑塊
＊ 總給滑塊提供一個標籤* 必須用標籤來標明滑塊的用途。而且，滑塊還應該有標明高、低值意義和當前選擇的標籤--當然都不帶冒號。
1.3.1.22. 靜態文字
＊ 左對齊靜態文字標籤 左對齊使得標籤外觀更有條理，且易於瀏覽。
＊ 寧可將靜態文字標籤置於相關控制元件的左邊，而不是上面 這樣對齊使標籤更易於被發現，且方便了標籤和控制元件的瀏覽。很明顯，長控制元件是例外情況，如列表檢視、樹形檢視（Tree）和多行編輯框。
＊ 總在用於標識控制元件的靜態文字標籤後帶上冒號* 使用冒號明顯表示為控制元件標籤的文字。為控制元件提供附加資訊的標籤不應該有冒號，如用來解釋滑塊控制元件的標籤。標籤也可作為螢幕讀出器的輸入資訊。
＊ 對非標籤文字總用只讀編輯框* 只讀編輯框允許使用者將文字複製到剪貼簿上，並在文字比控制元件長時可進行滾動。
＊ 不要把靜態文字置於凸起的邊界上* 在凸起邊界上的靜態文看起來像按鈕，因而使用者會試圖單擊它。
1.3.1.23. 列表框
＊ 總給列表框提供一個標籤* 必須用標籤來標明列表框的用途。
＊ 使列表框至少5行長 少於5行的列表沒有滑塊，不便於滾動。如果列表框沒有滾動條，那麼使用一個更短的列表框也是可以接受的。
＊ 對多個選擇考慮採用複選框 複選框列表可以突出其多個選擇的能力。如果不能接受複選框列表，那麼可以採用多選列表，並用靜態文字表示選項個數，清楚指明可進行多項選擇。
＊ 對多選列表考慮提供"全部選中"和"全部取消選中"命令 由於希望全部選中或全部取消使常見的事情，所以這兩個命令方便了使用者進行多項選擇。
1.3.1.24. 列表檢視
＊ 總給列表檢視提供一個標籤* 必須用標籤來標明列表檢視的用途。
＊ 使列表檢視至少5行長 少於5行的列表檢視沒有滑塊，不便於滾動。如果列表檢視沒有滾動條，那麼使用一個更短的列表檢視也是可以接受的。
＊ 僅在列表可排序時採用可單擊的表頭* 可單擊的表頭只應用於排序。首次單擊時應按正序對列表進行排序，而第二次單擊時按反序進行排列。
＊ 對列項大約超過30的列表檢視總使其可進行排序* 使用者能夠對列表進行排序方便了對資訊的查詢。
1.3.1.25. 滾動條
＊ 滾動條僅用於滾動* 使用滑塊或微調框來設定數值。
＊ 使滾動條足夠長，保證有可用的滑塊。 沒有滑塊的滾動條不便於使用。
1.3.1.26. 分組框
＊ 利用分組框分組相關控制元件 儘管分組框通常是用於單選按鈕的分組，但也可用於任何控制元件的分組。避免使用只有一個控制元件的分組框，除非是為了保持與同一對話方塊中其他分組框一致。
＊ 考慮採用靜態線或文字標籤來代替分組框 分組框多時要佔去許多空間。如果空間緊張的話，一個替代分組控制元件的好辦法是同時採用靜態文字標籤和靜態線。
考慮採用靜態文字標籤和靜態線代替分組框 ＊ 不要在分組框標籤的後面使用冒號* 分組框標籤的意思明白，使用冒號完全沒有必要且讓人糊塗。 1.3.1.27. 選單
＊ 總用單個單詞作為選單標題* 選單欄上多個單詞的選單標題看起來像多個選單標題。
＊ 不要在選單欄的文字間留有空隙* 不一至的選單欄文字既無用，又難看。
＊ 避免佔多行的選單欄* 儘管將父視窗縮小到足夠窄時，任何選單欄都要佔用幾行，當要避免正常使用時因選單項都而佔用幾行的選單欄。
＊ 保持選單穩定* 將無效選單置為不可用，而不要刪除它們。但是，對整個程式例項都無效的選單，就應該刪除。
＊ 合理安排選單項的順序 將相關選單項組合在一起。重要的命令應該位於選單的頂部，而不重要的選單則位於選單的底部。
＊ 將無效選單置為不可用來代替報錯* 選單絕不應該有僅產生出錯訊息的可用命令。
＊ 分配訪問鍵* 訪問鍵使使用者可以手不離開鍵盤進行操作，並提供程式的可訪問性。儘可能避免用小寫字母g、j、p、q、y或單詞中與它們靠近的字母來分配訪問鍵，因為下劃線與下一行的字母不好區分。當然，一個選單中的訪問鍵應該是唯一的。
＊ 總採用省略號來表示需要更多資訊* 命令中的省略號表示執行時需要更多的資訊，而不是簡單確認。省略號不表示一定有對話框出現。
＊ 使用標準選單 避免不提供"檔案"、"編輯"和"幫助"選單。由於這些是標準選單，所以使用者會期望它們出現。例如，期望在"檔案"選單中發現像"列印"和"退出"這樣的命令，雖然這些命令可能與"檔案"無關。同樣，使用者期望在"編輯"選單中發現"剪下"、"複製"和"貼上"命令，至少要在"幫助"選單中發現"關於"命令。
＊ 統一放置"查詢"和"選項"命令 總將"查詢"命令放在"編輯"選單中，而有"工具"選單時，總將"選項"置於其中，否則置於"檢視"選單中。
＊ 用複選標記來開關選項，用單選組來改變模式* 用複選標記進行選項的開關操作是有效的，但如果用來將模式改變為另外一種狀態就難免讓人迷惑了。例如，可用一個複選標記來表示是否顯示工具欄，但若用複選框來切換印表機的橫向模式和縱向模式就會使人糊塗，對橫向和縱向模式應該用一個單選組來代替。
＊ 不要使用多列的下拉選單* 多列增加了選單不必要的複雜性。
＊ 不要使用"Bang"（爆炸的聲音）選單* Bang選單是選單欄上那些看起來像下拉選單，但實際是選擇後立即執行的命令，如"退出"！顯然，使用者希望選單標題就只是選單，而不是命令。
＊ 不要右對齊選單標題* 這樣的選單風格陳舊且不易於使用。
1.3.1.28. 上下文選單
＊ 考慮將上下文選單作為冗餘使用 上下文才選單不應該是訪問命令的唯一方式。通常上下文選單中的命令應該在選單欄中也提供，使用上下文選單是為了提高訪問效率。
＊ 避免在上下文選單中包含快捷鍵 應該將快捷鍵分配在選單欄中，上下文選單的快速訪問是通過滑鼠進行，而不是通過鍵盤。
1.3.1.29. 工具欄
＊ 保持工具欄穩定* 將無效的工具欄按鈕置為不可用，而不是將它刪除。但是，應該考慮刪除使用者進入一種模式用不到的整個工具欄。
＊ 將無效命令置為不可用，而不是報錯* 工具欄絕不應該包含只出現錯誤訊息的命令。
＊ 對實用程式採用大工具欄按鈕 好的使用程式工具欄常常與應用程式的按鈕不同，其按鈕更簡樸，更大。實用程式工具欄應該只包含幾個帶有描述性文字和圖形的顯眼命令。
＊ 對應用程式採用可移動的、可定製的工具欄，而對實用程式採用固定的工具欄 應用程式需要靈活的工具欄來支援其典型的使用方式。使用者使用實用程式的時間一般不長，因而不需要定製工具欄。
＊ 提供顯示或隱藏工具欄選項 如果有多個工具欄，分別為它們提供顯示或隱藏的選項。
＊ 總使用工具提示* 工具提示幫助使用者瞭解工具欄按鈕的作用。
1.3.1.30. 工具提示
＊ 用工具欄的工具提示來提供資訊，但要簡短 避擴音示很明顯的事情。考慮採用省略號來表示執行命令時需要更多資訊。如果該命令已分配有快捷鍵，則顯示該快捷鍵。
＊ 使工具提示文字成為高階使用者的媒介 工具提示用於簡短的識別和提醒，而不是用來教學。
＊ 用工具提示顯示有用資訊 不僅僅可在工具欄上使用工具提示，它的使用簡單，能夠向用戶提供有用資訊。但不可濫用--工具提示太多也就失去了其價值。不要對命令按鈕會靜態文字這樣的控制元件使用工具提示。
＊ 不要自動消去包含許多文字的工具欄提示 預設時，10秒種後工具提示將自動消去。如果工具提示的文字很多，10秒鐘對使用者來說就看不完了。
1.3.1.31. 文字
＊ 避免不必要的縮寫詞 要麼給文字更多的空間，要麼改寫文字使其佔用更少的空間，縮寫詞使文字不易理解。
＊ 避免不必要的大寫字母文字 除非只去首字母構成的縮寫詞，否則不要用字母全為大寫的單詞，這樣的單詞看起來像在衝使用者大喊大叫一樣。
＊ 避免複雜的標號 儘量採用簡單的標點，如句號、逗號、問號，以及破折號。避免使用分號、感嘆號、圓括號、括號，等等。
＊ 採用一致的大小寫規則* 對視窗標題、選單、命令按鈕、列標題屬性頁選項卡以及工具欄提示文字採用與書題一樣的大小寫規則，而對於標題、單選按鈕、複選框、分組框和選單項幫助中的文字採用與句子一致的大小寫規則。（對於標題，除了不是標題開頭和結尾的冠詞和介詞外，每個單詞的第一個字母大小。對於句子，每個句子的第一個單詞以及通常大寫的單詞--如專有名詞的首字母大寫。）
＊ 避免不好的背景 將文字放在實地、顏色適中的背景上，確保在文字和背景之間存在良好的對比。
＊ 避免冒犯性語言 避免激烈的詞語，如fatal（致命的）、execute（執行）、kill（殺死、毀掉）、terminate（終止）、和abort（中止）。
1.3.1.32. 訊息框
＊ 仔細選擇訊息框的型別 採用帶"確定"按鈕的資訊訊息框向用戶提供有關命令結果的資訊。採用帶"是"、"否"，以及可能"取消"按鈕的警告訊息框在繼續進行前需要使用者輸入的情形下告誡使用者。採用危急訊息框通知使用者進行工作前需要修改一個錯誤。
＊ 不要使用疑問訊息框型別* 不再推薦對訊息框使用疑問標記符（MB_ICONQUESTION），因為它在Windows98後一致用來表示上下文修改幫助。
＊ 避免不必要的訊息框 不要用出錯訊息來報告正常行為，而應該用來報告不正常或不期望的結果。不要對很容易恢復的操作進行確認。
＊ 問用是/否回答的問題 問使用者問題時，採用"是"和"否"按鈕代替"確定"和"取消"按鈕，這樣使問題易於理解。與對話方塊中不一樣，"確定"和"取消"按鈕很少同時用在訊息框中。
＊ 確保訊息框選項按鈕與文字一致 例如絕不要用"是"和"否"來作為非提問訊息的響應。同樣，不要使用多個效果相同的選項按鈕。例如，除非有不同的操作結果，否則不要同時提供"否"和"取消"按鈕。"否"按鈕應該執行操作，而"取消"應該取消操作。
＊ 仔細選擇預設按鈕 將最安全的或最常用的選項作為預設按鈕。
＊ 避免無用的幫助 除非提供真正有用的附加資訊，否則不要提供"幫助"按鈕。不要附加帶無用幫助資訊的沒意義的訊息框。
＊ 對危急錯誤考慮採用系統模式訊息框 採用系統模式訊息框向用戶提示嚴重的、可能造成破壞性的、急需注意的錯誤。系統訊息框除了有 WS_EX_TOPMOST樣式外，與應用程式模式對話方塊完全一樣。與在16位Windows中不一樣的是，系統模式不影響使用者與其他程式的互動。
1.3.1.33. 錯誤訊息
＊ 避免錯誤號 除非這個錯誤號對使用者真正有用，否則不要給出錯誤號。
＊ 避免責怪使用者 避免在出錯訊息文字中出現單詞you（你）或your（你的）。如果需要，當指使用者操作時使用被動語氣。採用與"錯誤發生了"等價的表達，比採用與"你捅漏子了"等價的表達要好得多。
＊ 避免敵對性語言 避免在錯誤訊息文字中使用詞語bad（糟糕的、壞的）、caution（小心）、error（錯誤）、fatal（致命的）、illegal（非法）、invalid（無效）和warning（警告），而應該使用更具體的描述性詞語。並且應該儘量解釋到底是什麼出了錯。
＊ 在出錯訊息文字中使用平實的語句 表達要簡短、清楚、協調、具體。除非縮寫詞，否則不要使用全部大寫的單詞，那樣的單詞看起來像在衝使用者大喊大叫一樣。使用完整的句子和一般的現在或過去時態。避免縮寫詞。
＊ 避免在使用者錯誤訊息文字中裝做有趣或高人一等 使用者並不覺得錯誤訊息有趣，故裝幽默並不能被廣泛接受。
＊ 允許使用者壓制非危急的錯誤訊息 對經常出現的非危急錯誤，向用戶提供一個壓制該錯誤訊息的選項。
1.3.1.34. 字型
字型統一使用以下設定：
Charset = GB2312_CHARSET
Name = '宋體'
Size = 9
Color = clWindowText
Style = []
字符集不要使用 ANSI_CHARSET 或 DEFAULT_CHARSET，否則可能導致不同的作業系統下字符集不一致。
＊ 尊重使用者的字型選擇* Windows允許使用者為標題欄、選單、訊息框和工具提示選擇字型。及時處理WM_SETTINGCHANGE訊息以根據設定迅速而安全地改變字型。
＊ 避免讓人分心地字型 一般說來，應避免使用Arial、Tahoma和MS Sans Serif之外的字型。Verdana、TrebuchetMS和Century Gothic也適合於輕微差別的外觀。即使文件中的截線字型很不錯，但介面中的任何截線字型都被認為是讓人分心的。除了提示使用者輸入或模擬打字機外，不要採用等寬字型。
＊ 避免使用粗體和斜體 用粗體來吸引人的注意，用斜體表示著重，但要還少使用。
＊ 避免混合字型 任何不包含文件的視窗最多包含兩種不同的字型。
1.3.1.35. 顏色
＊ 使用系統顏色* 尊重使用者的顏色選擇，避免使用固定顏色。不要強迫使用者使用您選擇的顏色。避免讓人分心的文字顏色，通常是黑色之外任何顏色，對文字使用系統顏色COLOR_BTNTEXT或COLOR_WINDOWTEXT。在白色（COLOR_WINDOW）背景上使用黑色（COLOR_WINDOWTEXT）文字是完全正確的。及時處理WM_SYSCOLORCHANGE訊息以根據設定迅速而完全地改變顏色。
＊ 根據內容而不是外觀來選擇系統顏色* 不要將作為一個集合中的幾種系統顏色混合匹配在一起。例如，不要將COLOR_BTNTEXT和COLOR_WINDOW混合在一起。
＊ 考慮對圖形使用中間調色盤 在256色模式下使用中間色調色盤避免了調色盤的閃爍。
＊ 不要用顏色作為傳遞訊息的唯一方式* 不依賴於對顏色的區分可以增強程式對色盲使用者的可訪問性，並且使程式可執行在單色顯示器上。
1.3.1.36. 三維效果
＊ 避免不必要的三維效果 除非對控制元件分組，否則避免三維靜態線和矩形框。寧可採用空白來分開元件，絕不在三維矩形框周圍套其他的三維矩形框。避免使用三維文字。
三維效果過多 在介面中採用太多的三維效果是程式設計師常範的錯誤。畢竟，如果有些三維效果很酷，對吧？不完全如此。請看下面的對話方塊。一點也不酷。一旦三維控制元件流行起來，就好像能使用三維的都採用三維，而不管看起來是好是壞。即使採用三維邊框，其目的也是為了讓人理解。採用許多三維靜態框架控制元件通常是個壞徵兆，現代的趨時是傾向於更為簡單的風格。 ＊ 使用柔和的三維效果 請注意Window98中更為細緻的三維效果是如何比Window 3.1中的三維效果更有效更悅目的。儘管絕大多數現時世界的物體有加亮區，但很少有黑色實邊框的。Windows98僅是通過在突起物體的右邊和底部加上黑色邊框以及在凹陷物體的上部和左邊加黑色邊框來達到三維效果。 去除多餘的三維效果 最少三維效果 ＊ 使用一致的三維效果* 確保三維效果的光源位於螢幕的左上角。
1.3.1.37. 各種細節
＊ 不要發音和閃動 沒什麼比發音和閃動的程式更煩人的了。但閃爍程式的工作列視窗按鈕通知使用者未決訊息例外。
＊ 避免不必要的視訊效果 至少一個使其為可選擇的。理想情形是，預設時關閉這樣的效果，使用者有明確要求時才打開。
＊ 用縮放功能提高文件可訪問性 提供提供文件縮放功能，可提高顯示文件的程式的可訪問性和整體效能。
＊ 處理WM_DISPLAYCHANGE訊息* 改變顯示解析度後，程式應該能夠正確顯示和執行。
＊ 基於光碟的程式的應該支援自動播放 當光碟插入驅動器後，"自動播放"應該顯示一列選項，包括安裝。程式安裝以後，不應該執行"自動播放"。
＊ 支援使用者 採用日期和時間拾取控制元件進行日期輸入，GetDateFormat和GetTimeFormat函式用於設定貨幣和數字的格式， LCMapString API用於排序。考慮採用RichEdit控制元件用於文字輸入和輸出。最後，利用WM_INPUTLANGCHANGE訊息來處理輸入語言的改變。
1.3.2. 統一術語
1.3.2.1. 術語的重要性
我們用名稱來區別、描述和查詢事物，使用名稱來分解並理解不熟悉的事物。採用統一的術語有助於我們更好地理解和進行交流--簡化並統一使用者介面術語有助於使用者理解和充分應用我們設計的介面。
使用不同的術語描述相同的事物是最讓人迷惑的，而改變人人都已經熟悉的術語也是有害的。這兩種情況都使得程式難以討論、描述，以及歸檔。甚至使它難以程式設計。
1.3.2.2. 命名
下面是一些需要命名的、與介面有關的典型物件：
● 程式本身；
● 程式使用的文件型別；
● 使用者利用程式執行的主要操作；
● 所有的視窗、對話方塊和屬性表；
● 主程式視窗中的使用區域；
● 認為非標準的螢幕物件、命令、屬性、互動、或者技術。
簡而言之，使用者可以看到或需要與其進行互動的、顯示在選單、工具欄、視窗、對話方塊、狀態列、聯機幫助或文件中的任何內容都需要有一個名稱。當然，您將會使用已存在的標準螢幕物件的名稱。例如，您不需要命名常用的對話方塊，因為它們已經擁有名稱。
1.3.2.3. 用使用者的語言說話
使用軟體面向的使用者所熟悉的詞語，除非您的軟體是為了程式設計師設計的，否則應該避免使用計算機行話，而應用常用的單詞代替。例如，對絕大多數使用者來說，常用單詞"separator"（分隔符）就比技術術語"delimiter"（定界符）要好得多。如果必須使用技術詞彙，那麼應採用那些使用者可能知道的術語。
1.3.2.4. 要避免的術語
也有些術語是千萬不要用在您的使用者介面中的。儘管"execute"執行、"kill"（殺死）、"terminate"（結束）、"fatal"（致命的）和"abort"（中止）這樣的術語在程式
1.1. 總體原則
＊ 以使用者為中心。設計由使用者控制的介面，而不是介面控制使用者。
＊ 清楚一致的設計。所有介面的風格保持一致，所有具有相同含義的術語保持一致，且易於理解
＊ 擁有良好的直覺特徵。以使用者所熟悉的現實世界事務的抽象來給使用者暗示和隱喻，來幫助使用者能迅速學會軟體的使用。
＊ 較快的響應速度。
＊ 簡單且美觀。
1.2. 原則詳述
1.2.1. 使用者控制
使用者介面設計的一個重要原則是使用者應該總是感覺在控制軟體而不是感覺被軟體所控制。
＊ 操作上假設是使用者--而不是計算機或軟體--開始動作。使用者扮演主動角色，而不是扮演被動角色。在需要自動執行任務時，要以允許使用者進行選擇或控制它的方式來實現該自動任務。
＊ 提供使用者自定義設定。因為使用者的技能和喜好各不相同，因此他們必須能夠個性化介面的某些方面。Windows為使用者提供了對許多這方面的訪問。您的軟體應該反應不同的系統屬性--例如顏色、字型或其他選項的使用者設定。
＊ 採取互動式和易於感應的視窗，儘量避免使用模態對話方塊，而使用"非模式"輔助視窗。 "模式"是一種狀態，它排除一般的互動，或者限制使用者只能進行特定的互動。當最好使用一個模式或該模式只是可替換的設計時--例如，用於在一個繪圖程式中選定一個特定感覺--請確保該模式是顯然的、可見的，是一個明確的使用者選定的結果，並且容易取消。
＊ 在後臺執行長程序時，保持前臺式互動。例如，當正在列印一個文件，即使該文件不能被改變，使用者也應該可以最小化該視窗。
＊ 諒解。使用者喜歡探索一個介面，並經常從嘗試和錯誤中學習。一個有效的介面允許互動式的發現，它只提供一組合適的選擇，並在使用者可能破壞系統或資料的情況時發出警告。如果可行，還應提供可逆轉或可還原的操作。即使在設計得很好得介面中，使用者也可能犯錯誤。這些錯誤既可以是物理上得（偶然地指向了錯誤的命令或資料），也可以是邏輯上的（對選定哪一個命令或哪些資料做出了錯誤的決定）。有效的設計避免很可能導致錯誤的情況。它還包容潛在的使用者錯誤，並且使使用者易於還原。
1.2.2. 清楚一致的設計
一致允許使用者將已有的知識傳遞到新的任務中，更快地學習新事物，並將更多的注意力集中在任務上。這是因為他們不必花時間來嘗試記住互動中的不同。通過提供一種穩定的感覺，一致使得介面熟悉而又可預測。一致在介面的所有方面都是很重要的，包括命令的名稱、資訊的可視表示，操作行為，以及元素在螢幕和視窗內部的放置。
＊ 相同含義的詞使用統一的術語。比如對於倉庫中存放的物料，不可同時又稱為物品、貨物、備品、產品和材料等等，而統一約定一個稱謂，且此稱謂是使用者熟悉的和易於理解的。
＊ 使用一組一致的命令和介面來展示常見功能。例如，避免一個"複製"命令在一種情況下立刻執行一個操作，但在另一種情況顯示一個對話方塊要求使用者鍵入目標然後才執行。應該使用同樣的命令來執行對使用者來說相似的功能。
＊ 操作環境內的一致。保持Windows提供的互動操作和介面約定之間的高度一致，使用者將能很快熟悉軟體的使用。
＊ 使用隱喻的一致性。如果一個特定的行為更多的是一個不同的事物的特徵，而不是它的隱喻的含義，那麼使用者可能在學習將行為和該事物相關聯時遇到困難。例如，對於放在回收站中的物件而言，焚燒爐和廢紙籮代表不同的模型。
＊ 建立專案保留字。通過建立保留字來明確和統一術語和操作命令。
＊ 提供可視反饋。在後臺執行長程序時（時間超過1～10秒，視具體情況而定），必須提供進度條等資訊指示。
＊ 除非特別必要時，不要提供聲音反饋。在有嚴重的問題發生時，可以使用聲音來提示使用者，但是通常應該允許使用者取消聲音。
＊ 保持文字內容清楚。資訊的表達要言簡意賅，易於理解而又不羅嗦；避免使用冗長的文字給使用者反饋。
1.2.3. 有良好的直覺特徵
＊ 用熟悉的隱喻為使用者的任務提供直接而直觀的介面。通過允許使用者利用他們的知識和經驗，隱喻使得預測和學習基於軟體的表示的行為更加容易。
＊ 在使用隱喻時，不需要將基於計算機的實現侷限在真實世界的對應物上範圍之內。例如，與其基於紙張的對應物不同，Windows桌面上的資料夾可以被用來組織各種物件，例如印表機、計算器、以及其他資料夾。同樣，Windows資料夾可以其真實世界對應物不可能的方式被排序。在介面中使用隱喻的目的是提供一個認知的橋樑；隱喻並不以其自身為最終目的。
＊ 隱喻支援使用者認知而不是記憶。使用者記起與一個熟悉的事物相關聯的意義要比他們記起一個特定命令的名稱要容易得多。
＊ 同常見軟體保持一致性。出色的使用者介面在程式中將實現同用戶以前用過的其它成功軟體一致的動作。
1.2.4. 較快的響應速度
＊ 保持介面能很快對使用者操作作出反應。
＊ 提供快捷鍵。特別對於有大量錄入項的介面，能讓使用者不使用滑鼠即可完成快速資料錄入。在使用者介面中加入一些功能，這些功能可以讓熟練使用者在不同的區域快速的輸入資料。這些功能包括重複功能、快捷鍵、帶有有意義的圖示的按鈕等等，所有這些可以使速度快的使用者可以控制介面並加快資料的輸入。
＊ 除非必要，不要重繪螢幕。
1.2.5. 簡單且美觀
＊ 簡單。介面應該很簡單（不是過分單純化）、易於學習、並且易於使用。它還必須提供對應用程式的所有功能的訪問。在介面中，擴大功能和保持簡單是相互矛盾的。一個有效的設計應該平衡這些目標。支援簡單性的一種方法是將資訊的表示減少到進行充分交流所需的最少資訊。例如，避免命令名和訊息的文字描述。不相關或冗長的句子擾亂了您的設計，使得使用者難以很容易地提取重要資訊。另一個設計簡單而有用的介面的方法是使用自然的對映和語意。介面元素的排列和表示影響它們的意義和關聯。簡單還與熟悉相互關聯。熟悉的事物通常似乎更簡單。儘可能嘗試建立利用使用者已有的知識和經歷的聯絡。您可以使用漸進揭示來幫助使用者管理複雜的事物。"漸進揭示"涉及到仔細的資訊組織，以便只在恰當的時候才顯示資訊。通過隱藏向用戶表達的資訊，您減少了使用者必須處理的資訊數量。例如，您可以使用選單來顯示操作或選擇的列表，還可以使用對話方塊來顯示一組選項。漸進揭示並不意味著對顯示資訊使用非傳統的技術，例如需要一個修飾鍵作為訪問基本功能的唯一方法，或者強迫使用者通過一個更長的分級互動序列。這會使使用者介面更加複雜和麻煩。
＊ 美觀。可視設計是應用程式介面的重要部分。可視屬性提供了非常好的印象，並傳達特定物件的互動行為的重要線索。同時，出現在螢幕上的每一個可視元素也是很重要的，它們可能競爭使用者的注意。提供清楚地促進使用者對錶達的資訊的理解的連貫環境。圖形或可視設計器的技巧對於這一方面是無價的。
1.3. 細節約定
1.3.1. 介面風格
1.3.1.1. 普通外觀
＊ 使用一致性 一致的外觀將使使用者介面更易於理解和使用。使用者介面控制元件看起來應該是一致的。
＊ 使用安排和流程 在西方文化中（包括中國），人們習慣於從左到右，從上到下進行閱讀，因此，應該將重要資訊放在上面和左邊。左上角最容易吸引起人們的注意力。
＊ 使用對齊 通常，使用左對齊來使使用者介面控制元件更易於瀏覽。對於數值文字，應該使用小數點對齊或右對齊。對於非數值文字，應該避免使用右對齊或居中對齊。不必對什麼都使用中間對齊，或者使它們保持對稱形式。在右邊或底部保留空白區域更適合習慣。
＊ 使用分組 將相關的使用者介面控制元件分成組，以體現它們之間的關係。同時，還要顯示相關資訊。將控制元件放在它所作用的物件旁。使用空格、分組框、線條和標籤，或者其它分隔符對使用者介面控制元件進行分組。
＊ 使用強調 使用焦點、位置、分組、層次、啟用/禁用、大小、顏色或者字型等，來將注意力集中在需要首先看到的使用者介面控制元件上。儘量以可視的方式指明使用者接下來應該進行的操作。
＊ 使用可視的提示 儘量使用近似的大小和間距來指出使用者介面控制元件是相似的，而使用不同的大小和間距來指出使用者介面控制元件視是不同的。
＊ 使用空格 使用空格來建立一個"透氣室"，以使窗口布局更易於理解，並且檢視起來更舒服。空格的多少要適當，不要顯得太分散。但是，要避免過多地使用空格。如果可能，儘量使視窗小一些。
＊ 警惕空洞 不要到處貼上公司或產品的名稱及徽標。雖然在啟動屏或"關於"框中出現公司或產品名稱及徽標是完全可以接受的，但其他視窗中的可用空間應該出現其他內容。如果沒有其他內容，那麼應儘量使視窗小一些。
＊ 注意大小 使用使用者介面控制元件的解析度具有獨立性。使用系統規格（使用GetGystemMetrics API 函式）或文字規格（使用GetTextMetrics或GetTextExtentPoint32 API 函式）來確定使用者介面控制元件的大小。任何顯示文字的物件（如對話方塊或定義的文字文件）都應該使用文字規格。
＊ 考慮使用資源或預定義的佈局網格 資源模板或預定義的佈局網格有助於您在不同的視窗之間實現一致性。
注意，下頁所示圖的第二個對話方塊，與第一個不同，它有一個緊湊、從左到右、從上到下的流程，並且，左對齊的標籤很便於瀏覽；通過對齊編輯框並調整其大小，使它顯得更有組織，更加平衡。
1.3.1.2. Windows的可視提示
暗示與使用者只需通過檢視可視提示來確定物件的使用方式的能力有關。在Windows中，請保持使用下面的可視提示：
＊ 可以單擊凸起的專案。
＊ 可以單擊當滑鼠從其上移過時突出顯示的專案。
＊ 不能單擊下凹的專案。
＊ 可以編輯具有白色背景和閃爍垂直條（游標）的專案。
＊ 不能編輯具有灰色背景的專案。
＊ 灰色專案是被禁用的。
＊ 可以拖動凸起的專案。
1.3.1.3. 互動
＊ 儘量提供對所有功能的鍵盤訪問 理想情況下，除了繪圖這樣的圖形功能，其他所有的功能都應該只能通過鍵盤來訪問。
＊ 儘量提供對所有功能的滑鼠訪問 理想情況下，除了文字輸入外，其他所有功能都應該只能通過滑鼠來訪問。
＊ 確保具有明顯後果的操作要求使用者進行明確的選擇* 使用者需要完全明確他將要進行危險性操作或破壞性操作。
＊ 對於使有耗時的操作都給出反饋* 在進行長時間的操作時，要確保有等待游標、進度表或其他的可視反饋。使用者應該能夠取消長時間的操作。如果可以取消未完成的操作，那麼將按鈕標記為"取消"，否則將按鈕標記為"停止"。
＊ 可視的指示模式* 向用戶提供一種可視的反饋，以指出使用者進入一種模式，通常可以通過更改游標或標題欄文字來做到這一點。
＊ 確保單擊和雙擊的一致性* 單擊用於非按鈕選定，而雙擊用於選定並執行預設操作。換句話說，雙擊（在列表框、組合框，或其他接受雙擊的控制元件中）的效果應該與選定控制元件中的一個專案，然後按下Enter鍵的效果一樣。
＊ 滑鼠右鍵僅用於快捷選單* 確保滑鼠右鍵僅用於快捷選單，而不要用於其他用途。
＊ 不要使用滑鼠中鍵* 如果使用者的滑鼠有中鍵，那麼讓使用者使用"控制面板"中的"滑鼠"實用程式自己分配中鍵的行為。
＊ 保持分配的快捷鍵的一致性 組合功能鍵和Ctrl鍵用於快捷鍵。習慣上不將Alt鍵用於組合鍵，業務Alt鍵常常被用於訪問鍵。儘量避免使用Alt鍵和Ctrl鍵，因為這種組合會使快捷鍵非常麻煩，而且也很不方便。
＊ 將快捷鍵作為補充方式* 千萬不要將快捷鍵作為訪問命令的唯一方法。應該讓使用者有更多的明顯選擇。
＊ 避免水平滾動條 與垂直滾動條不同，水平滾動條並不受歡迎，因為它會使專案閱讀起來比較困難。解決的辦法有：儘量使用垂直滾動條、加寬視窗、減小文字的寬度，或者使文字自動換行等。當然，如果確實需要，還可以使用水平滾動條。
1.3.1.4. 程式
＊ 只有主程式窗口才有標題欄圖示、選單欄、工具欄和狀態列* 因為單擊主視窗的工作列按鈕也會啟用二級視窗，所以二級視窗絕對不要顯示在工作列中。二級視窗不要因為使用選單欄、工具欄或狀態列而使其變得複雜。可以使用標題欄圖示來明顯區分主視窗和二級視窗。另外，絕對不要使用預設的 Windows圖示(飄動的視窗圖示)作為視窗圖示。
＊ 簡化預設配置 讓使用者按自己的速度來學習和使用程式。
＊ 應用程式應該使用多文件介面（MDI）或單文件（SDI） 這些程式介面應該與應用程式的使用模式匹配。
＊ 預設情況下，應用程式應該保持為最大化 當應用程式佔用整個螢幕時，常常能夠提高使用者的工作效率。
＊ 實用程式應該使用SDI或對話方塊介面 這些程式介面應該與實用程式的使用模式匹配。對於實用程式，建議不要使用MDI介面，因為管理這些視窗需要付出很多努力。
＊ 實用程式應該在小螢幕範圍內執行 實用程式常常與其他程式一起執行，因此它們需要在小螢幕範圍內執行。實用程式應該有靈活的窗口布局，以適應多種不同的大小。實用程式很少以最大化的形式執行。
＊ 使用實際文件的SDI程式必須支援執行多個例項* 執行多個例項使使用者能夠同時操作多個文件。
＊ 使用"退出"命令終止程式 使用"退出"終止程式；使用"關閉"移走主視窗和非模式對話方塊；使用"取消"移走模式對話方塊。當關閉主視窗並不表示終止程序時，對於主視窗使用"關閉"來代替使用"退出"。例如：關閉印表機狀態視窗不會取消列印任務。
1.3.1.5. 預設
＊ 儲存和恢復使用者選擇 程式應該能夠能夠恢復到其最後退出的狀態。MDI程式應該能夠恢復文件視窗的大小和位置。對話方塊通常應該使用最後輸入的值作為預設值。
＊ 提供適當的預設值 提供提供適當的預設值來減少使用者不必要的操作，從而幫助使用者完成工作。提供最可能使用並給出設定實際使用方式的預設值。通常，最好的預設值是使用者最後輸入的值。
＊ 考慮選擇預設值時的安全性* 不應該將不可恢復或破壞性的操作設定為預設值。不要使用令使用者感到莫名其妙的預設值。
1.3.1.6. 窗體
對話方塊窗體大小盡量不要超過640*460，留20給工作列。並且高和寬（或W寬和高）的比應該大致保持為3:4（或4：3）。一般應該將窗體的"Position"屬性定義為 "poDesktopCenter"，"WindowState"屬性為"wsNormal"，某些主介面設定為"wsMaximized"。 "ShowHint"屬性設為"True"。如果是模式對話方塊，則將"BorderStyle"屬性設定為"bsDialog"。
窗體檔案(*.dfm)儲存為文字格式，以便在VSS中比較不同版本之間的差別。如果窗體大小超過螢幕大小，則在Delphi開發環境中開啟時，大小會有改變，並且影響到執行時刻效果。由於每個人的螢幕大小設定不一樣，有些是1024*768，有些是800*600，因此在設計期間請注意窗體大小，儘量不要超過800*600，以免出現上述問題。
1.3.1.7. 佈局和間距
窗體控制元件佈局和間距儘量保持與Windows標準一致。控制元件與窗體的上、下、左、右邊距為7象素。右下角主命令按鈕之間的間距為6象素，如果主命令按鈕在右上角，之間的間距則為4象素。主命令按鈕一般情況為75×21象素，如果按鈕的文字很長，應該適當加寬按鈕的寬度。如下圖。其它詳細資料請完全參照錯誤！書籤自引用無效。和命令按鈕。
控制元件的"TabOrder"屬性值應該與控制元件排列順序一致，即遵循從上到下、從左到右這樣一個流程。如果在PageControl的多個頁面中存在類似的控制元件，應該儘量使得它們在各個頁面中出現的位置/大小比較一致，以免在頁面間切換時產生閃爍感。 1.3.1.8. 圖示、圖片
不同介面中的同一功能應該使用同樣的圖示和圖片。圖示、圖片的色調、風格儘量保持一致。圖示、圖片的隱喻應能確切表示功能的含義，如果不能，就直接使用文字，以免混淆使用者。如果功能是一個動作時，可能比較難找到確切表示該功能的圖示，這時應該儘量採用此動作相關的名詞做圖示。例如 Windows中的"剪下"功能就是用一把剪刀來表示的。
1.3.1.9. 提示資訊（Hint）
工具欄按鈕應該設定工具提示 "Hint" 屬性。Hint能幫助使用者更方便地理解和使用。詳細資料可以參照工具欄、工具提示。
如果使用了"TSpeedButton"控制元件，並且只有圖示，同樣應對它設定"Hint"屬性。如果不是特殊情況，應儘量避免使用"TSpeedButton"控制元件，而使用"TButton"控制元件代替。
1.3.1.10. 標點符號
在標識控制元件用途的標籤文字（Label）和提示資訊（Hint）中，應使用半形符號。如果是指導性標籤文字（如解釋按鈕功能的句子），則使用全形符號，並且句子應遵循中文標點符號標準。如下圖Microsoft標準對話方塊例子。其他詳細資料可參照靜態文字。
1.3.1.11. 對話方塊
＊ 對話方塊應該在所有視訊模式下都能夠正確顯示 當在VGA模式（640×480）下顯示時，對話方塊應該不超過640×460（留20畫素給工作列）。這將確保對話方塊能夠顯示在所有的視訊模式下。
＊ 確保模式對話方塊的模式* 確保使用具有父視窗的模式對話方塊都提供正確的父視窗控制代碼，而不時提供NULL控制代碼。如果沒有提供父視窗控制代碼，那麼父視窗仍處於活動狀態，因此該對話方塊實際上並不是模式對話方塊。
＊ 不要使用可滾動的對話方塊* 也就是說，不要使用需要滾動條來進行完全檢視的對話方塊。這種對話方塊使用起來非常不方便，並且也時完全不必要的。應該重新設計這種對話方塊。
＊ 不要在作為二級視窗的對話方塊中使用選單欄* 使用這種對話方塊需要付出很多努力。注意，在用作主視窗的對話方塊（如"查詢"實用工具）中，選單欄時可以接受的。還要注意的是，在所有對話方塊中，快捷選單和選單按鈕都是可以接受的。
二級對話方塊不要使用選單欄，但可以使用選單按鈕。 ＊ 不要在作為二級視窗的對話方塊中使用標題欄圖示* 標題欄圖示用於區別主視窗和二級視窗。
＊ 不要在工作列上顯示作為二級視窗的對話方塊* 注意，單擊主視窗的的工作列圖示也將啟用二級視窗。
＊ 對話方塊中使用下頁圖所示的頁面佈局和間距。
＊ 對於相似的對話方塊，使用控制元件位置來強調其相似性。 如果意義相同的同一控制元件出現在一些相似的對話方塊中，那麼它應該顯示在相同的位置。另一方面，應避免將可能會產生混淆的不同控制元件放在同一位置。
＊ 對非模式對話方塊最好使用可停放的對話方塊 可停放對話方塊在功能上與非模式對話方塊是等效的，但其位置設定更為靈活。
＊ 策略地設定輸入焦點 將最初的輸入焦點設定在最可能首先使用的控制元件上。
＊ 在對話方塊標題文字中不要出現省略號 例如，作為選擇"列印選項..."命令結果而顯示地對話方塊的標題應該為"對於選項"。但是，表示命令正在執行過程中選單對話方塊（如"連線到Internet..."對話方塊）是一種例外情況。
＊ 為所有可處理訪問鍵的控制元件分配訪問鍵* 訪問鍵可以使使用者的手保持在鍵盤上，從而使訪問程式更加方便。您可以直接在其標題中為諸如命令按鈕、單選按鈕、複選框等控制元件分配訪問鍵。通過提供靜態文字標籤或帶有訪問鍵、在Tab順序上先於控制元件的組框，您可以為諸如編輯框、列表框、組合框等控制元件分配訪問鍵。在其他情況下不要為組框分配訪問鍵--這會使人產生混淆。"確定"按鈕沒有訪問鍵，因為在作為預設按鈕時，它通過提Enter鍵來選定的。"取消" 按鈕也沒有訪問鍵，因為Esc鍵預覽清除模式對話方塊。如果可能，避免使用小寫的g、j、p、q或y作訪問鍵，也避免使用這些字母前後的字母作為訪問鍵。下劃線不能與這些字母的下行字母分開。當然，訪問鍵必須是唯一的。
＊ 避免使用粗體文字 儘量少使用粗體文字。在Windows 3.1 的對話方塊中，粗體文字用於在舊式的視訊硬體上繪製被禁用的文字（即抖動的灰色文字）。因為現在的視訊硬體可以繪製沒有抖動的灰色文字，所以Windows 為了使外觀更加清潔，現在Windows 在對話方塊中使用正常文字。粗體文字僅用於強調。對於大多數對話方塊不要粗體文字。
＊ 提供環境敏感的幫助 對於複雜的對話方塊，應該為整個對話方塊提供環境敏感的幫助（通過幫助按鈕或F1鍵訪問），或者為個別控制元件提供控制元件特定的幫助（通過"這是什麼？"按鈕或Shift＋F1 鍵來訪問），或者同時提供這兩種幫助。
1.3.1.12. 對話方塊的主要命令按鈕
＊ 將主命令按鈕與對話方塊主體分開* 主命令按鈕包括像"確定"、"取消"、"關閉"、"幫助"、"停止"、"隱藏"，以及其他相關按鈕的等命令按鈕。這種分開使主命令按鈕更易於查詢和識別。
＊ 認真選擇對話方塊的方向 在西方文化中，人們習慣於從左到右、從上到下進行閱讀，因此，將主命令按鈕靠底部或右邊放置更容易被發現。您應該選擇對話方塊的外觀比例與螢幕的外觀比例（通常高與寬的比例為3：4）相似的方向。這將使對話方塊的外觀看起來更加舒服，並且更易於在螢幕上進行定位。如果按鈕具有不同的大小，那麼可以將它們放在對話方塊選單底部。當不能確定時，也可以將按鈕放在底部，因為這種定位方式最為常見，也更易於閱讀。
＊ 將排列在底部的主命令按鈕右對齊 右對齊主命令按鈕適合從左到右的閱讀習慣。當只有一個主命令按鈕時，您或許希望例外地將其居中放置。
右對齊主命令按鈕 ＊ 避免使用多行或多列的主命令按鈕 多行或多列的主命令按鈕對使用者是一個打擊。如果有許多主命令按鈕，那麼注意，通常在右邊排成一列與在底部排成一行相比可以放置更多的按鈕。另外，您可以考慮使用命令選單。如果必須使用很多按鈕，那麼注意使用多行別使用多列的效果好。
＊ 對模式對話方塊，通常提供"確定"和"取消"按鈕* 要使用對話方塊，使用者需要能夠方便地識別前進（使用"確定"按鈕）和後退（使用"取消"按鈕）的方式。您可以使用更明確的按鈕代替"確定"按鈕，但絕對不要在模式對話方塊中替換"取消"按鈕，除非用"停止"來表明正在進行的操作無法取消。
＊ 對於非模式對話方塊或或作為主視窗的對話方塊，提供"關閉"按鈕而不提供"確定"和"取消"按鈕* 將"確定"和"取消"按鈕用於非模式對話方塊或作為主視窗的對話方塊可以使對話方塊看起來像是模式對話方塊。而且，當用於非模式環境中時，"確定"和"取消"時沒有什麼意義的。使用"關閉"按鈕可以消除這種混淆。
＊ 通常將"確定"按鈕排第一，"取消"其次，"幫助"最後* "確定"或其等價按鈕通常作為第一個主命令按鈕。"取消"按鈕應該位於"確定 "的右邊或下面。將"確定"和"取消"按鈕放在一起。"幫助"按鈕應該時最後一個按鈕。如果沒有"確定"按鈕，那麼應該將"取消"按鈕放在"幫助"按鈕的前面。這可以使主命令按鈕更易於查詢和識別。
＊ 確保"取消"按鈕真正用於取消操作* 當取消時，程式的狀態列應該與之前顯示的模式對話方塊完全相同。如果不是這樣，那麼應該用"停止"按鈕來代替"取消"按鈕。模式對話方塊中的"取消"按鈕應該與標題欄中的"關閉"按鈕效果相同。而屬性表是個例外，因為"取消"按鈕不會取消已經應用的更改。
1.3.1.13. 屬性表和屬性頁
＊ 讓屬性頁獨立工作 避免使一個屬性頁的行為或操作受其他屬性頁的限止。使用者不可能發現屬性頁之間的這種獨立關係。在屬性頁的使用順序方面應該沒有限止。使用者應該能夠隨時檢視任意的屬性頁。
＊ 屬性頁的佈局相互獨立 一些屬性頁通常不會佔用同樣大小的空間。佔用空間較小的屬性頁應該與最大的屬性頁的佈局的格式方式不同，因為將會產生額外的空間（見下圖）。
屬性頁的佈局保持獨立，避免居中。 ＊ 用屬性表代替使用帶選項卡的對話方塊 使用屬性表而不使用帶選項卡的對話方塊除了具有一致性之外，沒有什麼明顯的實用性優勢。另外，對於實際顯示物件屬性的對話方塊使用屬性表，而對於其他用途，所有帶選項卡的對話方塊。
＊ 對屬性顯示總採用屬性表，即使僅有一個頁* 採用屬性表能夠明確告訴使用者檢視的使屬性而不是一般的對話方塊。屬性表有一個"應用"按鈕來幫助使用者測試設定。
＊ 絕對不要使用兩行以上的標籤* 最好使用一行標籤，但兩行也是可接受的，兩行以上就太多了，可用級連屬性設定或多個對話方塊代替。
＊ 總為屬性提供"應用"按鈕 再說一次，提供"應用"按鈕幫助使用者對設定進行測試。
＊ 對顯示屬性的屬性表總是在其標題中寫上"屬性"一詞和物件的名稱* 請注意，不是所有的屬性表都是用來顯示屬性的。
＊ 總將命令按鈕放在右邊* 適用於所有頁的命令按鈕必須置於標籤頁區域的外面，而僅適用於單個頁的命令按鈕必須置於該標籤頁的裡面。
1.3.1.14. 嚮導
＊ 對高階的、複雜的或不常用的任務使用嚮導 嚮導對非常高階或複雜的任務十分有用，省去了使用者許多麻煩的操作。當嚮導用於不常用的任務時，其效果最好。對常用任務使用嚮導則顯得大而不當。
1.3.1.15. 控制元件
＊ 儘量採用標準控制元件 儘可能採用標準控制元件（6個最早的控制元件和新的Win32常用控制元件）。採用非標準控制元件的程式與絕大多數Windows程式看起來不一致。只用完全合理時才使用自定義控制元件。
＊ 定製標準控制元件時要小心 改變標準控制元件的標準外觀或行為時一定要小心，這是個常常出錯的地方。
＊ 將無效控制元件置為不可用* 將不適用於當前程式狀態的控制元件置為不可用。
＊ 取消不必要滾動條 儘量使控制元件的尺寸足夠大，避免使用滾動條。
1.3.1.16. 命令按鈕
＊ 採用最小的寬度和標準的高度 帶文字的命令按鈕應該採用50個對話單位（75個畫素點）的最小寬度、14個對話單位(21個畫素點)的標準高度。儘量將不同大小的帶文字命令按鈕的個數控制在兩個以內。對父視窗拖動（owner-draw）按鈕或無文字的按鈕（如"…"），其大小可以任意設定，原則是使命令按鈕外觀簡樸一致。高度大於14個對話單位(21個畫素點)的按鈕看起來不夠專業。儘管不限制命令按鈕的最大寬度，但寬度超過200個對話單位的按鈕使不妥當的。請參閱下圖所示關於命令按鈕的例項。
命令按鈕大小示例 ＊ 針對國際化適當加寬按鈕 儘管50個對話單位（75個畫素點）的寬度是適合英語文字的最小寬度，但對需要針對其他語言進行本地化的程式來說，可能就太小了。對於需要翻譯為其他語言的程式，將命令按鈕的最小寬度定為60個對話單位可能更適合。
＊ 將無效按鈕置為不可用，以取消報錯* 絕對不要使可用的按鈕僅產生一條出錯資訊。
＊ 總採用省略號來表示需要更多資訊* 命令中的省略號表示執行命令時需要更多資訊，而不是簡單的確認。省略號並不表示一定會出現對話方塊。
＊ 絕對不要指定雙擊行為* 使用者意料不到命令按鈕會響應雙擊，因此不可能發現這樣的行為。
命令按鈕大小使用Window標準75x21象素。一般情況下，"確定"和"取消"按鈕的屬性設定如下：
btnOk: TButton
Caption = '確定'
Default = True
ModalResult = mrOk
end
object btnCancel: TButton
Cancel = True
Caption = '取消'
ModalResult = mrCancel
End
"確定"和"取消"按鈕一般被對映為Enter鍵和Esc鍵，因此不應該對它們指定訪問鍵，除此以外的命令按鈕都應該指定一個訪問鍵。如下圖：
主命令按鈕在下 如果主命令按鈕在右上角，應該佈置為這樣。 主命令按鈕在上 如有其他不明，請參照命令按鈕。
如果設計期間未指定"ModalResult"，注意一定要在按鈕的"OnClick" 事件程式碼中為"ModalResult"賦值。
1.3.1.17. 複選框
＊ 用複選框開關選項，用單選按鈕改變模式* 用複選框進行選項的開關操作是很有效的，但如果用來將模式改變為另外一種狀態就難免讓人迷惑了。例如，可用一個複選框來表示是否顯示工具欄，但若用複選框來切換印表機的橫向模式和縱向模式就會使人糊塗，對橫向和縱向模式應該用一組單選按鈕代替。
＊ 避免一組複選框中選項個數超過8個 應該考慮用複選框列表代替，它佔用的空間更少，但複選框列表需要滾動時使用就稍稍麻煩了。儘管控制元件足夠或保持與同一視窗中其他複選框一致時，採用複選框時可取的，但大於8個左右的複選框就未免太多了。
＊ 考慮將修改組的複選框置於應該分組框中 這樣的分組使得複選框之間的關係更為明顯。
＊ 寧可豎向對齊 雖然更合適的情況下采用橫向對齊或直角對齊也是可以接受的，但豎向對齊的一組複選框更易於瀏覽。
1.3.1.18. 單選按鈕
＊ 避免一組單選按鈕中的選項個數超過8個 考慮用列表或組合框代替，它們佔用的空間更少，但要記住控制元件使用更麻煩些。儘管控制元件足夠或保持與同一視窗中其他單選按鈕一致時，採用單選按鈕是可取的，但多於8個的單選按鈕未免太多了。
＊ 避免使用單選按鈕進行開 / 關或是 / 否選擇 用複選框代替。
＊ 總將單選按鈕置於一個分組框中* 由於單選按鈕是一組相互排斥的選項，所以分組框使選擇更為明確。
＊ 寧可豎向對齊 雖然更合適的情況下采用橫向對齊或直角對齊也是可以接受的，但豎向對齊的一組單選按鈕更易於瀏覽。
1.3.1.19. 組合框
＊ 總給組合框提供一個標籤* 必須用標籤來表明組合框的用途。
＊ 使組合框的下拉列表最少有5行長 少於5行的列表就沒有可用的滑塊，不易於滾動。請注意，如果組合框沒有足夠的列項來填滿列表，那麼將自動縮短列表的長度。
＊ 避免組合框的列項少於4 考慮用單選按鈕代替，它們雖然多佔空間，但更易於操作。如果空間更為重要或為了保持與同一視窗中的其它組合框一致時，採用組合框則更為可取。
1.3.1.20. 編輯框
＊ 總給編輯框提供一個標籤* 必須用標籤來標明編輯框的用途。如果標籤在左邊，將標籤文字與編輯框文字垂直對齊。
＊ 避免有輸入限制的編輯框 將編輯框用於使用者對任何文字的輸入或數字編輯框用於數字的編輯。對於輸入受限的情況，使用其他的控制元件，如組合框、列表、滑塊和微調框。對於日期和時間，使用日期和時間拾取控制元件。
＊ 用微調框和瀏覽按鈕使編輯框可視 微調框和瀏覽按鈕是簡單的可視機制，它們幫助使用者在編輯框中進行有效的輸入。避免讓使用者必須輸入。僅對數字編採用帶微調框的編輯框，對於文字，使用組合框代替。
＊ 按期望輸入來設定編輯框的寬度 編輯框的寬度是對期望輸入的可視提示。例如，如果使用者是輸入地址，兩個字元寬的State欄位明顯暗示使用者輸入兩個字元的州名縮寫。如果期望的輸入沒有特別的大小，就選擇與其他編輯框或控制元件一致的寬度。
＊ 總採用數字編輯框用於數字輸入* 當用戶在數字欄位中輸入非數字文字時，不應該有任何出錯訊息。
1.3.1.21. 滑塊
＊ 總給滑塊提供一個標籤* 必須用標籤來標明滑塊的用途。而且，滑塊還應該有標明高、低值意義和當前選擇的標籤--當然都不帶冒號。
1.3.1.22. 靜態文字
＊ 左對齊靜態文字標籤 左對齊使得標籤外觀更有條理，且易於瀏覽。
＊ 寧可將靜態文字標籤置於相關控制元件的左邊，而不是上面 這樣對齊使標籤更易於被發現，且方便了標籤和控制元件的瀏覽。很明顯，長控制元件是例外情況，如列表檢視、樹形檢視（Tree）和多行編輯框。
＊ 總在用於標識控制元件的靜態文字標籤後帶上冒號* 使用冒號明顯表示為控制元件標籤的文字。為控制元件提供附加資訊的標籤不應該有冒號，如用來解釋滑塊控制元件的標籤。標籤也可作為螢幕讀出器的輸入資訊。
＊ 對非標籤文字總用只讀編輯框* 只讀編輯框允許使用者將文字複製到剪貼簿上，並在文字比控制元件長時可進行滾動。
＊ 不要把靜態文字置於凸起的邊界上* 在凸起邊界上的靜態文看起來像按鈕，因而使用者會試圖單擊它。
1.3.1.23. 列表框
＊ 總給列表框提供一個標籤* 必須用標籤來標明列表框的用途。
＊ 使列表框至少5行長 少於5行的列表沒有滑塊，不便於滾動。如果列表框沒有滾動條，那麼使用一個更短的列表框也是可以接受的。
＊ 對多個選擇考慮採用複選框 複選框列表可以突出其多個選擇的能力。如果不能接受複選框列表，那麼可以採用多選列表，並用靜態文字表示選項個數，清楚指明可進行多項選擇。
＊ 對多選列表考慮提供"全部選中"和"全部取消選中"命令 由於希望全部選中或全部取消使常見的事情，所以這兩個命令方便了使用者進行多項選擇。
1.3.1.24. 列表檢視
＊ 總給列表檢視提供一個標籤* 必須用標籤來標明列表檢視的用途。
＊ 使列表檢視至少5行長 少於5行的列表檢視沒有滑塊，不便於滾動。如果列表檢視沒有滾動條，那麼使用一個更短的列表檢視也是可以接受的。
＊ 僅在列表可排序時採用可單擊的表頭* 可單擊的表頭只應用於排序。首次單擊時應按正序對列表進行排序，而第二次單擊時按反序進行排列。
＊ 對列項大約超過30的列表檢視總使其可進行排序* 使用者能夠對列表進行排序方便了對資訊的查詢。
1.3.1.25. 滾動條
＊ 滾動條僅用於滾動* 使用滑塊或微調框來設定數值。
＊ 使滾動條足夠長，保證有可用的滑塊。 沒有滑塊的滾動條不便於使用。
1.3.1.26. 分組框
＊ 利用分組框分組相關控制元件 儘管分組框通常是用於單選按鈕的分組，但也可用於任何控制元件的分組。避免使用只有一個控制元件的分組框，除非是為了保持與同一對話方塊中其他分組框一致。
＊ 考慮採用靜態線或文字標籤來代替分組框 分組框多時要佔去許多空間。如果空間緊張的話，一個替代分組控制元件的好辦法是同時採用靜態文字標籤和靜態線。
考慮採用靜態文字標籤和靜態線代替分組框 ＊ 不要在分組框標籤的後面使用冒號* 分組框標籤的意思明白，使用冒號完全沒有必要且讓人糊塗。 1.3.1.27. 選單
＊ 總用單個單詞作為選單標題* 選單欄上多個單詞的選單標題看起來像多個選單標題。
＊ 不要在選單欄的文字間留有空隙* 不一至的選單欄文字既無用，又難看。
＊ 避免佔多行的選單欄* 儘管將父視窗縮小到足夠窄時，任何選單欄都要佔用幾行，當要避免正常使用時因選單項都而佔用幾行的選單欄。
＊ 保持選單穩定* 將無效選單置為不可用，而不要刪除它們。但是，對整個程式例項都無效的選單，就應該刪除。
＊ 合理安排選單項的順序 將相關選單項組合在一起。重要的命令應該位於選單的頂部，而不重要的選單則位於選單的底部。
＊ 將無效選單置為不可用來代替報錯* 選單絕不應該有僅產生出錯訊息的可用命令。
＊ 分配訪問鍵* 訪問鍵使使用者可以手不離開鍵盤進行操作，並提供程式的可訪問性。儘可能避免用小寫字母g、j、p、q、y或單詞中與它們靠近的字母來分配訪問鍵，因為下劃線與下一行的字母不好區分。當然，一個選單中的訪問鍵應該是唯一的。
＊ 總採用省略號來表示需要更多資訊* 命令中的省略號表示執行時需要更多的資訊，而不是簡單確認。省略號不表示一定有對話框出現。
＊ 使用標準選單 避免不提供"檔案"、"編輯"和"幫助"選單。由於這些是標準選單，所以使用者會期望它們出現。例如，期望在"檔案"選單中發現像"列印"和"退出"這樣的命令，雖然這些命令可能與"檔案"無關。同樣，使用者期望在"編輯"選單中發現"剪下"、"複製"和"貼上"命令，至少要在"幫助"選單中發現"關於"命令。
＊ 統一放置"查詢"和"選項"命令 總將"查詢"命令放在"編輯"選單中，而有"工具"選單時，總將"選項"置於其中，否則置於"檢視"選單中。
＊ 用複選標記來開關選項，用單選組來改變模式* 用複選標記進行選項的開關操作是有效的，但如果用來將模式改變為另外一種狀態就難免讓人迷惑了。例如，可用一個複選標記來表示是否顯示工具欄，但若用複選框來切換印表機的橫向模式和縱向模式就會使人糊塗，對橫向和縱向模式應該用一個單選組來代替。
＊ 不要使用多列的下拉選單* 多列增加了選單不必要的複雜性。
＊ 不要使用"Bang"（爆炸的聲音）選單* Bang選單是選單欄上那些看起來像下拉選單，但實際是選擇後立即執行的命令，如"退出"！顯然，使用者希望選單標題就只是選單，而不是命令。
＊ 不要右對齊選單標題* 這樣的選單風格陳舊且不易於使用。
1.3.1.28. 上下文選單
＊ 考慮將上下文選單作為冗餘使用 上下文才選單不應該是訪問命令的唯一方式。通常上下文選單中的命令應該在選單欄中也提供，使用上下文選單是為了提高訪問效率。
＊ 避免在上下文選單中包含快捷鍵 應該將快捷鍵分配在選單欄中，上下文選單的快速訪問是通過滑鼠進行，而不是通過鍵盤。
1.3.1.29. 工具欄
＊ 保持工具欄穩定* 將無效的工具欄按鈕置為不可用，而不是將它刪除。但是，應該考慮刪除使用者進入一種模式用不到的整個工具欄。
＊ 將無效命令置為不可用，而不是報錯* 工具欄絕不應該包含只出現錯誤訊息的命令。
＊ 對實用程式採用大工具欄按鈕 好的使用程式工具欄常常與應用程式的按鈕不同，其按鈕更簡樸，更大。實用程式工具欄應該只包含幾個帶有描述性文字和圖形的顯眼命令。
＊ 對應用程式採用可移動的、可定製的工具欄，而對實用程式採用固定的工具欄 應用程式需要靈活的工具欄來支援其典型的使用方式。使用者使用實用程式的時間一般不長，因而不需要定製工具欄。
＊ 提供顯示或隱藏工具欄選項 如果有多個工具欄，分別為它們提供顯示或隱藏的選項。
＊ 總使用工具提示* 工具提示幫助使用者瞭解工具欄按鈕的作用。
1.3.1.30. 工具提示
＊ 用工具欄的工具提示來提供資訊，但要簡短 避擴音示很明顯的事情。考慮採用省略號來表示執行命令時需要更多資訊。如果該命令已分配有快捷鍵，則顯示該快捷鍵。
＊ 使工具提示文字成為高階使用者的媒介 工具提示用於簡短的識別和提醒，而不是用來教學。
＊ 用工具提示顯示有用資訊 不僅僅可在工具欄上使用工具提示，它的使用簡單，能夠向用戶提供有用資訊。但不可濫用--工具提示太多也就失去了其價值。不要對命令按鈕會靜態文字這樣的控制元件使用工具提示。
＊ 不要自動消去包含許多文字的工具欄提示 預設時，10秒種後工具提示將自動消去。如果工具提示的文字很多，10秒鐘對使用者來說就看不完了。
1.3.1.31. 文字
＊ 避免不必要的縮寫詞 要麼給文字更多的空間，要麼改寫文字使其佔用更少的空間，縮寫詞使文字不易理解。
＊ 避免不必要的大寫字母文字 除非只去首字母構成的縮寫詞，否則不要用字母全為大寫的單詞，這樣的單詞看起來像在衝使用者大喊大叫一樣。
＊ 避免複雜的標號 儘量採用簡單的標點，如句號、逗號、問號，以及破折號。避免使用分號、感嘆號、圓括號、括號，等等。
＊ 採用一致的大小寫規則* 對視窗標題、選單、命令按鈕、列標題屬性頁選項卡以及工具欄提示文字採用與書題一樣的大小寫規則，而對於標題、單選按鈕、複選框、分組框和選單項幫助中的文字採用與句子一致的大小寫規則。（對於標題，除了不是標題開頭和結尾的冠詞和介詞外，每個單詞的第一個字母大小。對於句子，每個句子的第一個單詞以及通常大寫的單詞--如專有名詞的首字母大寫。）
＊ 避免不好的背景 將文字放在實地、顏色適中的背景上，確保在文字和背景之間存在良好的對比。
＊ 避免冒犯性語言 避免激烈的詞語，如fatal（致命的）、execute（執行）、kill（殺死、毀掉）、terminate（終止）、和abort（中止）。
1.3.1.32. 訊息框
＊ 仔細選擇訊息框的型別 採用帶"確定"按鈕的資訊訊息框向用戶提供有關命令結果的資訊。採用帶"是"、"否"，以及可能"取消"按鈕的警告訊息框在繼續進行前需要使用者輸入的情形下告誡使用者。採用危急訊息框通知使用者進行工作前需要修改一個錯誤。
＊ 不要使用疑問訊息框型別* 不再推薦對訊息框使用疑問標記符（MB_ICONQUESTION），因為它在Windows98後一致用來表示上下文修改幫助。
＊ 避免不必要的訊息框 不要用出錯訊息來報告正常行為，而應該用來報告不正常或不期望的結果。不要對很容易恢復的操作進行確認。
＊ 問用是/否回答的問題 問使用者問題時，採用"是"和"否"按鈕代替"確定"和"取消"按鈕，這樣使問題易於理解。與對話方塊中不一樣，"確定"和"取消"按鈕很少同時用在訊息框中。
＊ 確保訊息框選項按鈕與文字一致 例如絕不要用"是"和"否"來作為非提問訊息的響應。同樣，不要使用多個效果相同的選項按鈕。例如，除非有不同的操作結果，否則不要同時提供"否"和"取消"按鈕。"否"按鈕應該執行操作，而"取消"應該取消操作。
＊ 仔細選擇預設按鈕 將最安全的或最常用的選項作為預設按鈕。
＊ 避免無用的幫助 除非提供真正有用的附加資訊，否則不要提供"幫助"按鈕。不要附加帶無用幫助資訊的沒意義的訊息框。
＊ 對危急錯誤考慮採用系統模式訊息框 採用系統模式訊息框向用戶提示嚴重的、可能造成破壞性的、急需注意的錯誤。系統訊息框除了有 WS_EX_TOPMOST樣式外，與應用程式模式對話方塊完全一樣。與在16位Windows中不一樣的是，系統模式不影響使用者與其他程式的互動。
1.3.1.33. 錯誤訊息
＊ 避免錯誤號 除非這個錯誤號對使用者真正有用，否則不要給出錯誤號。
＊ 避免責怪使用者 避免在出錯訊息文字中出現單詞you（你）或your（你的）。如果需要，當指使用者操作時使用被動語氣。採用與"錯誤發生了"等價的表達，比採用與"你捅漏子了"等價的表達要好得多。
＊ 避免敵對性語言 避免在錯誤訊息文字中使用詞語bad（糟糕的、壞的）、caution（小心）、error（錯誤）、fatal（致命的）、illegal（非法）、invalid（無效）和warning（警告），而應該使用更具體的描述性詞語。並且應該儘量解釋到底是什麼出了錯。
＊ 在出錯訊息文字中使用平實的語句 表達要簡短、清楚、協調、具體。除非縮寫詞，否則不要使用全部大寫的單詞，那樣的單詞看起來像在衝使用者大喊大叫一樣。使用完整的句子和一般的現在或過去時態。避免縮寫詞。
＊ 避免在使用者錯誤訊息文字中裝做有趣或高人一等 使用者並不覺得錯誤訊息有趣，故裝幽默並不能被廣泛接受。
＊ 允許使用者壓制非危急的錯誤訊息 對經常出現的非危急錯誤，向用戶提供一個壓制該錯誤訊息的選項。
1.3.1.34. 字型
字型統一使用以下設定：
Charset = GB2312_CHARSET
Name = '宋體'
Size = 9
Color = clWindowText
Style = []
字符集不要使用 ANSI_CHARSET 或 DEFAULT_CHARSET，否則可能導致不同的作業系統下字符集不一致。
＊ 尊重使用者的字型選擇* Windows允許使用者為標題欄、選單、訊息框和工具提示選擇字型。及時處理WM_SETTINGCHANGE訊息以根據設定迅速而安全地改變字型。
＊ 避免讓人分心地字型 一般說來，應避免使用Arial、Tahoma和MS Sans Serif之外的字型。Verdana、TrebuchetMS和Century Gothic也適合於輕微差別的外觀。即使文件中的截線字型很不錯，但介面中的任何截線字型都被認為是讓人分心的。除了提示使用者輸入或模擬打字機外，不要採用等寬字型。
＊ 避免使用粗體和斜體 用粗體來吸引人的注意，用斜體表示著重，但要還少使用。
＊ 避免混合字型 任何不包含文件的視窗最多包含兩種不同的字型。
1.3.1.35. 顏色
＊ 使用系統顏色* 尊重使用者的顏色選擇，避免使用固定顏色。不要強迫使用者使用您選擇的顏色。避免讓人分心的文字顏色，通常是黑色之外任何顏色，對文字使用系統顏色COLOR_BTNTEXT或COLOR_WINDOWTEXT。在白色（COLOR_WINDOW）背景上使用黑色（COLOR_WINDOWTEXT）文字是完全正確的。及時處理WM_SYSCOLORCHANGE訊息以根據設定迅速而完全地改變顏色。
＊ 根據內容而不是外觀來選擇系統顏色* 不要將作為一個集合中的幾種系統顏色混合匹配在一起。例如，不要將COLOR_BTNTEXT和COLOR_WINDOW混合在一起。
＊ 考慮對圖形使用中間調色盤 在256色模式下使用中間色調色盤避免了調色盤的閃爍。
＊ 不要用顏色作為傳遞訊息的唯一方式* 不依賴於對顏色的區分可以增強程式對色盲使用者的可訪問性，並且使程式可執行在單色顯示器上。
1.3.1.36. 三維效果
＊ 避免不必要的三維效果 除非對控制元件分組，否則避免三維靜態線和矩形框。寧可採用空白來分開元件，絕不在三維矩形框周圍套其他的三維矩形框。避免使用三維文字。
三維效果過多 在介面中採用太多的三維效果是程式設計師常範的錯誤。畢竟，如果有些三維效果很酷，對吧？不完全如此。請看下面的對話方塊。一點也不酷。一旦三維控制元件流行起來，就好像能使用三維的都採用三維，而不管看起來是好是壞。即使採用三維邊框，其目的也是為了讓人理解。採用許多三維靜態框架控制元件通常是個壞徵兆，現代的趨時是傾向於更為簡單的風格。 ＊ 使用柔和的三維效果 請注意Window98中更為細緻的三維效果是如何比Window 3.1中的三維效果更有效更悅目的。儘管絕大多數現時世界的物體有加亮區，但很少有黑色實邊框的。Windows98僅是通過在突起物體的右邊和底部加上黑色邊框以及在凹陷物體的上部和左邊加黑色邊框來達到三維效果。 去除多餘的三維效果 最少三維效果 ＊ 使用一致的三維效果* 確保三維效果的光源位於螢幕的左上角。
1.3.1.37. 各種細節
＊ 不要發音和閃動 沒什麼比發音和閃動的程式更煩人的了。但閃爍程式的工作列視窗按鈕通知使用者未決訊息例外。
＊ 避免不必要的視訊效果 至少一個使其為可選擇的。理想情形是，預設時關閉這樣的效果，使用者有明確要求時才打開。
＊ 用縮放功能提高文件可訪問性 提供提供文件縮放功能，可提高顯示文件的程式的可訪問性和整體效能。
＊ 處理WM_DISPLAYCHANGE訊息* 改變顯示解析度後，程式應該能夠正確顯示和執行。
＊ 基於光碟的程式的應該支援自動播放 當光碟插入驅動器後，"自動播放"應該顯示一列選項，包括安裝。程式安裝以後，不應該執行"自動播放"。
＊ 支援使用者 採用日期和時間拾取控制元件進行日期輸入，GetDateFormat和GetTimeFormat函式用於設定貨幣和數字的格式， LCMapString API用於排序。考慮採用RichEdit控制元件用於文字輸入和輸出。最後，利用WM_INPUTLANGCHANGE訊息來處理輸入語言的改變。
1.3.2. 統一術語
1.3.2.1. 術語的重要性
我們用名稱來區別、描述和查詢事物，使用名稱來分解並理解不熟悉的事物。採用統一的術語有助於我們更好地理解和進行交流--簡化並統一使用者介面術語有助於使用者理解和充分應用我們設計的介面。
使用不同的術語描述相同的事物是最讓人迷惑的，而改變人人都已經熟悉的術語也是有害的。這兩種情況都使得程式難以討論、描述，以及歸檔。甚至使它難以程式設計。
1.3.2.2. 命名
下面是一些需要命名的、與介面有關的典型物件：
● 程式本身；
● 程式使用的文件型別；
● 使用者利用程式執行的主要操作；
● 所有的視窗、對話方塊和屬性表；
● 主程式視窗中的使用區域；
● 認為非標準的螢幕物件、命令、屬性、互動、或者技術。
簡而言之，使用者可以看到或需要與其進行互動的、顯示在選單、工具欄、視窗、對話方塊、狀態列、聯機幫助或文件中的任何內容都需要有一個名稱。當然，您將會使用已存在的標準螢幕物件的名稱。例如，您不需要命名常用的對話方塊，因為它們已經擁有名稱。
1.3.2.3. 用使用者的語言說話
使用軟體面向的使用者所熟悉的詞語，除非您的軟體是為了程式設計師設計的，否則應該避免使用計算機行話，而應用常用的單詞代替。例如，對絕大多數使用者來說，常用單詞"separator"（分隔符）就比技術術語"delimiter"（定界符）要好得多。如果必須使用技術詞彙，那麼應採用那些使用者可能知道的術語。
1.3.2.4. 要避免的術語
也有些術語是千萬不要用在您的使用者介面中的。儘管"execute"執行、"kill"（殺死）、"terminate"（結束）、"fatal"（致命的）和"abort"（中止）這樣的術語在程式