可用性工程閱讀筆記

可用性工程閱讀筆記 Nielsen?

看這本書和寫下這些筆記總共用了快兩個星期的時間,這段時間事情真的有點多。。

從這本書里,能夠看到關于可用性測試中的績效測試真的和我們心理學平常的實驗設計很像。我覺得在看到那部分時最驚訝的是,關于作者提出來的若干個可以用在實驗測試中的指標,我覺得如果不是平常比較擅長于這方面可能真的想不出那么精妙的指標。總體上來說,是對產品的可用性概念更加清晰了,應該對正在參加的這個比賽的整體設計有很大的幫助。

1.可用性及相關概念

可用性對于系統可接受性來說,是一個相對來說較小的概念。系統可接受性表示的是是否可以達到滿足用戶和其他可能的相關方(如用戶的客戶和經理)的所有需要和需求的程度。

可用性和系統可接受性的關系:


2.可用性的五個傳統成分:

1)可學習性:系統應當容易學習,從而用戶可以在短時間內開始用系統來做某些事情;

2)效率:系統的使用應當高效,因此,當用戶學會使用系統后,可能具有更高的生產力水平;

度量使用效率的典型方法是,確定關于某技能水平的定義,尋找一些具有這種技能水平的有代表性的用戶樣本,然后度量這些用戶執行某些典型人物測試所用的時間。

3)可記憶性:系統應當容易記憶,從而那些非頻繁使用系統的用戶,在中間有一段時間沒有使用之后能夠使用系統,而不用重新從頭學起;

關于界面的可記憶性的測試,有兩種主要的方法:一種方法是對于在特定長的一段時間內沒有使用系統的用戶,進行標準用戶測試,度量這些用戶在執行某些任務上花費的時間;另一種是在他們結束一個使用系統過程后,讓其解釋各種命令的作用,或者完整說出某種功能的命令(或畫出對應的圖標),最后得到用戶界面的可記憶得分,就是用戶給出正確答案的個數

4)出錯:系統應該具有低的出錯率,從而用戶在使用系統過程中能夠少出錯,在出錯之后也能夠迅速恢復,而且能夠防止災難性錯誤的發生;

可以通過統計用戶執行某個任務過程中出現錯誤的次數來作為度量指標。

5)滿意度:系統應該使用起來令人愉快,從而讓用戶在使用時主觀上感到滿意。

從原理上說,可以采用腦電圖、瞳孔擴散率等指標作為評判用戶在使用過程中的壓力和舒適程度,但測量這些生理指標會需要用戶配合額外的儀器,可能會成為用戶畏懼的條件。因此在滿意度的這項屬性中我們通常的方法是讓用戶在測試完成之后填一份主觀滿意度的問卷

2.為了在一組可用性度量的基礎上確定系統的整體可用性水平,通常的做法是取每個可用屬性度量的平均值沒然后看他們是否比先前確定的某個低標準要好。

3.一個關于圖標的可用性測試實例:

參見參考文獻:

[Green?and?Barnard?1990;?Hakiel?and?Easterby?1987;?Magyar?1990;?Nolan?1989;?Salasoo?1990;?Stammers?and?Hoffman?1991;?Zwaga?1989]

關于可學習性:

為某個圖形界面設計了四套不同煩人圖標,每套17個。對每套圖標都測試其易學習性、使用效率和主觀滿意度。

程序:

每次向被試呈現一個圖標,讓用戶描述“你認為這是什么意思?”——測試每個圖標的直覺性;

向被試展現一套圖標,告訴用戶一個圖標的名字以及它是做什么的的簡短描述,讓用戶把他們覺得最匹配的圖標選出來------測可理解性;

告訴被試一套圖標的名字,讓被試把它們與所有圖標相匹配——測可理解性;

以上學習測試中的得分就是這些被正確描述和命名的圖標所占的比例。

關于可記憶性:

在第一個測試中,對于通過參加學習測試已經知道圖標含義的用戶,給他們一個圖標的名字,告訴他們它可能會出現在計算機屏幕中,然后隨機地顯示圖標,如果是用戶要尋找的圖標,用戶就按下“是”,如果是其他圖標,就按下“否”。

在第二個測試中,向用戶同時顯示最忌分布的若干圖標沒讓用戶點擊相應的那個。這兩個圖標都是計時的,圖標的得分就是用戶的反應時間。

關于主觀滿意度:

