可用性的維度
當我檢查可用性文獻時，我發現可用軟件包含如用戶友好、易學、可發現性、質量、有用的和阻止錯誤。在可用性工程中， Jakob Nielsen給出一個產品的五個屬性：易學性、效率、可記憶性、容錯（低錯誤，容易恢復）和滿意度。從我的觀點，我認為有：
- 有效性（Effective）
- 效率（Efficient）
- 吸引的（Engaging）
- 容錯（Error tolerant）
- 易學（Easy to learn）
首先，使用首位字母都是E的詞剛開始看做是一個游戲，但我同樣想尋找一個方法來使可用性的維度方便記憶，於是5E誕生了。
有效性
有效性是第一個E。主要表明軟件是可用的，而且幫助用戶准確地實現他們的目標。如果用戶不能實際完成他們准備做的事情（或做了不必要的事情），無論體驗的長短都失去了意義。最后用戶沒有完成任務或達到他們的目標。如果設計者能夠測量有效性，就可以理解人們如何定義成功或有用。
效率
效率是所做工作的速度（與精確性要求相關）。效率可以被詳細地定義。例如，在一個呼叫中心，衡量客服人員一天能處理的呼叫數量。或者它是一個主觀的判斷，當一個任務執行“太長“或需要“太多的點擊“。
吸引
關於吸引的簡單定義就是一個界面的愉快、滿意或興趣程度。所有的軟件都會給用戶帶來情緒上的影響，但這個維度的重要性隨着程序的類型會發生變化。在一個辦公軟件中，一個吸引人的界面可以使人投入工作，幫助他在工作中建立信心，或在表達信息方式上特別容易閱讀。這個可視的表示和風格或交互的質量都會使軟件更加吸引人。
容錯
容錯包含產品防止錯誤的程度和幫助用戶從錯誤中恢復。輕觸鼠標就會點擊一下。如果你錯讀了一個連接，需要按原路返回，或輸入相關內容。實際測試是在錯誤產生時了解軟件如何進行幫助的。
易學
易學和產品如何支持初次使用和更深度的學習相關。一個產品可以使用一次，或一會兒，或一天。它可以完成一個容易的或復雜的任務，用戶可能是一個專家或新手。但每一次使用，界面必須能夠記憶或重新學習，而且使用一段時間后能夠發掘更多的功能。
平衡的問題
如果在每個產品中，對於每個用戶，可用性的每個要素都是同等重要的，那么就會出現圖1中的情景，但實際情況顯然不是這樣的。而且這個提供了一個機會來可以更好地理解一個產品的可用性需求。在5E中的平衡可以確定界面設計的方向。換句話說，可以理解可用性依賴哪些內容。在表1中，我們可以看到一個利潤管理業務的兩類用戶一個雇員和一個利潤專家——他們有不同的需要。對於兩個用戶，都必須具有有效性，但利潤專家的需求更多地放在效率上。對於雇員，效率與易學、容錯和軟件吸引人的程度相比，要被放在一個次要的地位上。
通過可用性進行思考帶來的價值要比簡單理解用戶的利益走得更遠。它可以作為項目管理的一個工具，幫助選擇項目過程中用於用戶研究和可用性評估的技術。它可以在必要時進行平衡，給出設計方法和辨別方向。 
一個以用戶為中心的步驟
大多數UCD過程都符合ISO13407的通用綱要：在交互系統中以人為中心的設計過程。以一個發現過程開始，然后在研究——設計/原型——評估步驟中循環直到項目完成。整個項目創建出一個設計步驟，並且測試確保任務的結構和組織是正確的。然后，用同樣的迭代進行分析、設計和評估每一個功能與設計，直到所有的功能都被集成到整個設計架構。最后通過可用性測試完成對軟件發布前的檢查。在整個生命周期都可以應用這些過程，將可用性和交互設計工作嵌入到過程的所有階段，從最初的產品概念一直到整個開發周期（見圖2）。 
當然，UCD工作的強度是不一樣的——在設計階段高，在實現階段低。在每一個階段，團隊必須決定哪些UCD活動可以最好地支持產品。
依表進行設想
設計者不是在每一個新項目中都是一張白紙。無論項目是一個已有程序的新版本，還是完全是一個新產品，團隊都會在工業或商業領域中工作過。團隊有過成功的經歷，當然也有問題（或完全直接的失敗），而且他們都會有設想，也會把過去經驗的帶到新項目中。制作一個表格采集這個信息。而且因為團隊需要給出願景，所以構建了一個用戶和可用性需求的藍圖。
表1不同的用戶，不同的可用性需求
雇員
利潤呼叫中心專家
公司的所有雇員，必須在他們的個人信息或利益選擇中使用利潤管理業務。他們並不經常使用這個應用。在這個業務應用之前，他們通常要通過訪問HR部門和在利潤專家填寫的模板基礎上進行一些修改。他們經常不確定一些選項，而且擔心做錯什么會破壞他們的信用。他們需要：
- 好的指令，以替代個人訪問（幫助，體現易學）
- 確認不僅他們的數據更新，而且和這些變更的相關利益（容錯）
- 確保整個過程中和在他們的入口中是精確的（吸引人的和有效的）。
這個公司有一個呼叫中心，利潤專家可以在此處支持有困難的雇員。他們也完成一些雇員自己完成不了的一些過程。他們在業務中心每天工作，經常重復回答同樣的問題，而且大多數呼叫都使用同一個界面。他們需要：
- 快速完成日常工作（效率）
- 在一個簡單界面中看到雇員，這樣可以集中在會話中，而不是界面（吸引人的/效率）
- 在完成之前，可以確認和雇員相關的所有變更（有效性）
從用戶中獲得用戶的知識
有很多技術用於獲得用戶的知識，不同的方法可以發現用戶體驗的不同方面。如果關注效率，將使用一個技術可以使我們看到真實的人們在實際的環境中完成實際任務；對於容錯，可以使用關鍵事件的日志與報告或記錄的實際錯誤相比較。使用可用性的不同方面作為選擇研究技術的一個工具，可以幫助獲得了問題的答案，有助於做出好的設計選擇。
當用戶研究和分析完成時，有一個機會讓我們來比較最初的觀點和用戶的新理解。這是一個更新藍圖和修正不正確假設的機會。
可用性文獻充滿了由於用戶形象變化從而導致產品革新的例子。例如，我曾經工作在一個關於雇員管理程序的小業務。當開始設計時，客戶告知我們典型用戶會與很多不同的程序工作，對微軟辦公軟件很熟悉，定期使用email，而且喜歡學習使用程序以改進他們的業務。產品開發團隊建議用戶最關注的可用性需求是效率，這樣他們可以更快地處理他們的業務；有效性或精確性，可以作為第二重要的需求。
當開始和用戶工作時，很快就會發現，這個描述是多么的不准確。這些典型用戶只與一個或兩個程序工作，經常使用行業內的專業軟件。很少使用通用辦公軟件，而且工作中不用email。最重要的是，他們只感興趣獲取足夠的學習內容；他們想完成他們的工資帳目，不想改變他們業務的方式。在這個項目中，我們開始做用戶研究，關注速度和精確性，並試圖了解用戶如何完成創建工資帳目的特定任務，但我們發現這是個錯誤的方法。反而，我們更改我們的技術，關注易學性和容錯。我們想知道在工資帳目中，需要培訓軟件中的哪些內容，哪些困難會經常導致錯誤。
創建可用性目標和需求
5E中的每一個都可以作為可用性目標的依據。一個用戶的表述如“我怎么知道每個人是否會收到他們支票的正確利息”，可以引出一個需求：用戶應該能看到，並在最后階段之前確認所有的選擇。對一個有許多不常用任務的程序可以確定一個可用性目標：對於一個（典型、培訓過的）用戶可以在沒有額外培訓或使用幫助手冊的情況下完成指定的任務。
無論這個表述可以變成一個功能需求還是一個可用性目標，將它們和可用性維度聯系起來，使最初會話的表述和從中產生的共享願景聯系起來。例如，一個經理可以關注高效地完成工作，關注一個任務的時間；同時，工人卻把它看作是一個容錯問題，以及他們工作時業務支持的程度。
形成一個設計方法
僅僅關注可用性的錯誤方面是不正確的。因此，設計方法應當適應於可用性需求。例如，用戶需要快捷鍵來一次處理一個以上的數據記錄嗎？或不經常使用產品的用戶需要內置的幫助來提醒他們如何使用產品嗎？5E提示了一些可能的設計需求（見表2）
表2：5E和可能的設計方法
維度
用戶需求
可能的設計方法
有效性
精確性
- 提供所有關鍵活動的反饋
- 消除錯誤機會
- 為用戶決策提供充足的信息
效率
操作速度
- 為理想的工作流設計導航，也同時兼容替代方案
- 提供快捷鍵
- 通過交互風格和設計圖標提升速度
- 將界面中的無關元素最小化
吸引
被吸引住
- 使用清晰的語言和適當的術語
- 通過適合用戶的會話水平設定一個幫助聲音
- 功能結構化以匹配用戶任務
容錯
有效和確認
- 將錯誤轉化成替代路徑
- 使用控件有助於准確選擇
- 確信活動容易回溯
易學
及時的信息
- 通過最少的快捷鍵和說明使界面有幫助
- 針對困難或不常用任務創建引導界面
可用性測試計划
需要什么樣的可用性評估以確信設計符合可用性目標？需要什么樣的原型以獲得有用的結果？與用戶研究相同，答案在於我們所感興趣的維度（見表3）。例如，一個業務需要支持非常高效的操作，很可能需要在一些初始的培訓和一套與實際任務相吻合典型工作條件下用一個高保真原型或程序的早期版本進行測試。為了測試產品在復雜任務中的吸引程度，與早期概念原型一起工作會幫助聚焦在整個過程，而不是特定的細節。
表3：5E和可能的評估技術
維度
可能的評估技術
有效性
- 針對困難或模糊的任務創建場景
- 評估任務的成功完成的程度和產生沒有測量到的錯誤頻率
效率
- 創建一個實際的工作任務，重復地進行測試
- 使用工作軟件或高保真原型
- 在用戶工作時進行觀察，發現那些打斷或減緩用戶操作的情形
- 收集計時數據，但同樣掌握用戶的主觀印象
吸引
- 使用滿意度訪談問題或調查作為評估的一部分
- 對視覺設計做偏好的測試
- 測試使參加用戶能在他們想放棄時放棄一個任務
容錯
- 創建容易犯錯誤的場景
- 觀察用戶能夠從所發生問題中恢復過來的容易程度或精確度
易學
- 收集測試用戶的實現步驟，或招募不同經驗或知識的參加用戶
- 摻入不常用的任務和功能
在計划中引入可用性
對可用性或以用戶為中心設計的最大異議是實踐問題。如何將所有的額外工作融入已經安排得很緊、有時間點約束的計划？讓我們將這個問題變換一個角度，問一個不同的問題：可用性如何幫助那些困擾軟件開發過程的問題？
不僅僅是開發軟件過程難以避免。實際上，當你問開發人員他們工作中最恨什么？他們將告訴你：
- 需求發生了變化、變化和變化
- 客戶不能理解軟件能做的和不能做的
- 構建某物，結果被告知它不是用戶（或市場）想要的。
有趣的是，試驗報告中已經包含以下數字：34%的項目在完成之前被取消，50%是僅僅部分實現了最初設想，只有16%成功。而且在項目的最初階段就失敗存在以下失敗原因：
- 缺乏用戶輸入（12. 8%）
- 不完整的需求和規格（12. 3%）
- 變更需求和規格（11. 8%）
從這些發現可以看到，沒有提前做用戶研究導致了缺陷和不可管理的項目。
令人感興趣地，這些是可用性專家和用戶界面設計者抱怨的主要問題：
- 軟件不能考慮用戶的實際工作、任務和環境
- 太多重點放在技術需求，而沒有充分平衡用戶需求
- 在他們有了任何實際影響的很久以后，設計和可用性才被加入到產品
總之，需要針對功能和用戶需求的共同語言，和整個開發過程中可用性評估反饋到實際工作中。沒有這個共同的基礎，就不能准確描述產品，也無法在創建產品之后時認可它。
結論
如果想創建一個能用和有用的產品，必須將用戶的知識和理解融入到概念和架構中。引用一個喜歡的可用性諺語：“可用性不是某些東西如花生油一樣可以在項目最后抹在上面”。在今天軟件開發的混亂世界中，很容易拒絕新思想；減少了對開發過程的控制，增加了復雜性。無論如何，如果集成得很好，以用戶為中心的設計不僅能幫助創建更好的產品，而且可以減少勞動和重復。當產品設計和理解用戶需求結合，有更多的機會來滿足需求。
參考
1. ISO/IEC 9241-11 Ergonomic Requirementis for Office Work with Visual Display Terminals（VDT） – Part II Guidanc on Usability. 1998：ISO/IEC 9241-11： 1998（E）
2. Lidwell, W.,K. Holden, and J. Butler. Universal Principles of Design. Rockport Publishers, 2003
3. Nielsen, J. Usability Engineering. Academic Press, 1993
4. Standish Group. The CHAOS Report. Standish Group International, 1994
（www.standishgroup.com/sample_research/chaos_1994_1.php）
作者簡介
Whitney Quesenbery是一位用戶界面設計師、設計過程顧問和可用性專家。
她致力於發展產品設計中的新概念，並且開發了喝多獲獎的多媒體產品，網站，以及網絡和軟件應用產品。
Whitney領導着自己的設計咨詢公司Whitney Interactive Design，是公司的首席顧問。可以從網站www.wqusability.com了解更多信息
參考：