下面是已經發表過的一些使用者介面設計準則。
norman（1983a）
從研究中得到的推論
■模式錯誤意味著需要更好的反饋。
■描述錯誤說明需要更好的系統配置。
■缺乏一致性會導致錯誤。
■獲取錯誤意味著需要避免相互重疊的命令佇列。
■啟用的問題說明了提醒的重要性。
■人會犯錯，所以要讓系統對錯誤不敏感。
教訓
■反饋使用者應該能夠清楚地了解系統的狀態。最好是以清晰明確的形式展現系統狀態，從而避免在對模式的判斷上犯錯。
■響應序列的相似度不同型別的操作應有不同型別的指令序列（或者選單操作模式），從而避免使用者在響應的獲取和描述上犯錯。
■操作應該是可逆的應盡可能可逆。對有重要後果且不可逆的操作，應提高難度以防止誤操作。
■系統的一致性系統在其結構和指令設計上應保持一致的風格，從而儘量減少使用者因記錯或者記不起如何操作引發問題。
shneiderman（1987）；shneiderman & plaisant（2009）
■力爭一致性。
■提供全面的可用性。
■提供資訊充足的反饋。
■設計任務流程以完成任務。
■預防錯誤。
■允許容易的操作反轉。
■讓使用者覺得他們在掌控。
■盡可能減輕短期記憶的負擔。
nielsen & molich
■一致性和標準。
■系統狀態的可見性。
■系統與真實世界的匹配。
■使用者的控制與自由。
■錯誤預防。
■識別而不是回憶。
■使用應靈活高效。
■具有美感的和極簡主義的設計。
■幫助使用者識別、診斷錯誤，並從錯誤中恢復。
stone et al.（2005）
■可見性朝向目標的第一步應該清晰。
■自解釋控制項本身能夠提示使用方法。
■反饋對已經發生了或者正在發生的情況提供清晰的說明。
■簡單化盡可能簡單並能專注具體任務。
■結構內容組織應有條理。
■一致性相似從而可預期。
■容錯性避免錯誤，能夠從錯誤中恢復。
■可訪問性即使有故障，訪問裝置或者環境條件存在制約，也要使所有目標使用者都能夠使用。
johnson（2007）
原則1：專注於使用者和他們的任務，而不是技術
■了解使用者。
■了解所執行的任務。
■考慮軟體執行環境。
原則2：先考慮功能，再考慮展示。
■開發乙個概念模型。
原則3：與使用者看任務的角度一致
■要爭取盡可能自然。
■使用使用者所用的詞彙，而不是一自己創造的。
■封裝，不暴露程式的內部運作。
■找到功能與複雜度的平衡點。
原則4：為常見的情況而設計
■保證常見的結果容易實現。
■兩類「常見」：「很多人」與「很經常」。
■為核心情況而設計，不要糾結於「邊緣」情況。
原則5：不要把使用者的任務複雜化
■不給使用者額外的問題。
■清除那些使用者經過琢磨推導才會用到的東西。
原則6：方便學習
■「從外向內」而不是「從內向外」思考。
■一致，一致，還是一致。
■提供乙個低風險的學習環境。
原則7：傳遞資訊，而不是資料
■仔細設計顯示，爭取專業的幫助。
■螢幕是使用者的。
■保持顯示的慣性。
原則8：為響應度而設計
■即刻確認使用者的操作。
■讓使用者知道軟體是否在忙。
■在等待時允許使用者做別的事情。
■動畫要做到平滑和清晰。
■讓使用者能夠終止長時間的操作。
■讓使用者能夠預計操作所需的時間。
■盡可能讓使用者來掌控自己的工作節奏。
原則9：讓使用者試用後再修改
■測試結果會讓設計者（甚至是經驗豐富的設計者）感到驚訝。
■安排時間糾正測試發現的問題。
■測試有兩個目的：資訊目的和社會目的。
■每乙個階段和每乙個目標都要有測試。
著名的使用者介面設計準則
結論 模式錯誤意味著需要更好的反饋 描述錯誤說明需要更好的系統配置 缺乏一致性會導致錯誤 獲取錯誤意味著需要避免相互重疊的命令序列 啟用的問題說明了提醒的重要性 人會犯錯，所以要讓系統對錯誤資訊不敏感 指系統的容錯性高 教訓反饋 使用者應該能夠清楚地了解到系統的狀態，最好是以清晰明確的方式展現系統狀...
使用者介面設計準則從何而來
對當前的討論而言，這些設計準則的共性 它們的基礎和起源，比每套設計準則的具體規則更重要。這些設計準則從何而來？它們的作者只是像時裝設計師一樣，試圖將個人的設計品味強加在計算機和軟體業上嗎？如果是這樣，這些設計準則會因各自作者追求與眾不同而變得非常不一樣。實際上，忽略在措辭 強調點以及撰寫時計算機技術...
使用者介面設計準則從何而來
對當前的討論而言，這些設計準則的共性 它們的基礎和起源，比每套設計準則的具體規則更重要。這些設計準則從何而來？它們的作者只是像時裝設計師一樣，試圖將個人的設計品味強加在計算機和軟體業上嗎？如果是這樣，這些設計準則會因各自作者追求與眾不同而變得非常不一樣。實際上，忽略在措辭 強調點以及撰寫時計算機技術...