第一種方法是,讓用戶就圖標是否容易識別,挨個圖標給打分。第二種方法是,針對17個概念中的每一個,給用戶顯示可能的四個圖標,讓用戶選擇他更加傾向哪一個。主觀測試中的滿意度得分,就是用戶在第一個測試中給該圖標的打分,以及在第二個測試中選擇該圖標的用戶比例。

最好的圖標可以既表現操作的具體對象,又抽象地表示所進行的操作對象。

4.可用性權衡的問題:

一個系統可以是容易學習的或者是,難學習到最后使用效率卻是高的。

和人的記憶學習曲線一樣,注重新手的使用效率或者考慮給熟手創造更高的使用效率其實是不能夠同時滿足兩者的,但可以把兩種學習曲線好的部分結合起來,提供具有多種交互風格的界面,使得用戶可以在開始學習階段先學習使用容易學習的交互風格,后來在裝箱對于頻繁操作更高效率的風格。實現這種優勢互補的途徑就是用“加速鍵”,可以讓用戶更快捷低執行頻繁操作的任務,盡管同樣的任務也可以通過更一般的、也許比較慢的范式執行。加速鍵的典型例子包括功能鍵、命令名縮寫以及通過栓劑來激活某個對象。

5.關于用戶分類和個體差異


對于在相關領域有廣泛知識的用戶,可以再假面上使用專用術語,屏幕設計中的信息密度也可以加大。

6.關于計算機和用戶界面分帶的情況總結:


7.可用性生命周期:

可用性工程晟敏周期模型中的階段:

1)了解用戶

a.個體用戶特征

b.用戶當前的任務和需要的任務

c.功能性分析

d.用戶及其工作的演變

2)競爭性分析

3)確立可用性的目標

a.經濟影響分析

4)并行設計

5)參與型設計

6)整體界面的協同設計

7)指南應用和經驗性分析

8)原型

9)實驗性測試

10)反復設計

a.捕捉設計原理

11)從現場使用中搜集反饋。

這個生命周期模型強調的是,不應當部分青紅皂白地直接進入設計階段,想要使可用性活動左右產品的設計,最省力的辦法實在設計開展之前做可能多的可用性工作,這樣就不必為了滿足可用性方面的要求而更改設計。而且,在設計開展之前所開展的可用性活動,可能會避免開發那些不必要的功能。

了解用戶:

個體特征和各種不同的任務,是對可用性影響最大的兩個因素,應當對它們進行認真研究。通過了解用戶的工作經歷,教育程度,?年齡,計算機使用經驗等情況,可以在某種程度上預測它們在學習上回遇到的困難,從而對用戶界面的復雜程度作出恰當的控制。我們還應當了解用戶的工作環境和社會環境。舉一個簡單的例子,聲音提示“嘟”聲或者更加復雜的聲音效果,對于在開放式辦公環境中的用戶來說是不太合適的。在作者曾經做過的一個用戶訪談中,有一位秘書強烈不滿,她需要能關閉“嘟”聲提示音的功能,因為她不想要因為她的計算機總是想個不停,而讓其他人覺得她很笨。

任務分析:

任務分析是系統設計必需的早期輸入,應當研究用戶的最終目標,還要研究他們目前是怎樣執行任務的,他們的信息需求,以及他們怎樣處理異常或者緊急情況。此外,還應該識別用戶的任務模型,因為可以利用它得到關于如何設計用戶界面的隱喻和啟發,而且,通過觀察那些特別有效的用戶及他們的策略和工作環境,可以對于新系統應當提供的支持得到某些特別的啟示。最后,應該找到當前情況下存在的問題,既用戶未能實現的目標,花費過多時間和感到不舒服的地方,這些弱點將為改進新產品提供了機會。

任務分析還可以暗戰結構進行分解,大任務分成小任務。每當用戶在說“然后我做這件事情的時候”,進行訪談的人員就可以問兩個問題“你為什么做這件事情”(把這件事情與更多的目標聯系起來)“你怎樣去做這件事情”(把這件事情分解成小任務,以便進一步研究)。訪談的最后還應該讓用戶談一下留下印象深刻的成功或者失敗的事例,存在的問題,他們最喜歡什么東西和最不喜歡什么東西,希望有什么改變,對改進有什么建議,以及目前的什么東西讓他們感到煩惱。

競爭性分析:

原型是可用性過程中的重要組成部分,而享有的產品或者同類競爭者的產品,則常常是可以得到我們自己產品最好的原型。可以對現有的產品根據成熟的可用性指南進行經驗性分析,或者對這些產品進行實驗性用戶測試。針對于已經完全實現了的產品進行用戶測試要比對其他原型的測試更現實一些。用戶可以使用同類競爭系統來執行真實任務,這使得我們可以了解,其功能和交互技術能否很好地支持這些任務,而這些任務是已規劃的產品根據對目標用戶的初步研究所預計要支持的。

