設計人機介面有很多種方式， User Study 應該仍然是最重要也最難在小公司實現的一環。對很多公司來說，除非先前曾經有過慘痛的失敗經驗，不然人機介面設計的預算往往低到不行，所以也只能祈禱工程師設計出來的介面不會太難用了。

不過，這樣的流程會讓介面設計的討論流於情緒化，往往公司裡面會有這樣的對話:

PM: 「我覺得這個按鈕放這裡不對。」
工程師: 「為什麼？」
PM: 「我也不知道，但我就是覺得怪怪的。」
工程師: 「好吧，我改。」

如果 “覺得怪怪的” 是客戶說的，也許我還是可以視為 user study 的一環，但是 PM 並不是 user；這樣的討論最後往往沒有什麼好的結果，為了大家說不出來的 “感覺”，爭得臉紅脖子粗。

所以，如果有一些原則可以遵守，找出自己覺得奇怪的原因，就可以讓討論更為理性。

因此，可用性之王 – 賈扣尼爾森 (Jakob Nielson) 提出了十條評估的假說，供設計者參考。這十條本身就有重疊或互斥的地方，但是至少大家可以就這方面的優劣討論。例如，這種設計是遵照大部份同類網站的設計；或、在這個情境下，為了引起使用者注意，所以我們特別不用業界的設計。

在這裡把這十條翻譯一下，並舉一些實例。引用文字是他的原文翻譯，舉例的部份是我個人的解釋。

系統狀態的能見度 (Visibility of System Status)

系統應該透過適時和適當的 feedback，讓使用者知道發生了什麼事，

例：設計 AJAX 介面時，如果有什麼功能需要比較長的時間，畫面上應該有 “執行中..” 等字眼；如果跑一跑掛掉了，也應該把訊息改成 “執行失敗” 而不能讓使用者等很久沒反應。

系統設計應與現實世界一致

系統應該採用使用者熟悉的詞、句、或概念，而不是系統內部的詞句。採用現實世界的慣例，讓資訊以大家習慣的方式呈現。

例：對使用者來說，「無法連線到資料庫」比起「一個無法復原的例外已經產生」好多了。同時，如果你要設計一個控制面板，內有兩個開關分別操作左右兩個視窗，你應該把兩個開關也放成一左一右，而不是放成一上一下，這樣使用者可以直接知道左邊的控制左邊的。

提供使用者控制與自由

使用者常常會誤觸系統的功能，所以會需要 “緊急出口” 的功能來回復資料，提供 undo 和 redo 的功能。

例: 如果使用者在結帳的過程中想要修改訂單，他應該要能自由的跳到修改該資料的頁面而不會漏掉其他資料；如果填某個表格很花時間，要提供使用者誤刪資料時的 undo 功能。

一致性與遵照標準

使用者應該不需要思考不同的詞、狀況或動作，是否會對系統產生不同的效果。遵照平台的標準。

例: “啟用” (enable) 是個中性的字眼，有時候工程師會直接把系統的 “啟用” 當作使用者的 “啟用”，例如，”啟用不過濾廣告信功能”，也許在系統中這功能真的是叫 “不過濾廣告信”，但是對使用者來說，”啟用廣告信過濾” 和 “停用廣告信過濾” 才合理。如果確認鍵在類似的平台中都在左邊(相對於取消)，除非你想要引起使用者注意，不然應該也設計在左邊。如果真實世界裡面左邊大多是開啟，右邊是關閉；或紅色鍵通常是停止、綠色是開始，就不要設計相反的。

預防犯錯

一開始就預防使用者出錯比好的錯誤訊息更好，消除容易讓使用者搞錯的情境，或是提供確認鍵、讓使用者在執行前再度確認。

例: 將付款結帳的按鈕設計在容易看得見的地方並清楚標示，按下之後會再跳出視窗再次確認。

讓使用者辨識 (Recognition) 而非回想 (Recall)

利用標示清楚的按鈕、功能、選項減少使用者的記憶負擔，使用者不用記住從一個選項到另一個選項之間的資訊，操作系統的資訊應該顯而易見、或馬上可以找到。

例: 如果網頁上需要使用者輸入信用卡的資訊，應該要在表格上面清楚標示系統可以接受的輸入格式 (卡號要不要加 -, 日期用哪一種格式)，而不是讓使用者記住你們接受什麼格式；系統的 help 選單應該在每一個頁面都放在同樣的位置，例如，頁面右上角或表格旁邊的問號。

使用的彈性與效率

提供快速鍵讓有經驗的老手可以快速操作系統，但隱藏起來讓新手不會受這些功能影響，如此可以同時讓新手和老手都能有效的操作系統。讓使用者可以自訂常用的功能。

例: 在網頁的輸入表單，確保按 tab 鍵可以跳到下一個應填的資料欄。網頁相簿提供上一張、下一張的熱鍵。

美學及極簡主義者的設計

對話框中不應該包括不相關或是很少用到的資訊，多餘的資訊和重要的資訊相互排擠，會讓使用者分心。

例: 在網頁上填寫信用卡資訊時，如果需要使用者提供信用卡的檢查碼，這時候教導使用者找到檢查碼是附屬的資訊，我們需要告訴使用者這個資訊，但不應該把整個放在此頁上，而是提供一個明顯的 “這是什麼?” 連結讓使用者可以查詢 help 資訊。

幫助使用者辨認、診斷甚至復原錯誤

錯誤訊息應該以白話文表達，而非機器語言；精準的指出錯誤，並提供解決方式。

例如: 網頁的 Internal Server Error 並沒有告訴使用者任何事；如果使用者在填一個表單，而其中有一個必填的欄位未填，則明確的顯示出未填的欄位及 “此欄位不能是空白”，不要只寫 “所有必填的欄位都需要填寫”。如果錯誤和某一個資料有關，清楚的寫出是哪一個錯誤，例如: “您所選擇的位置已被購買，請選擇其他位置” 或 “我們無法使用您提供的信用卡下單，請換一張信用卡”，而不是 “訂位時發生錯誤”。

幫助及說明文件

即便系統已設計到不需說明文件就可操作，幫助和說明文件仍是必要的。所有這類資訊應該很容易找到、重點放在使用者要完成的任務上、列出明確的步驟並且儘可能精簡。

例: 找出新手可能會看不懂的字眼，在旁邊或附近加上點選後可以開啟的說明。系統重要的功能應該都有說明，並可以一步步照著做。除非必要，不然不要花篇幅解系統原理。

原文參見: Ten Usability Heuristics