軟體設計中的可用性 (轉)
設計中的可用性
在工作中體現可用性
在建立軟體的環境中,術語“可用性”表示一種方法,它將而不是擺在過程的中心。這一方法稱作以使用者為中心的設計,它從設計過程的一開始就將使用者關心的問題和意見考慮在內,並提出在任何設計決策中使用者的需要都應擺在首位。
這種方法最顯著的特點就是可用性測試。在測試中,使用者使用產品的介面進行工作,透過介面進行互動,就他們的觀點和關心的問題與設計人員和開發人員進行交流。
本文討論了可用性的概念,並討論了為什麼可用性在所有軟體設計專案中都是一個重要部分。本文的第一部分定義了在環境中可用性意味著什麼,以及它與衡量產品價值的其它方面間的關聯。第二部分回答了一些常見的問題,包括:為什麼可用性很重要,以及如何在開發過程中體現以使用者為中心的設計理念等。本文在結尾處列出了一些書籍、論文和組織機構名稱,幫助您加深對可用性的瞭解,並在專案中應用可用性。
本文中討論的大部分概念在零售和內部軟體開發中均有所應用。在閱讀本文時,請注意“使用者”和“產品”等詞語,並思考如何將其應用到您的專案和終端使用者中。
可用性定義
易於使用
可用性是衡量使用一種產品來指定任務的難易程度的尺度,它與實用性和受歡迎度等相關概念是有差異的。
可用性與實用性
決定產品可接受性的核心屬性是其有用性,它用於評價實際使用產品時,是否能達到設計人員期望產品實現的目標。有用性的概念可以進一步劃分為實用性和可用性。雖然這些術語間有聯絡,但它們卻不能相互替代。
實用性指產品執行任務的能力。根據設計,產品執行的任務越多,其實用性就越高。
讓我們以二十世紀八十年代末問世的典型 ® MS-DOS® 字處理為例。此類程式提供了多種強大的文字編輯和處理功能,但需要使用者學習和記憶幾十個令人費解的按鍵後才能執行這些功能。可以說此類應用程式具有很高的實用性(它們為使用者提供了必要的功能),但其可用性卻較差(使用者必須花費大量的時間和精力來學習和使用它們)。與之形成對比的是,一個設計合理的簡單的應用程式(如計算器)使用起來很容易,但其實用性卻有欠缺。
這兩種性質都是一種產品被市場接受所必需的,而且它們都是總的有用性概念的一部分。顯然,若程式很好用但沒有什麼有價值的功能,那麼沒有人會使用它;如果程式的功能強大但卻很難使用,那麼使用者也很可能會拒絕這個程式而轉向其它的替代品。
可用性測試幫助您判斷使用者使用產品執行特殊任務的難易程度。但是,它並不能直接幫助您判斷產品自身是否有價值、是否實用(在可用性測試中,使用者可能會主動提出一些關於實用性的意見,但任何意見都應透過其它更可靠的研究方法予以驗證)。
喜歡它與使用它
受歡迎度往往表示產品中可取的特性。如果人們喜歡某產品,就更有可能使用它,並將它推薦給其他人。但是,與實用性一樣,您一定要小心不要將受歡迎度和可用性混淆。
人們喜歡某產品的原因往往與實用性和可用性無關。他們可能被產品的樣式和引人注目的外觀吸引,或被心目中所賜予的該產品的地位吸引。人們傾向於喜歡很好用的產品,但這並不是說人們普遍喜愛的產品就是可用的。
可用性是指人們是否可以使用該產品來執行他們需要執行的任務。可用性測試主要用於評價而不是評價喜愛程度,但標準化的調查問卷也可以用來衡量人們對產品的喜愛程度。
發現、學習與有效性
可用性包含很多方面,但通常這一術語特指發現、學習和有效性這三種屬性。
發現表示針對某種特定的需要去尋找並找到產品的某一功能。可用性測試可用於確定使用者找到某一功能所用的時間,以及在整個過程中使用者犯了多少錯誤(關於定位的錯誤選擇)。
學習表示使用者弄清楚如何運用所發現的功能來完成現有任務的過程。可用性測試可以確定這個過程的長短,以及在學習該功能期間使用者犯了多少錯誤。
有效性表示使用者“掌握”了某項功能,不再需要進一步學習即可使用。可用性測試可以確定有的使用者使用該功能時執行必要步驟所需的時間。
可用性的這三個基本方面在很大程度上受到當前任務性質和使用者執行任務的頻率的影響。有些功能的使用頻率很低或者使用起來十分複雜,導致使用者基本上每次使用時都要重新學習;對於這些功能,Microsoft 通常開發了使用嚮導,在整個使用過程中對使用者予以指導。
光喊口號是不夠的
軟體設計人員有時以為簡單的口號,如“使產品更可用”,就可以解決可用性問題。雖然對可用性的積極態度是重要的,但是隻有在具體的產品建立環境中,透過對普通使用者進行恰當的可用性測試,才能為設計人員提供所需的資訊,使產品可以滿足使用者的需要。“使產品更可用”應當成為每個軟體設計人員的座右銘,但是這句話只對那些瞭解“可用性”含義的設計人員才有意義。而對普通使用者進行測試就是可以找到的最可靠的途徑。
常見問題
為什麼要強調可用性問題呢?
如果您還沒有在產品設計過程中將可用性因素考慮在內,您可能會問:可用性為什麼是必要的,或可用性為什麼是可取的?畢竟,不進行任何可用性工作,也可能發售一個可以工作的、沒有錯誤的產品。但是,透過引入以使用者為中心的設計理念可以使產品在很多方面得以很大改進。
減少使用者撥打技術支援電話的次數是執行可用性測試的最佳理由。較差的可用性是使用者撥打軟體技術支援熱線的主因,而每個軟體公司主管以及資訊服務經理都知道產品支援的成本是多麼昂貴。此外,使用者不得不尋求技術支援增加了使用者對產品的潛在不滿情緒。如果使用者發現貴公司的產品使用起來十分容易,那麼他們就不必頻繁地打電話尋求技術支援了。
對於內部使用的軟體,之所以將可用性作為開發過程中的一個重要部分,其原因還在於它減少了培訓費用。對使用者而言,可用性強的軟體學習起來比可用性不受重視的產品學習起來要容易得多。使用者能夠更快地瞭解產品的各項功能,並能長久地掌握它,這直接減少了培訓費用和時間。
可用性測試有助於促進使用者對產品的接受程度。有很多因素決定了使用者對產品的接受程度,這些因素包括可用性、實用性和受歡迎度。對於零售產品,使用者的接受程度往往直接影響對產品的重複購買或對產品的忠誠度,這說明使用者可能將產品推薦給其他人。對於內部應用程式,使用者的接受程度決定使用者是否願意使用該軟體執行任務,而這些軟體就是針對這些任務設計的,這有助於提高生產。提高可用性是提高使用者對產品的接受程度的一個因素。
可用性可將您的產品與您的競爭對手的產品區分開來。如果兩個產品在實用性方面從本質上講是一樣的,那麼人們很可能認為可用性更好的產品高出一籌。此外,由於 Microsoft® ® 的外觀和感受以及隨附的準則劃定了基本使用者介面的使用區域的標準,因此很多執行相似功能的程式其外觀與操作在相當大的程度上是相似的。這些相似性表明,即使可用性上的細微差異也會對使用者的喜好產生重大的影響。
最後請記住,每個產品最終都要進行可用性測試。使用者每次使用您的產品時,都是在對它進行可用性測試,而他們對可用性優劣的意見將會影響他們是否繼續使用該產品。將產品推向市場之前,對產品進行測試,可以有助於確保使用者對產品的滿意程度。
它的花費是多少?
軟體設計人員和專案經理往往擔心,如果採用以使用者為中心的設計過程並執行適當的可用性測試,恐怕要佔用大量的時間並花費大量的金錢。事實上,花費在關注使用者方面的時間和金錢通常是相當少的,而且與不這樣做而導致的花費相比,這點花費也是微不足道的。
例如,設想一下在開發週期的後期而不是在前期(產品仍處在開發階段時)對設計進行修正您要花費多少時間和金錢吧!如果您一直等到 Beta 測試時期才使使用者接觸到產品以便進行可用性測試,就會發現自己不得不將花費了大量時間開發的程式的各部分分拆重做。而若等到產品真正釋出時,如果要根據負面反饋進行修改或支援較差的設計,因為產品支援的龐大開銷或使用者對產品的接受程度較差等原因,很可能要支付高昂的費用。
合理的可用性研究通常只需要兩週或更短的時間,並可以顯著減少開發週期後期進行修改所需的時間和金錢。進行測試所需的花費將根據您的產品的性質以及所測試的介面部分的不同而有所不同。
可以認為可用性測試與程式碼測試是類似的。成功的專案經理在計劃開發專案時總是會考慮到程式碼測試。他們並不認為程式碼測試是專案時間表或預算外的額外部分,而是將程式碼測試作為開發過程的一部分而計入成本。因為若不進行程式碼測試,那麼花費反而會高得多。對於可用性測試,情況也是如此。
怎樣獲得可用性?
在理解可用性的重要性基礎上,軟體設計人員有時試圖“獲得”一些可用性,就好象可用性是一種成分,他們可以簡單地把它新增到產品中,這樣產品就更可用了。然而,可用性應當是設計過程本身的一部分,不是您可以在設計過程的隨便某一地方新增的“東西”。可用性專家提到“使用者關注的”與“以使用者為中心的設計”的原因是:可用性取決於將使用者的需要一直作為設計過程的中心。以使用者為中心的設計根據需要的不同,包含的內容不單單是在介面中按照一組規則,對按鈕和選單佈置進行管理。可用性測試是對設計工作進行檢查的良機,而不是在產品中“新增”可用性的一種方法。
Gould、Boies 和 Lewis (1991) 為以使用者為中心的設計定義了 4 個重要的原則:
及早以使用者為中心:設計人員應當在設計過程的早期就致力於瞭解使用者的需要。
綜合設計:設計的所有方面應當齊頭並進的發展,而不是順次發展。使產品的內部設計與使用者介面的需要始終保持一致。
及早並持續性地進行測試:當前對軟體測試的唯一可行的方法是根據經驗總結出的方法,即若實際使用者認為設計是可行的,它就是可行的。透過在開發的全過程引入可用性測試,可以使使用者有機會在產品推出之前就設計提供反饋意見。
反覆式設計:大問題往往會掩蓋小問題的存在。設計人員和開發人員應當在整個測試過程中反覆對設計進行修改。
為什麼應當將使用者融入進來?
設計人員應當認識到他們自己不是普通的使用者。與一般的使用者相比,他們對正在開發的系統有著更深入的瞭解。因此,對大多數使用者而言不明確或造成混淆的介面,可能對那些從事專案設計工作的人員來說是非常清晰的。某些軟體設計人員可以在一定程度上代表普通使用者,但他們絕對不能代替實際使用產品的真正使用者。
因此,透過在早期關注普通使用者的需要,並根據使用者測試結果經常改進設計,以使用者為中心的軟體設計人員會提出更好的設計,並生產出更好的產品。
更好的設計將得到使用者更好的認可。零售軟體增加買進點的利益是很明顯的:這增加了銷售額。對於為內部使用而開發的軟體,認可也是十分重要的:買進點增加將導致生產效率增加,並減少了對技術支援的需求。顯然,從開發的一開始就將使用者融入進來,並向使用者表明您看重他們所關心的問題和需求,這將使使用者更願意協助您開發出更好的軟體。
遵循這些準則就足夠了嗎?
Microsoft 為 Windows 計算平臺開發了一系列介面準則,以此確保 Windows 程式具有一致的外觀和感受。其它公司為非 Windows 計算平臺開發了類似的準則,並且象 Jakob Nielsen 這樣的專家撰寫了大量關於設計可用 頁的文章。透過關於這些主題的大量資訊,設計人員有時認為生產可用產品所需的全部工作就是嚴格遵守準則和規範。
這種想法的錯誤之處在於:準則在本質上是通用的。準則必須應用到各種各樣不同的情況之中,因此它不能總是針對您正在設計的特定的應用程式制訂最佳的行動方案。遵守一組合理編寫的準則有助於您設計出風格一致的介面,但是您不能保證它是可用的,除非透過真正的使用者對它進行了測試。當您的確要使用準則時,不要象使用詳盡的說明書一樣,希望根據準則執行的方法所生成的所有結果都是最好的。兩個設計人員可以用兩種不同的方法實施同一個準則,而兩種實施方案對特定情況卻不一定同等適用。而且,有時候嚴格遵守準則可能導致很差的結果,或在準則之間發生衝突。只有採用以使用者為中心的設計,才可以在問題產生前排除它們。
對這個問題的另一種理解方式是:應當使以使用者為中心的設計理念成為設計決策的決定因素,而不是以使用者介面準則為決定因素。
是否需要建立可用性實驗室?
不要以為可用性測試就意味著建立昂貴的實驗室,在天花板上攝像機,安裝單向鏡,以及採用其它以小組為中心的設陷技術。的確,進行大量測試的公司通常認為建立專用的實驗室十分方便,並且可用性顧問往往可以為客戶提供各種各樣的設施和裝置,但您也可以在各種各樣的設定和環境中執行有用、有效的可用性測試。
一種方法只需要一個測試人員(該測試人員對有人參與的研究工作與資料收集十分精通),在使用者工作時坐在使用者後面觀察使用者如何執行任務,這在會議室或辦公室裡就可以輕而易舉地辦到。Dumas 和 Redish (1999) 提供了大量關於使用觀察法進行測試的資訊。
隨著可用性測試的進一步進行,您可以新增諸如攝像機、單向鏡等裝置,或其它幫助實時觀察和記錄使用者顯示器的工具。不必一下子新增所有的裝置,即使一件一件地新增,也可以使您從可用性測試中獲得更多有價值的東西。
另一種方法是,您可以將測試外包給可用性顧問。關於為您尋找合適顧問的幾點提示資訊,請參見下文的“我如何開始?”。
我如何開始?
一旦您決定將以使用者為中心的設計原理運用到您的開發過程中,就需要決定是自己僱傭可用性專業人員還是將可用性測試外包給供應商。
可用性專業人員協會 (UPA) 有一份供應商指南,有助於找到為您執行測試的可用性顧問。
有些諮詢部門還可以幫助您建立您自己的可用性實驗室或開發內部的可用性程式,在您的設計過程中引入可用性理念。
如果您寧願自己僱傭可用性專業人員,那麼 Human Factors and Ergonomics Society 有職業介紹服務,使您可以找到潛在的僱員。很多可用性專業人員還屬於 ACM Special Interest Group on Computer-Human Interaction (SIGCHI) 和 UPA,您也可以在他們的出版物和會刊上刊登招聘廣告。
無論您選擇哪種途徑,請記住:您將要僱傭的是測試服務人員,而不是那些自己訪問您的介面,並告訴您介面上有哪些錯誤的人員。設計人員不是普通使用者的原則同樣也適用於可用性專業人員。
關於這些公司和組織的資訊,請參見下文的“資源”,您從中可以找到更多的關於可用性測試和以使用者為中心的設計的內容。
資源
文獻和書籍
Beyer、Hugh 和 Karen Holtzblatt。Contextual Design: Defining Customer-Centered Systems。San Fran: Morgan Kaufmann, 1997。(ISBN: 1558604111)
Dumas、Joseph S. 和 Janice C. Redish。A Practical Gu to Usability Testing。 London: lect Books, 1999。(ISBN: 1841500208)
Gould、John D.、Stephen J. Boies 和 Clayton Lewis。"Making Usable, Useful, Productivity: Enhancing Computer Applications。" Communications of the ACM (January 1991): 72-86。
os、JoAnn T. 和 Janice C. Redish。User and Task Analysis for Interface Design。New York: John Wiley and Sons, 1998。(ISBN: 0471178314)
Nielsen, Jakob。Usability Engineering。Boston: AP Professional, 1994。(ISBN: 0125184069)
Shneiderman 和 Ben。Designing the User Interface: Strategies for Effective Human-Computer Interaction。Reading, MA: Addison Wesley, 1998。(ISBN: 0201694972)
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-987799/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 軟體的效能設計(一)介面設計對軟體效能的影響 (轉)
- 軟體設計雜談(二)--軟體設計與設計人員的個人素質 (轉)
- TRIZ在軟體設計中的思考
- 軟體設計深度挖掘(一) (轉)
- 軟體測試用例設計中的結構設計
- 用例設計在軟體開發專案計劃中的應用(轉)
- 【軟體工程】軟體設計之總體設計軟體工程
- [轉載]好的程式設計師做不出好的軟體設計程式設計師
- <<軟體設計學習筆記>> (轉)筆記
- 軟體的效能設計(二) 臨時物件對軟體效能的影響 (轉)物件
- 開發流程中的可用性 (轉)
- 軟體設計
- 軟體效能的設計(三)資料型別對軟體效能的影響 (轉)資料型別
- 網站設計中不可忽視的可用性原則網站
- 形象化的多媒體軟體主呼叫程式設計 (轉)程式設計
- 進銷存軟體之OO設計--中間層處理(二) (轉)
- 成功軟體開發者的9種程式設計習慣 (轉)程式設計
- Java程式設計:軟體最大的追求是什麼?(轉)Java程式設計
- 軟體設計雜談(一)--需求分析與系統設計 (轉)
- [軟體人生]程式設計師轉行,需要麼?程式設計師
- 軟體工程——程式導向的軟體設計方法軟體工程
- 微服務可用性設計微服務
- 用例設計在軟體開發專案績效考核中的應用(轉)
- 軟體設計是怎樣煉成的(4)——軟體設計的“大道理”
- 軟體設計模式設計模式
- 哪種人是軟體設計中的稀缺型人才?
- 軟體架構設計中要注意的六個方面架構
- 軟體測試中過度設計的那些事兒
- 【架構設計】你真的理解軟體設計中的SOLID原則嗎?架構Solid
- 二八法則在軟體設計中可行嗎?
- 軟體工程“36計”(轉)軟體工程
- 怎樣成為優秀的軟體模型設計者 [轉]模型
- 成功軟體開發者的9種程式設計習慣 7 (轉)程式設計
- 成功軟體開發者的9種程式設計習慣 1 (轉)程式設計
- 成功軟體開發者的9種程式設計習慣 2 (轉)程式設計
- 成功軟體開發者的9種程式設計習慣 3 (轉)程式設計
- 成功軟體開發者的9種程式設計習慣 4 (轉)程式設計
- 成功軟體開發者的9種程式設計習慣 6 (轉)程式設計