確立目標:

可用性并不是系統的單維屬性。可用性包含若干彼此可能互相矛盾的成分。一般來說,在一個特定的項目中,并非可用性的所有方面都具有同樣的權重,所以必須根據用戶和任務中的分析來明確他們的優先級。例如,有不斷的新雇員招進來的話,就應該將系統的可學習性放在重要的位置;而對于那些每3-4個月才會使用一次系統的重配置實用程序來說,非頻繁型用戶使用系統的能力就應該受到重視,

對于每一個感興趣的可用性屬性,在確立可用性目標的過程中可以定義若干不同的績效水平,至少定義對于產品發布來說可接受的最低水平,更詳細的目標定義還可以包括計劃達到的績效水平和目前的績效水平。另外,還要對系統的可用性的經濟影響進行分析以及他們使用系統的大致時間量。

并行設計:

在開始及時,有一個不錯的方法就是進行并行設計,既有幾個不同的設計人員來進行初步設計,并行設計的目的是在確定某個設計方案之前,先對幾個不同的設計方案進行一番探索,然后再對確定的設計方案做進一步的開發,開展更細致的可用性活動。在進行并行設計的時候,重點是要讓設計人員進行獨立設計,因為其目標是為了產生可能大的多樣性,因此,在產生各自的設計草圖之前,不應該要設計人員討論他們之間的方案。

并行設計的另一種變形是多樣化并行設計。它是基于讓不同的設計人員側重于不同的設計問題。例如們可以讓一個設計人員針對新手用戶來設計界面,同時讓另一個人來這對熟手用戶來設計一個方案,再讓第三個人來探索一個完全無需語言的界面。通過確定每個設計人員的設計方向,多樣化并行設計的方法可以把每一種方案推向極致,從而得到在通用設計方案中很難出現的設計構思。當然,對于某些多樣化的設計構思需要進行修改,才能用到一個統一和集成的設計方案中。

咋一看,并行設計的方法可能和經濟上的可用性工程是相抵觸的,因為大多數構思被拋棄了,然而實際上,并行設計是一種探索設計中非常經濟的辦法,這正是由于對大多數設計構思都不需要費力去實現,而如果不這樣做的話?,其中的某些構思則要等到晚一些時候進行反復設計才能夠實現。

參與型設計:

盡管在設計開始之前,我們就對用戶進行了相應的了解,但這樣的了解是不足以解決設計過程中的所有問題。在設計過程中,設計人員不應當只憑猜測,而硬鋼與一些用戶代表保持溝通,用具體非呈現形式呈獻給將要使用產品的領域專家,引導和啟發他們談出自己的想法。

隨著用戶參與系統的開發過程,他們會逐漸變得不具有普通用戶的代表性,一個參與過太多設計會議煩人用戶代表,將會受到開發人員的思維方式侵染,將會了解所提出的系統結構,并可能會傾向于接受那些有問題的設計部分所做的解釋。而后來參與到項目中的新鮮用戶,則更可能對這種潛在的問題提出質疑,因為他們并不了解歷史。

整體界面的協調:

一致性是最重要的可用性特征之一。對于一致性的度量在時間上并不是一次性的,而應當應用于產品的后續更新的版本,也應該牡蠣在整個產品族中的一致性。

原型:

早期的可用性評估可以基于最終系統的原型進行,?可以用更快捷和更經濟的方法來開發這種原型,因此在對用戶界面設計上獲得更好的認識之前,可以對它進行多次修改。

減少功能數的辦法為垂直原型,因為這樣產生的是一個狹窄的系統,它的確包含某些完整的功能,但只針對少數選擇的功能。

降低功能水平的做法成為水平原型,這樣產生的知識結果的一個表層,具有完整的整個用戶界面,意味著用戶可以執行所用的導航和搜索命令,卻不能通過執行這些命令得到一個任何真實的消息。

劇情:

劇情是對事物的一種很籠統的描述,一般包含以下幾種元素:用戶個體,對一組特定功能計算機功能的使用,獲取特定的結果,在特定的情況下會發生什么,經過特定的時間間隔(明確包含什么時間發生了什么事情)。執行用戶測驗之前,可以詢問用戶接下來他們認為會發生什么事情。

界面評估

對于一個界面,采用合理的可用性工程評估方法評估改進后的界面再進行發布,會比沒有經過測試就直接發布的產品的產品好太多,同時會比不斷遞增的版本更加省時省力。

