軟件設計中的易用性摘要:這篇文章介紹了軟件設計中“易用性”的概念并解釋了為什么它在軟件設計項目中應該是一個重要的部分.介紹應用“易用性"到軟件開發中?“易用性Ｕｓ(又被譯為可用性）”這個詞在軟件開發中表現為這樣一種方式，即把用戶而非系統臵于開發過程的中心。這種被稱為“以用戶為中心進行設計”的概念,是指從設計過程的開端便把用戶所關注的東西包含于其中,并規定用戶應該是任何設計決定中最重要的因素.?種“以用戶為中心進行設計"的方式最顯著的方面便是易用性測試。在易用性測試中，用戶對產品界面進行交互式的測試，并與開發、設計人員交流他們的觀點和所關注的問題.篇文章討論了“易用性”的概念及為什么它應該是軟件設計項目中重要的組成部分。第一部分解釋了在軟件開發中“易用性”意味著什么，它跟產品價值的其他衡量標準如何相關.第二部分闡明了“易用性”的重要性及怎樣把“以用戶為中心進行設計"的原則包含于開發過程中等常見問題.這篇文章的末尾提供了一份有關的書籍、文章、組織名單，這份名單可以幫助你更多地了解易用性及如何把之應用于你的項目。?這篇文章中的大部分原則都適用于零售軟件（ｒetailｓoftｗarｅ）的開發和內部應用軟件（ｉｎｔeｒｔwaｒｅ)的開發。
當你深入閱讀時,請注意象“用戶”和“產品”這樣的詞軟件易用性描述，思考它們和你自己的項目之間的關系，思考那些產品最終用戶的需求。?定義易用性?容易使用?“功能性（utiｌiｔy）”、“喜歡（ｌｉkeaｂｉｌｉｔｙ)"這些相關的概念是軟件設計中易用性不一樣的.?易用性Vs功能性（ｉtyｖs。Utｉｌity）?定一個產品能否被用戶接納的關鍵是它是否有用,即實際使用它能否完成設計人員原本期望用戶去完成的目標.“有用(ｅｓs）"這個概念可以進一步分為“易用性（)"和“功能性(utｉlitｙ)”.盡管這兩個詞是相關的,但它們卻是不可以相互替換的。?功能性是指產品完成任務的能力.產品被設計為能完成更多的任務，那么產品的功能性就越強。?我們看看80年代末微軟的ＭS_ＤOS版文字處理程序,該程序提供了很多很強的文字編輯功能，但是要求用戶必須學習并記住很多神秘的按鍵才能完成任務。象這樣的程序可以說具有很高的功能性(它們提供給用戶很多必要的功能）但易用性很低（用戶必須花大量時間和精力去學習、使用它們）.與此形成對照的是，一個設計得很好、簡單的應用程序，比如計算器程序，很容易使用，但卻沒有提供多少功能.這兩種特性對于產品被市場接納都是必要的。
二者都是產品“有用”這個整體概念的組成部分。明顯地，如果一個程序非常容易使用但卻沒有什么功能，沒有人會有理由去使用它。而如果給用戶一個功能非常強大的程序，但卻很難使用，那么用戶將很可能會抵制它或者尋求其他替代物。?易用性測試幫助你確定用戶能否容易地執行特定的任務。但是，它并不能直接幫助你確定產品本身是否有價值或有功能。（用戶在易用性測試中也許會主動提供跟功能性有關的評論,但是任何這樣的評論應該通過別的、更加可靠的研究方法來驗證)。喜歡它Vs使用它（LikｉｎgＩtvs.ＵsingＩｔ)?在一個產品中“受人喜歡”總是一個令人想要的特性。如果人們喜歡這個產品，他們更可能會去使用它并推薦給他人。但是你應該小心，不要把“受人喜歡"和“易用性”混淆。?人們經常會因為一些跟產品的易用性和功能性無關的理由而喜歡一個產品。他們常常因產軟件設計中易用性品的式樣外觀或相信產品能賦予他們某種身份而被吸引。人們傾向于喜歡易于使用的產品,但你并不應該因此斷定一個受人喜歡的產品是易用的。?易用性是關于用戶能否使用產品來完成他們需要完成的任務.易用性測試主要衡量產品的性能，而非用戶對它的偏愛.但是，可以用標準化的問卷調查測定用戶對產品之間的偏愛.發現Vs弄懂Vｓ效率易用性有很多方面,但傳統上這個詞特別是指“發現”、“弄懂”、“效率”等特征。
“發現（ｙ）”涉及用戶根據需求去查找產品的某項功能(fｅatuｒe)。易用性測試可以測定用戶找到某項功能需要花多長時間及用戶在查找過程中會犯多少錯誤（找錯位臵)。?“弄懂（）”涉及這樣一個過程,即用戶通過這個過程弄懂怎樣去使用某項已發現的功能特點去完成手頭上的任務。易用性測試可以測定這個過程需要多長時間及用戶學會這個特點會犯多少錯誤。“效率（Ｅfｆｉciｅncy)”涉及一個時候，在此刻用戶已經“精通”產品的功能并且不再需要進一步學習便可以使用它。易用性測試可以確定有經驗的用戶去使用某項功能特點所執行必須的步驟需要多長時間。手頭上任務的性質和用戶執行任務的頻率強烈影響易用性的這三個基本方面。有些功能很少被使用或者太復雜以至于用戶本質上必須每次都重新學習它，對于這些功能，微軟經常通過向導（ｗiｚard）方式來引導用戶。?口號不起作用?件設計人員有時會認為象“讓產品更易用“這樣的簡單口號將幫助解決易用性問題.面對易用性的積極態度是重要的,但只有讓普通用戶對產品進行適當的易用軟件設計中易用性試,才能提供給設計人員要創造出一個能滿足用戶需要的產品所需的有關信息.“讓產品更易用”應該是每一個軟件設計人員的座右銘,但是只有當設計人員明白"易用性“的含義這句話才有意義。
對普通用戶進行測試是確定易用性最可靠的方式。?經常被問到的問題（FAＱ）?為什么我應該關心？果你還沒有把對易用性的考慮包含進你的產品設計過程中,你也許想知道為什么它是必須的或值得要的.歸根結底，根本不進行任何易用性測試工作就可以發布一個可以運行的、沒有錯誤的產品肯定是可能的，但是把“以用戶為中心"的設計原則包含到設計過程中，會制造出一個在很多方面都被改進的產品。進行易用性測試的最佳理由是減少用戶尋求技術支持服務電話的數量。糟糕的易用性是用戶打軟件技術支持服務熱線的主要原因,每一家軟件公司的信息服務經理知道產品支持是多么地昂貴。再者，向用戶收取支持服務費用將增加用戶對產品潛在的不滿意。如果用戶覺得很容易使用你們的產品，他們將不需要經常撥大技術支持服務電對于為內部使用開發的軟件，把易用性作為開發過程中的重要部分的另一個最好理由是可以減少培訓費用。一個很易用的產品比一個不重視易用性的產品讓用戶更加容易學習。用戶能更快地學會功能特點,能更長時間地記得他們所學會的，這跟減少培訓費用和培訓時間直接相關。用性測試幫助提高用戶對產品的認可程度。用戶的認同源自于多種因素，包括“易用性"、“功能性"、“喜歡”。
對于零售產品，用戶的認可經常與重復購誠度直接相關,這意味著用戶很可能向其他人推薦產品.對于內部使用的程序，用戶的認可關系到用戶是否愿意使用該軟件，去完成能幫助提高生產率的任務。增強的易用性是能提高用戶認可度的因素之一。?易用性能幫助把你的產品和競爭者的產品區分開來.如果兩個產品在功能方面幾乎是一樣的,更易用的軟件設計中易用性產品將可能被認為是更好的。另外，微軟的Wｉnｄoｗｓ風格外觀和相應的 編程規范造就了一致的基本用戶界面，所以提供相似功能的很多程序看上去和用 起來都很類 似。這些相似性意味著,易用性方面的的細小差異可以對用戶的偏 愛有很大的影響。 最后，請記住：每個產品最終都會得到易用性測試。用戶每次使用你的產品就是 在進行易用性測試,用戶通過不斷地使用或很少使用產品的行動來給予他們的 “裁決”。在產品發布到市場之前測試產品，你可以確保用戶對產品的體驗將是 正面的。 它花費多少？? 軟件設計人員和項目經理經常擔憂啟動以用戶為中心的設計過 程及進行適當的易用性測試將需要無法接受的的時間和金錢。事實上，聚焦于用 戶所花費的時間和金錢常常是相對較小的，而且與不聚焦于用戶所導致的花費相 比肯定是較小的。
如，考慮一下在開發周期的后期對設計進行修改所花費的時間和金錢,與早期進行修改所需的花費（那個時候產品還在繪圖板上)之間的對比.如果你等到beta 時期才把產品交給用戶進行易用性測試，你也許會發現自己忙于把已經花了很多 時間所開發的程序分解為多個部分.如果你等到產品實際發布之后,然后根據負面 的反饋才去變更或向糟糕的設計提供技術支持，會因為很高的產品技術支持費用或用戶的不滿,使得代價非常高.? 一項合理的易用性研究通常可以在兩個星 期左右內完成,可大大地減少隨后在開發周期中變更所導致的費用.進行測試所涉 及的費用隨產品的性質和欲進行測試的界面多少而異。? 可以把易用性測試與代碼測試認為是類似的。成功的項目經理在計劃一個開發項目時會覺得代碼測 試是合理的開銷，他們不會把它看做是附加在項目日程計劃和預算 上的額外東 軟件設計中易用性 西。項目經理更愿意接受代碼測試，把之作為正常的開支之一，因為其他替代方 式會將昂貴得多。同樣地這也適用于易用性測試。? 我怎么去得到一些易用性？ 閱讀和理解“易用性”的重要性的時候,軟件設計人員有時也被誘惑去“獲得一些"易用性，似乎它是一種可以簡單地添加，使得一個產品更易用的成份.恰 反，易用性應該是設計過程本身的一部分,而不是一種你可以隨意添加到過程中的某種東西。
易用性專家提到要“聚焦于用戶”及“以用戶為中心進行設 計”的理由 是，易用性取決于把用戶的需要保持作為設計過程的中心.? 戶為中心進行設計必然地涉及到更多的東西,不僅僅只是遵循一套規定在界面上按鈕、菜單如何擺放的規則.易用性測試是一個可以檢查你的設計工作的機會， 它不是一種把易用性“添加”于你的產品中的途徑。? Ｇouｌｄ，Boieｓ， Leｗis(19９1）確定了“以用戶為中心進行設計"的四個重要原則:? 盡早聚焦于客戶的需求.設計人員在設計過程的早期就應該專注于理解用戶的需要。 完整綜合的設計。設計的各個方面應該平行地進展，而非順序地進行。 較早地并持續不斷地測試。軟件設計中目前唯一可行的途徑是經驗主義式的：只有實際用戶認為設計好那么 這個設計才是好的。把易用性測試貫穿于整個開發過程,可以讓用戶在產品發布 之前對設計給予一個反饋的機會 反反復復的設計。大問題經常掩蓋小問題.設計人員和開發人員應該通過多輪 測試反復修正設計。? 為什么我們應該讓用戶參與其中？ 計人員應該明白他們他們并不是典型用戶.他們比一般的普通用戶對他們正在開發的軟件熟悉得多。對大多數用戶而言不清楚或令人糊涂的界面,對一直在 開發這個 項目的人員而言卻是非常清晰的.有些軟件設計人員在某種程度上能 軟件設計中易用性 理解一般用戶的感受,但是并沒有什么可以替代物可以代替實際用戶對產品的真 實交互反應。
? 因此，通過盡早聚焦于典型用戶的需要并經常根據用戶測試修正 設計，軟件設計人員能創造出更好的設計，作為結果，那就是更好的產品. 好的設計會得到來自用戶更好的認可。對于零售軟件,增加的購買所帶來的好處是明顯的:銷量增加了。對于為內部使用所開發的軟件,來自用戶的認可也是重 的：增加的使用會導致生產率的提高和對技術支持需求的減少。從開發過程的開始就明顯地讓用戶參與其中也向他們表明你對他們的關心和需要是關注的, 也因此會 增加他們去幫助你們開發更好軟件的意愿。 為什么我不能僅僅遵循指南？ 微軟已經開發出一套winｄｏws 平臺的界面指導規范以確保windｏws 程序具有 一致性的外觀.其他公司也開 發出針對其他平臺的類似指南.象Jakob Niｅlsｅn 這樣的易用性專家已經寫了很多關于設計易用的網頁方面的文章。有關于這些主 題的大量信息可以獲 得，有時設計人員相信嚴格地遵循這些指南和標準便是制 造出易用的產品所需的全部。? 關于這種方式存在問題在于指南在本質上就是概 括性的.指南必須適 用于各種情況,因此并不總是能為你正在設計的特定程序提 供了最佳的行動指南。遵循一個寫得很好的指南可以幫助你設計出一個一致性的 界面，但你不能肯定它就 是易用的，除非你讓真正的用戶對其進行測試。
當你 使用指南的時候,不要象使用食譜那樣去使用它們，不要期待一個指南為你指出 可以獲得全部最佳結果的道路。 兩個設計人員可以兩種不同的方式實施同一指 南，而且兩種實施也許都不適合于情況。而且，有時候嚴格遵循指南會導致一個 糟糕的結果，或者導致指南間的沖突。? 在這些問題真正成為問題之前，只有以 用戶為中心的設計才能幫助解決這些問題。? 讓我們以另外一種方式來考慮這個 軟件設計中易用性 問題吧:讓“以用戶為中心的設計"，而非用戶界面指南，成為設計決定的仲裁者. 我需要建造一個易用性實驗室嗎？? 要斷定易用性測試就意味著一個必需具有一個昂貴的實驗室,在其中天花板上架設有攝像機、有one—ｗay mirｒoｒ（譯 注：一種可以透視的鏡子,在鏡 子的一測，看上去跟正常的鏡子一樣,但在另一測 卻可以看穿鏡子的另一面)及其他注意力監控設施等。可以肯定的是,那些需要做 很多測試的公司將會發現建造一 個專門的實驗室會很方便.易用性測試咨詢商 經常有很多設施和設備提供給他們的顧客,但你可以在各種條件和情況下進行有 用的、有效的測試。? 一種方式是只需簡單地找一個精通于人機對話研究和收集 數據的測試人員坐在用戶后面軟件易用性描述，觀看用戶怎樣操作任務。
這種測試可以在會議室 或辦公室里很容易地進行。Dumas 和(1999)提供了大量的關于怎樣通過觀 察進行測試方面的信息。 當你越來越多地涉及到易用性測試的時候,你可以添加諸如攝像機、one-ｗay 或能讓你實時觀看和記錄用戶的顯示器這樣的設備。你不必一次性就添加好所有設備，即使一件件地添臵設備也可以幫助你從易用性測試中獲取很多價值. 另外一種替代方式是,你可以把你的易用性測試外包給易用性測試咨詢人員。請 看下面的“我怎樣開始"了解關于尋找合適的咨詢人員的技巧。? 我怎樣開始？ 一旦你決定把“以用戶為中心”的設計原則包含于你的開發過程中,你將需要決定是否需要雇傭易用性測試專家或把易用性測試外包給服務供應商。? 易用性 專家協會（Uｓａbｉlity ｓiｏnａｌs ｔｉｏn，UPA）提供了一個服 務供應商指南，能幫助你找到易用性測試咨詢專家為你進行易用性測試。 一些咨詢團體也能幫你建立你自己的易用性實驗室或開發一個內部使用的易用 性程序,以便把易用性原則包含于你的設計過程中。? 果你愿意雇傭易用性軟件設計中易用性 方面的專家,人機工程協會(Humａn Facｔors ErgonｏmicsＳociｅty)提供了能 幫助你找到潛在雇員 的服務.很多易用性方面的專家也隸屬于AＣM Sｐｅｃｉ al Inｔerest Grouｐ -Human Inｔｏn (ＳIGCＨI)和UPA，你可以 在他們的出版物上或會議上放臵招聘廣告. 無論你選擇采取那種方式，記住你是在雇傭易用性測試服務，易用性測試專家跟 那些進入軟件界面并告訴你什么有問題的普通用戶是不一樣的.設計人員不是典 型用戶的原則同樣適用于易用性測試專家。 請看下面的“資源”，以了解這些組織的信息及更多關于易用性測試和以用戶為 中心進行設計方面的信息。 資源（Ｒｅsourｃes）? 文章和書籍 作者：微軟公司MｉcrｏｓoｆtCoｒｐｏrａtiｏn 譯：Dozer ２003—8-15 １９：０2：10