可用性的維度（5E）

可用性的維度

當我檢查可用性文獻時，我發現可用軟件包含如用戶友好、易學、可發現性、質量、有用的和阻止錯誤。在可用性工程中， 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瞭解更多信息

 

 

 

 

 

 

 

 

參考：

http://www.everyinch.net/index.php/whitney_quesenbery_5e/