嚴重性評價

不論采用什么方法評估,所得到的主要結果都是這樣一個清單,內容為界面存在的可用性問題,以及關于改進功能以及支持用戶任務的建議。通常,想要解決所有問題都是不太現實的,因此需要對現有的問題進行優先級排序。一般在這個過程中,我們會邀請可用性專家進行一個評估,由于不同可用性專家之間存在個體差異,所以由不同可用性專家評判的嚴重性程度并非一直都是可靠的,所以應該綜合多個可用性專家的意見,去他們評判的平均值能夠得到一個較為準確的結果。

嚴重性評價的兩種方法是,一種采用單一尺度,另一種是采用若干正交尺度組合的方式。

單一尺度:

0=這根本不是一個可用性問題;1=只是一個表面的可用性問題,除非項目有額外時間,否則不必進行糾正;2=輕微的可用性問題,糾正這一問題的優先級較低;3=重要的可用性問題,需要重視改問題的糾正,應當給以高優先級;4=可用性災難,在產品發布之前必須予以糾正。

嚴重性程度還可以根據可用性問題最重要的兩個因素來評價,預期用戶會遇到這個問題,以及這些用戶受該問題影響的程度。

捕捉設計道理:

可以吧各種用戶界面設計決定背后的中藥道理甲乙明確的記載,以便于設計參考。在反復設計和開發產品未來的版本的時候,對界面設計的道理回顧是非常重要的,因為經常需要對界面進行修改,所以最好能夠了解設計方案的基本原理,從而不會為了微不足道的目標而損害最原始的設計原理。

可用性活動的優先順序:

以下是通過對13位可用性專家的調查后得到關于可用性活動的重要性程度打分,得分最高的6種方法是:1-2名是反復設計和對當前用戶的任務分析,得分為4.7。第3名第用真實用戶進行的實驗性測試,得分為4.5分。第4名是參與型設計,得分為4.4。第5和6名是在設計開始前訪問顧客現場,在系統安裝運行后進行現場研究,以了解系統的實際使用情況。?在實際項目中,各種可用性方法的使用頻率呈現一種搞得相關性(r=0.71)。

8.可用性經驗原則:

(1):簡潔而自然的對話。在屏幕中每增加一個額外的功能,就以為著用戶需要學習更多的東西,誤解的可能性就會越大,查找所需要的功能就會越來越困難。理想的情況下是僅提供用戶當前所需要的信息,并把他們放在所需要的地方。在頁面的布局上應當利用人類認知領域中的完全形態法則,以增加用戶對對話元素間相互關系的理解。可以通過用大寫字母的辦法來突出重點,但是不要過于頻繁的使用,因為大小寫混合文本會讓用戶的閱讀速度降低10%。?同時也不要過度地使用顏色,顏色數量方案中最好不要超過5-7種,因為用戶很難記憶和區分太多顏色,即使是經過專門訓練的用戶也只能夠對付大約11種顏色。另外,還要確保界面再不用顏色的情況下也能使用,要記住,很多人是色盲(8%男性)。

少即是多:

通過恰當的任務分析,通常能偶把對用戶真正重要的信息識別出來,用戶利用這些信息可以完成絕大部分任務。在設計過程中,最好將重要的任務放在主要屏幕上,將不太重要的任務放在輔助屏幕上。

(2)使用用戶的語言:開發人員或許對于產品的專業術語很熟悉,但是用戶未必能夠理解,如果能夠將產品中用于和用戶交流的語言換成用戶的母語,將會使得用戶的使用效率增加。

還可以使用映射和隱喻的方法:為了實現面向用戶的對話,一種比較常見的辦法是力爭讓計算機顯示的信息和用戶關于信息的概念相符。通常,會要求用戶列出一組與應用領域相關的概念,并且依據用戶的應用領域模型進行排組和分析。其中一些常用的技術包括順序回想(讓用戶盡可能自由地聯想他們所能夠想到的概念,其中運用的原則是一同提到的想法和概念模型中是相關聯的),卡片分類,相似性打分(提供問卷,其中包括各種可能成對的概念,讓用戶對他們的相似性進行打分),這些測試的結果可以拿來直接使用,已通過使用統計程序來用于多維度量或聚類分析。

(3)將用戶的記憶負擔減到最小:

可以通過預測用戶輸入的內容來采取相應措施,比如在輸入日期的對話框中,就應該在附近提示輸入內容的格式或者提供用戶最近使用的文檔,供用戶直接選擇,而不是要讓用戶器回想或者猜。

(4)一致性:如果用戶知道同樣的命令或者同樣的操作會產生同樣的效果,那么他們在使用的過程中就會更加自信,同時也能夠鼓勵他們進行探索性學習,因為他們已經具備了使用系統新部分應該有的基礎知識。另外,還要考慮系統任務和功能結構上也要考慮一致性。比如,有人發現,用戶在采用命令行的PC機和采用命令行的大型機之間切換,要比在采用命令行的PC機和采用圖形界面的PC機之間的切換更困難。從屏幕設計的觀點上來看,兩個命令行的界面非常相似,但其底層的操作系統差別卻很大,而兩個不同類型的PC界面是建立在具有同樣原理和功能的系統之上的。

(5)反饋:系統應該不斷告訴用戶目前他正在做什么,而不應該等到系統出錯的時候才給用戶反饋:在用戶操作正確的時候,系統也應該提供部分的反饋,并且當產生部分信息時應當給出部分信息的反饋。

響應時間:?如果系統所進行的操作需要很長的響應時間,反饋就變得很重要了,鯽魚響應時間的基本建議多少年來都基本變化不大:

0.1秒是讓用戶感覺到系統立即做出了響應的時間上限,此時除了顯示結果外不需要其他反饋;1.0秒是讓用戶思維不被中斷的上限,但用戶會感覺到延遲。通常不需要對0.1-1.0秒的延遲專門給出信息反饋,但此時用戶會失去數據直接操作的感覺。10秒是讓用戶注意力保持集中的上限。對于較長時間的延遲,由于用戶想在完成等待的時間里去完成其他任務,因此應該在任務快要完成時應當用過反饋信息來提示用戶。響應時間不確定的情況下反饋顯得尤為重要,因為這時候用戶不知道要發生什么事情。

(6)清楚地標識退出:

(7)快捷方式:?典型的快捷方式包括縮寫,功能鍵,命令鍵等,其中命令鍵使用一個按鍵代表一個完整命令,雙擊對象會進行最常用的操作。利用交互歷史提供訪問的一個簡單的例子是,一些程序會記錄用戶經常打開的文件,這些程序可以為用戶提供一個特殊的文件菜單,列出下一個用戶可能會打開的文件。

(8)好的出錯信息:出錯的信息應該用清晰的語言表達出來,而不要使用難懂的代碼,出錯信息也應該精煉準確,如應該顯示“無法打開該文檔,由于文檔不再磁盤上”而不是僅僅顯示“不能打開文檔”,另外,出錯信息應該友好,不要威脅或者責備用戶,如經典錯誤:“非法用戶操作,任務被終止”

(9)多層次消息:不要在小子中包含所有可能有用的消息,而應該使用簡短的消息以方便用戶快速閱讀,只要用戶能容易地訪問更詳細的信息就好。

(10)避免出錯和避免使用用戶模式

(11)幫助和文檔:提供使用手冊和在線幫助和在線文檔。在線幫助的好處就是上下文相關。

(12)經驗性評估:經驗性評估的目標是要發現用戶界面設計中的可用性問題,因此經驗性評估可以成為反復設計中的一部分,其他可用性檢查的方法海英擺闊認知步進評審和訴求分析。單人評估可能會漏掉假面評估中的大部分可用性問題,有研究[Molich?and?Nielsen?1990;?Nielsen?and?Molich?1990;?Nielsen?1992C?1994b]在對6個項目進行評估以后,發現單人評估人員往往能夠發現35%的問題,但由于不同的人會發現不同的問題,因此綜合了多個人(10人)的看法觀點會得到一個更好的結果。注意,要評估人員進行獨立評估,最后才對比其他評估人員的觀點,這樣能夠避免這個評估是獨立的,無偏向的。評估者發現問題的能力也是一個值得考慮的地方。

9.可用性測試

可用性測試要保證可靠性和有效性(信度和效度的問題)。

(1)測試目標和測試計劃

在進行任何測試之前,都應該搞清楚測試目的,因為對要進行什么樣的測試有重要的影響。測試的種類分為兩類,一類是形成性評估,反復設計中的一部分,目的是為了改進界面,因此這類測試的目標就應該是了解界面細節方面的優劣,如何改進設計,典型方法是邊說邊做式;另一類是總結性評估的目的在于評定界面的整體質量,例如可以用它在兩個備選方案中進行懸著,或者競爭性分析的整體質量,倆了解競爭對手的產品設計好在哪里。

測試計劃里面應該包含的內容有:

測試目標、測試時間地點、測試時長預期、測試需要的裝備、測試要用什么樣的軟件、測試時系統處于的狀態、測試時系統的網絡負載和響應時間、測試人員、測試的用戶、測試用戶的數量、測試用戶需要完成的任務、怎么找到用戶、用戶完成測試的標準、測試用戶可以使用的輔助手段、測試人員可以給測試用戶提供怎樣程度的幫助、測試要收集什么樣的數據,數據怎么處理和分析、判斷界面成功的標準是什么。

測試預算:應該包含兩部分,一部分是固定費用和可變費用。固定費用是計劃和組織測試做所需要的花費,而不考慮用戶的多少,可變費用是付給用戶的額外費用。

另外,最好還是要先進行試點測試,防止一些任務不被理解。

(2)招募測試用戶

有關找測試用戶的主要原則,就是所選擇的用戶越能代表預期使用系統的用戶越好。還要明確的是,這是新手用戶還是熟手用戶,如果是新手用戶,還應該給他進行一些簡單的培訓先;用戶間測試還是用戶內測試,這里要注意的是應該按照實驗設計的方法來設計測試,平衡問題;實驗人員的發現問題的能力也需要值得注重,好的實驗人員和差的實驗人員發現問題的數量可以差上好幾倍,實驗人員還應該具備大量有關程序和用戶界面方面的知識;最后,還要注意用人來進行測試的倫理問題。


(3)測試任務的設計:

測試任務的基本原則是所選擇的測試任務要盡可能地代表系統的最終使用,另外,測試任務應該大致覆蓋用戶界面上最重要的那些部分,測試任務的設計可以基于任務分析或者基于產品用途說明。測試任務應該設計的比較小,這樣就能在有限的時間內完成,但是任務小也不能夠小道微不足道的程度。測試任務應該詳細精確地說明用戶執行后產生什么樣的后果,因為使用計算機來達到某一目標的過程與只是隨便用用系統是很不一樣的。測試任務設計不要輕佻、滑稽或者冒犯,例如在測試一個繪畫程序的時候,讓用戶在總統掃描的照片上畫上小胡子的做法是很不妥的。首先,不能夠保證所有人對同樣的事情都會覺得很好笑,其次,這種不嚴肅的熱內會讓系統的測試受到干擾,甚至貶低用戶的身份。相反,所用的測試任務都應該是面向業務處理的。為了增肌用戶對任務的理解和真正使用軟件的感覺,應該把任務設計的和和整個事件相關聯。測試任務的設計上還可以把剛開始的任務設計的比較簡單,保證用戶先得到成功的體驗以鼓舞士氣。

(4)測試的各個階段:

準備→介紹→測試→事后交流

介紹過程值得注意的點:說明測試的目的是為了對軟件進行評價,而不是對用戶進行個人測試;測試結果將會用戶改進用戶界面,所以最終發布的界面和測試中看到的界面可能有所不同;提醒測試用戶對所測試的系統保密,不要與別人談論有關的內容,以免帶給后面要進行測試的用戶一些主觀的影響。任何錄音錄像的設備要跟用戶進行解釋。

測試期間,實驗人員通常不要與用戶進行交談,也不要有人和個人觀點或關于用戶操作好或者不好的表示。實驗人員可以發出一些不代表任何態度的聲音,如“嗯”“啊哈”來表示知道用戶的評論,并讓用戶繼續做下去,這里要小心說話的語音和語調,不要讓用戶聽出他對了還是做了可笑的事情。即使用戶已經陷入了相當嚴重的困境,實驗人員也應該不要去提供幫助,不過這種不提供幫助的方法不適用于用戶已經明顯停滯并且對當前處境感到不快的時候。實驗人員應該謹慎決定自己應該什么時候提供幫助。在測試之后,要詢問用戶,并要求用戶填寫一份主觀滿意度的問卷,為了避免實驗人員的評論所帶來的偏向,用戶應當在有關系統的討論之前填寫問卷。在交談中,請用戶對系統的使用情況進行評論并提出改進建議。

(5)績效度量方法:

在各個目標之間進行平衡,決定好哪個可用性目標比較重要,然后將其細分量化,例如,“使用效率”可以用用戶完成一定數量的規定任務的平均時間來衡量。在解釋度量時,我們應該時刻關注主要成分,既總體上的使用效率,與作為該成分替代物(測試任務)的特定量化指標之間的區別。一個明顯的例子是,反復設計過程中不應該把目標?在僅僅針對所要求執行的5個任務,而不考慮其他方面來優化界面,以改進系統的使用效率。

量化指標后,應該定義一些方法來度量用戶的績效,通常可以量化的可用性度量指標包括:

*用戶完成任務的所有時間;

*在限定時間內完成的任務數量;

*正確的交互操作與所發生錯誤之間的比率;

*從錯誤中恢復所用的時間;

*用戶出錯的數量;

*隨后導致的出錯操作數量;

*用戶用到的命令或其他功能的數量;

*使用手冊或者幫助系統的頻數,以及使用時間;

*手冊/幫助系統有多少次解決了用戶的問題;

*用戶在測試期間對系統肯定和批評的比率;

*用戶表達明顯的挫折或者喜歡的次數;

*表示喜歡用該系統而不喜歡用某個特定競爭產品的比例?;

*用戶不得不試圖解決或者某個無法解決問題的次數;

*采用高效策略和使用低效策略的用戶之間的比例(在有多種方法完成任務的情況下);

*用戶不與系統進行交互的“呆滯”時間,可以在系統中度量出兩種呆滯時間,一種是用????戶等待系統響應所造成的延遲,另一種是等待用戶思考所造成的延遲,這兩種呆滯時間顯然可以用兩種不同的方法研究;

*用戶注意力從真實任務唄吸引到其他地方的次數。


(6)邊說邊做的辦法:通過測試用戶對自己想法的描述,我們能夠了解他對計算機的想法,還能很容易地確定用戶對系統主要有哪些誤解。這種方法的缺點在于,它并不適用于大多類型的績效度量。邊說邊做的方法還有的缺點就是,口述所做的事情將會減慢用戶的操作的速度,使得這樣得到的績效度量缺少對用戶正常工作速度的代表性。其次,用戶在口述他們想法的同時必然影響到他們解決問題的行為。

實驗人員常常需要不斷提醒用戶,向他們提出類似“你正在想什么”“你認為這條信息是什么意思”(當用戶已經注意到這條信息并且在花時間查看和考慮的時候)這樣的問題,讓用戶大聲說出他們這樣的想法。如果用戶問:“我能夠這么做嗎?”,實驗人員不應該回答,但可以用反問的方法來讓用戶繼續說話,“如果你這么做了你認為會有什么結果?”如果系統的反應讓用戶感到驚訝卻沒有說什么,實驗人員就應該這樣來提示用戶,“這是你預料中的事情嗎?”當然,遵循在用戶使用系統時不要干擾用戶這一通用的原則,實驗人員不能在用戶沒有注意到某個消息的時候這樣提示用戶“你認為在屏幕底部的消息是什么意思?”

協同交互的方法:?邊說邊做的方法的另一種變形,讓兩個測試用戶同時使用一個系統。它的主要優點在于,測試形式比只用單一用戶進行的標準邊做邊說測試顯得更為自然一點,因為人們習慣于在共同解決問題的時候把自己的想法說出來。協同交互的方法尤其適合對于兒童使用的用戶界面的可用性測試,因為讓孩童遵循邊說邊做的方法有點困難。

回顧式測試,如果在測試期間錄了像,就可以讓用戶回顧錄像的內容來收集額外的信息。在看錄像帶的時候用戶不會那么緊張,偶執行測試任務時的緊迫感,因此會說出更多意見。當然,這種方法的缺點在于每個測試至少要用雙倍的時間,因此這個方法不適用于用戶報酬很高的情況下。

輔導方法,多少和其他測試方法有些不同,它在測試用戶和實驗人員之間有清楚的交互過程。測試前,測試用戶可以問任何與系統相關的問題。有一種變形的輔導方法是從熟練的用戶中選擇一個人來作為輔導人員。設立這樣一個單獨的輔導人員,可以讓實驗人員來研究輔導人員是如何回答問題的。這種變形方法可以用來分析熟練用戶擔任的輔導人員對界面所形成的模型。當然,輔導方法通常關注的是新手用戶,目的是發現這些用戶的信息需求,以便提供更好的培訓和文檔資料,同時還能夠幫助重新設計界面來避免這些問題。

10.其他可用性評估方法

(1)觀察法:是所有可用性方法中最簡單的方法,因為只需要訪問一個或者幾個用戶,讓他們使用系統和產品和做筆記即可。在進行觀察的時候,觀察人員自始至終應該盡量保持安靜,讓用戶操作時感覺旁邊沒有人會比較自在。對于在觀察過程中看到的無法理解用戶的操作,我們應該把這些?行為記錄下來,事后詢問用戶為什么要這樣做,聽取他們的解釋。

(2)問卷調查和訪談:從可用性的角度來看,問卷調查和訪談屬于間接的方法,因為兩者都不對用戶界面本身進行研究,而只是研究用戶對界面的看法。

附一個用戶界面滿意度的問卷:QUIS(Questionare?for?User?Interface?Satisfaction),方法[Chin?et?al.,?1988]。通常建議是用稍短的問卷獲得更多的信息,對于較忙的用戶,如果問卷短一些的話,能夠得到填寫的機會遠遠大于長問卷。

(3)焦點小組:是一個非正式的方法,用來在界面設計之前和經過一段使用后評估用戶的需要和感受。在焦點小組中,請大約6-9個用戶在一起討論新的概念,和摸清一些問題,時間一般為一兩個小時。焦點小組中有一個主持人,負責是小組的討論集中在焦點話題上。主持人事先提出問題,小組中的用戶在交互過程中,常常會流露出用戶的自然反應,焦點小組的最大優點是能夠對小組的動態變化和組織問題進行考察。焦點小組在參與討論的人數上有嚴格要求,因為既要保證討論的流暢,又要體現用戶的不同觀點,所以不能少于6人。

(4)記錄實際使用情況:

記錄數據指的是計算機自動收集的關于系統使用情況的詳細統計數據。這是非常有用的,因為這既體現了用戶是如何完成真實任務的,也是的從工作的不同環境下的大量用戶那里自動收集數據變得相當容易。典型的界面日志文件包括:每個月用戶使用每個功能的頻率和各類事件(如錯誤信息)發生的頻率。舉個例子,Brandford等人曾記錄并分析了在命令行式操作系統下用戶發出的6112條錯誤命令,30%是由于拼寫造成的,表明需要一種拼寫校對器來協助系統用戶輸入命令。

與后續訪談相結合:用日志記錄數據的方法存在的主要問題是,它值能展示了用戶做了什么,而無法知道用戶為什么這樣做,既所謂“知其然而不知其所以然”。應該在記錄數據后再結合其他方法,如訪談,通過給用戶顯示他們使用系統時記錄的信息,請用戶詳細描述里面任何可能引發可用性的地方。

(5)

用戶反饋:優點:

由用戶主動提供,因此能夠直接反應用戶最關注的地方;反饋是一個持續的過程,所以不需要進行額外的收集工作;能夠迅速反映出用戶在需求、環境和想法上的改變,因為無論何時發生這種改變,都可以通過最新的反饋顯示出來。

另外,許多軟件公司都采用beta測試,就是把即將問世的產品發行給一小部分挑選出來的客戶,讓他們做出評價。Beta測試方法能及時獲得用戶反饋,以改進產品的第一個正式發行版。

11.可用性方法匯總:

可用性方法的組合:一般來說,可用性人員首先要從界面入手進行經驗性評估,排除顯而易見的可用性問題。重新設計界面后,經由用戶測試,來檢查反復設計的效果,同時也發現經驗性評估未發現的問題。在經驗性評估和用戶測試之間進行選擇主要有兩個理由。第一個原因是經驗性評估不需要用戶參與就能夠發現并消除系統或產品中存在的可用性問題,實際上,找到一定數目的測試用戶并進行有計劃的安排,有時并不容易。第二個原因是這兩大類可用性評估方法所發現的可用性問題有明顯的不同,這意味著兩種方法可以互補而不會重復。

12.界面的標準:

(1)界面的一致性和標準有益于用戶,一致性通常能夠提高用戶把使用某個系統的技能運用到另一個系統去的可能性。

(2)界面的一致性得益于軟件商,這不僅能增加界面的美感,更夠是設計人員后來可以依靠這一基本規范進行設計,把工作重點放在設計產品的獨特方面,而不需要在界面設計中重復設計每一種交互設計。

(3)標準帶來的不利因素:盡管完善的標準將會大大節省產品的開發費用,但要使標準達到優秀本身就是一個費用昂貴的過程,在標準得以使用之前,必須投入時間和財力去開發標準,這樣一來就可能導致基于這種標準的產品開發被拖延。

13.國際化用戶界面:

(1)相似圖標:描述圖標所要表示的物理對象。例如用信封圖片表示電子郵件文件就使用了相似圖標

(2)引用圖標:描述一些圖標對象,通過參照和類推的方法表達圖標想要表達的概念。例如,用彈簧夾圖片表示壓縮工具。

(3)指定圖標:指定圖標只有通過約定才具有特殊的含義,交通圖標就是指定圖標,由于交通圖標已經非常標準化,這些圖標可以構成一個很好的計算機來源。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容