欧美人与动牲交免费观看 ,亚洲欧美春色校园另类小说

搜索

APP

起點(diǎn)課堂會員權(quán)益

職業(yè)體系課特權(quán)

線下行業(yè)大會特權(quán)

個人IP打造特權(quán)

30+門專項(xiàng)技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導(dǎo)直播

12場專業(yè)技能直播

會員專屬社群

榮耀標(biāo)識

發(fā)布

注冊 | 登錄

4個方面，聊聊如何做一次更高效的可用性測試

J.Yang

2017-12-01

1 評論 6764 瀏覽 25 收藏

32 分鐘

前段時間做過了一次比較系統(tǒng)的可用性測試。因此寫了這篇文章作為個人對可用性測試的梳理和反思。

可用性測試是一個體量很大的學(xué)科，僅僅從形式和平臺兩個維度去分，就可以細(xì)分出十幾種不同的可用性測試，而每種不同的測試其研究方法還有相當(dāng)大的不同。

而且我相信，即使是同樣的一個目標(biāo)，由不同的角色去設(shè)計和執(zhí)行（比如咨詢公司的用研人員，某些公司專門的用研部門，或者業(yè)務(wù)線上的產(chǎn)品經(jīng)理）也會有不同的方法和側(cè)重點(diǎn)，因此本文數(shù)千字的篇幅是不可能涵蓋可用性測試的方方面面的，甚至連作為某一種特定的可用性測試的工具書都不夠詳盡。

這里只是我作為一個業(yè)務(wù)部門里的交互設(shè)計師，就我們采用的實(shí)驗(yàn)室的可用性分析（usability lab studies）來談一談進(jìn)行可用性測試的一些技巧和需要注意的點(diǎn)——總的來說，站在測試的大目標(biāo)下，我們的每一個決定和方法都需要緊貼在目標(biāo)上，每一個步驟都需要有合理的前因后果和清晰地邏輯。

本文分為“可用性測試的時機(jī)”，“可用性測試的目標(biāo)”，“以目標(biāo)為導(dǎo)向的方案設(shè)計”和“測試的過程”四個部分。

可用性測試的時機(jī)

廣義的可用性分析是指讓用戶使用真實(shí)材料（包括真實(shí)的產(chǎn)品，模塊，頁面，原型，概念等）來探索其可用性的研究。包括了概念測試（concept testing），實(shí)驗(yàn)室的可用性分析（usability lab studies），遠(yuǎn)程的有指引可用性測試（moderated remote usability studies），快速迭代的測試和評估（rapid iterative testing and evaluation），眼動分析（eyetracking）等。

我們將這些可用性測試的方法放到用戶研究方法的“定性—定量／態(tài)度-行為”坐標(biāo)系中，我們發(fā)現(xiàn)各種可用性測試方法涵蓋了定性到定量的整個坐標(biāo)軸，而在縱坐標(biāo)軸上，可以看到可用性測試是偏向行為的。

因此，不論是要對系統(tǒng)的可用性得到一個概括性的結(jié)論，還是要針對一個模塊的可用性進(jìn)行精確的數(shù)據(jù)分析，我們都可以通過不同的測試方法來完成。然而不論是哪一種方法，可用性測試的核心都是建立在觀察上的。

那么，我們應(yīng)該在什么時候去發(fā)起一次可用性測試？NNG的聯(lián)合創(chuàng)始人Jacob Nielsen列出了以下三個場景：

在迭代的過程中，特別是兩個迭代之間的時候。我們需要知道我們本期的設(shè)計是否解決了之前的問題，或者我們還需要繼續(xù)改進(jìn)我們的設(shè)計方案。
數(shù)據(jù)不會騙人——對于競品的可用性分析，可用性測試得到的指標(biāo)是非常有用的。
在每一次新的發(fā)布之前，我們需要在腦海中有一個清晰的目標(biāo)。當(dāng)我們對現(xiàn)在的設(shè)計方案沒有很大的把握的時候，一次可用性測試可以告訴我們，新的版本是不是已經(jīng)準(zhǔn)備好發(fā)布了。

總的來說，可用性測試最好是發(fā)生在整個設(shè)計周期里的研究階段（在連續(xù)迭代的過程中，研究可以被看作是一個設(shè)計周期的第一環(huán)，也可以是發(fā)布后的最后一環(huán)）在我們擁有一個真正的產(chǎn)品之前，我們需要知道一個方案是否可行，此時需要注意的是，我們需要平衡可用性測試材料的保真度。

我們可以用一個盡量輕量級的原型來進(jìn)行，這樣就可以盡快的對設(shè)計方案進(jìn)行迭代；當(dāng)然，它也要有足夠的細(xì)節(jié)來讓用戶明白我們到底做了一個什么東西，并且能夠被帶入到我們預(yù)設(shè)的場景里。再就是在我們發(fā)布產(chǎn)品之后對于設(shè)計的評估和梳理，這個時候的可用性測試相當(dāng)于一次低配版的田野觀察。

可用性測試的目標(biāo)

這一部分我分兩點(diǎn)來說，第一是什么是可用性以及我們是怎么用可用性測試來衡量它的，第二是可用性測試是用來做什么。

usability.gov為可用性給出的定義是“用戶與一個系統(tǒng)交互時體驗(yàn)的質(zhì)量”，而構(gòu)成可用性的三個因素包括效度，效率和主觀滿意度。一般來說，我們通過以下的幾個維度來衡量系統(tǒng)的可用性：

設(shè)計的直觀性：產(chǎn)品的整體架構(gòu)符合用戶的心智模型，換句話說，用戶可以輕松直觀的了解產(chǎn)品的結(jié)構(gòu)，并利用導(dǎo)航系統(tǒng)在界面間清晰的移動
清晰性：界面元素表意清晰，交互方式和結(jié)果符合用戶的預(yù)期
可尋性：用戶可以快速準(zhǔn)確的找到界面的關(guān)鍵信息
易學(xué)性：一個新用戶可以輕松的完成一個任務(wù)
使用的高效性：一個老用戶可以用系統(tǒng)高效的解決問題
可記憶性：在第一次訪問這個系統(tǒng)后，用戶可以記住足夠的內(nèi)容來幫助他在以后使用的時候可以高效的使用
發(fā)生錯誤的頻率和嚴(yán)重性：用戶在使用系統(tǒng)時發(fā)生錯誤的頻率，這些錯誤的嚴(yán)重性，以及用戶能否修正這些錯誤
主觀滿意度：用戶在使用時的總體體驗(yàn)，以及他們有多喜愛這個系統(tǒng)

……

那么問題來了：我們是怎么來衡量這些可用性指標(biāo)的呢？我反思了我們之前做過的可用性測試，在所有的這些測試?yán)?，我們招募的都是從未使用過系統(tǒng)的目標(biāo)用戶。

這樣做的好處在于：上述的1-4點(diǎn)可以得到優(yōu)質(zhì)的結(jié)果。這樣的做法更適用于對設(shè)計概念和新功能的驗(yàn)證，但是我們經(jīng)常忽略的是——其實(shí)也是更難做的是——對舊功能的可用性測試。因?yàn)樵谄綍r的設(shè)計過程中，我意識到有的功能，即使是可用性很差，但是用戶在一段時間的使用后也可以正確的完成任務(wù)?；蛘呤钦f，有的功能是為多次使用而設(shè)計的，這些功能模塊可能相當(dāng)復(fù)雜或者有很長的操作路徑，特別是一些B端的產(chǎn)品，頁面的信息密度還相當(dāng)?shù)拇?，此時采用新用戶來進(jìn)行可用性測試，不一定會得到準(zhǔn)確的結(jié)論。

然而對于已有功能的可用性測試是必須而且重要的。

舉例來說，我們有一個對對象進(jìn)行批量操作的模塊，用戶需要對相似的對象進(jìn)行多次的重復(fù)操作，此時的可用性就和上述的1-4點(diǎn)沒有多大關(guān)系了，而需要度量的是系統(tǒng)的效率和容錯性。此時就需要對可用性測試的思路進(jìn)行一定的調(diào)整了，比如說，我們可以為我們的設(shè)計設(shè)定一個指標(biāo)，來觀察我們的設(shè)計能否達(dá)到這個指標(biāo)。

比如：我們的目標(biāo)是一個熟練的用戶可以在1分鐘內(nèi)處理10個對象；在沒有辦法制定指標(biāo)的時候，我們可以引入兩個方案的對比，從而選取更好的一個。

當(dāng)然，我們還需要隨時保持這樣一個意識，就是在具體的場景下，可用性測試是否是最好的方式，還是剛才那個例子，如果我們確定上面的1-4點(diǎn)都沒有問題，并且埋點(diǎn)數(shù)據(jù)的分析就可以回答現(xiàn)有的設(shè)計下用戶每分鐘處理對象的數(shù)量，那么就沒有必要去進(jìn)行一場可用性測試了。

所以最后就是關(guān)于可用性測試的使用場景，可用性測試主要有以下兩個作用：

衡量產(chǎn)品的可用性
定位產(chǎn)品問題及產(chǎn)生的原因。總的來說，可用性測試用于優(yōu)化產(chǎn)品，但是不能告訴我們應(yīng)該去做什么需求，或者是用戶想要什么。

比如說，我正在設(shè)計一個幫助用戶進(jìn)行鍛煉的應(yīng)用，系統(tǒng)里有一張匯總用戶每日跑步詳情的月匯總表，可用性測試不會告訴我們用戶為什么會去關(guān)心這張表，或者這張表會為系統(tǒng)帶來怎樣的價值——你需要通過一本叫做Hooked的書或者一些深度訪談來回答這些問題。

請注意下面這個例子：可用性測試不回答用戶會去關(guān)心這張表里的哪些字段，只有在我們預(yù)設(shè)某一個字段是重要的的時候，我們可以通過可用性測試來驗(yàn)證我們的設(shè)計是否能讓用戶直觀的接受這個字段信息。我們用數(shù)據(jù)埋點(diǎn)，點(diǎn)擊分析和問卷來了解產(chǎn)品里發(fā)生了什么，用深度訪談來了解用戶的動機(jī)，態(tài)度，想法和體驗(yàn)。而可用性測試的意義在于告訴我們一個問題為什么發(fā)生。

因此，我們不會去詢問用戶對這個產(chǎn)品的看法，而是將產(chǎn)品交給用戶，給他們布置一個任務(wù)，去觀察他們是如何與系統(tǒng)交互的，再通過這樣一些行為數(shù)據(jù)去了解系統(tǒng)中存在哪一些問題。比如說，我們通過埋點(diǎn)數(shù)據(jù)發(fā)現(xiàn)在一個復(fù)雜的注冊流程中的用戶資料上傳頁面存在巨大的跳出率，我們就需要可用性測試來告訴我們?yōu)槭裁磿羞@樣的跳出發(fā)生，以及如何修正這個問題。

以目標(biāo)為導(dǎo)向的方案設(shè)計

以目標(biāo)為導(dǎo)向其實(shí)是我一直非常認(rèn)可的一種設(shè)計思想，這種思想同樣也體現(xiàn)在了我的用戶研究上。這里也分為兩個方面：

一是和其他所有的用戶研究方法一樣，我們采用研究學(xué)習(xí)螺旋模型來規(guī)劃我們的可用性測試。這種模式的核心在于，研究的每一步都是建立在目標(biāo)之上的；
二是，我們方案里的每個行為都必須是有目的的——在我剛開始做用戶研究的時候，常犯的一個錯誤就是全套照搬別人的流程，然而在研究結(jié)束后的反思里才意識到，每一個行為都應(yīng)該是有意義的，根據(jù)實(shí)際情況的不同，我們也需要對標(biāo)準(zhǔn)的流程進(jìn)行修改或者補(bǔ)充。

設(shè)計了一個好的研究方案，就成功了一大半了。如上文所說，可用性測試的最大目的就是：

研究用戶是否能順利的通過系統(tǒng)達(dá)成目的
定位問題。第一點(diǎn)比較簡單，第二點(diǎn)稍微復(fù)雜一些。

先講第一點(diǎn)：在我們開始思考任何的方法和擬定任何的方案之前，我們需要先把本次測試的目標(biāo)定清楚，在制定研究目標(biāo)的時候，我建議根據(jù)上文列出的8個維度來思考（當(dāng)然你也可以列出更多的維度）。

比如，如果需要測試一個網(wǎng)站導(dǎo)航系統(tǒng)的可用性，那么我更傾向于去關(guān)注系統(tǒng)的“設(shè)計的直觀性”，如果我需要測試一個新用戶是否能順利的預(yù)訂酒店，那么我需要關(guān)注的可能就是系統(tǒng)的“清晰性”，“可尋性”和“易學(xué)性”。

我們需要一個清晰的框架來幫助我們梳理我們的研究目的，這樣才能保證我們可以找到一個研究對象最關(guān)鍵的點(diǎn)，并且在后續(xù)的步驟中不會遺漏掉可能出現(xiàn)的問題。在這里我們也可以看到，目標(biāo)其實(shí)是和大小無關(guān)的：測試一整個預(yù)訂流程是否流暢是一個合理的目標(biāo)，測試一個按鈕組的呈現(xiàn)方式是否足夠直觀也是一個合理的目標(biāo)。

第二點(diǎn)就是定位問題，為了精準(zhǔn)的定位到問題出現(xiàn)的原因，我的做法是將觀察的粒度拆得盡量細(xì)。而這樣的細(xì)分其實(shí)是分為兩個部分的：

通過關(guān)鍵假設(shè)將目標(biāo)拆分為可以度量的條目
?在完成了任務(wù)的設(shè)計后，需要在任務(wù)流程里設(shè)置詳細(xì)的觀察點(diǎn)。

先說關(guān)鍵假設(shè)，其實(shí)假設(shè)是我們在做用戶研究的時候很容易忽略的一個步驟。這個步驟的含義是，我們在提出了目標(biāo)之后，需要理清關(guān)于目標(biāo)，我們（認(rèn)為自己）已經(jīng)知道的事情，我們預(yù)期用戶的行為是什么，我們認(rèn)為哪些地方會出現(xiàn)問題，以及我們可能會怎么去解決這些問題。

Frog的一個設(shè)計研究負(fù)責(zé)人Jon Freach提出，在研究的早期，假設(shè)可以幫助我們感知和思考我們需要去解決的問題，更好的選擇研究方案。

具體到我們的可用性測試來說，除了上述的作用，關(guān)鍵假設(shè)還可以為我們帶來這樣的價值：我們在第一步提出的目標(biāo)其實(shí)是不能直接和具體的方法聯(lián)系起來的，這個時候，關(guān)鍵假設(shè)可以幫助我們將目標(biāo)拆分為更容易被翻譯成具體任務(wù)的條目。

比如：我的目標(biāo)是“測試用戶是否在酒店列表里能找到合適的酒店”，我的關(guān)注點(diǎn)是頁面信息的“清晰性”，“可尋性”，那么我的關(guān)鍵假設(shè)可能就是：

用戶可以清晰的理解每條記錄里具體信息的意義
我們提供的按價格，評分，星級的排序機(jī)制可以滿足用戶需求的
用戶在尋找左側(cè)邊欄的篩選控件時會遇到困難。那么根據(jù)這樣一些假設(shè)，我們只要設(shè)計出可以全部覆蓋它們的任務(wù)流程，就可以很順利的達(dá)成目標(biāo)了。

至此，我們已經(jīng)走在了正確的道路上，我們的任務(wù)可以覆蓋我們目標(biāo)可能存在的所有問題?，F(xiàn)在再來回想一下我們在一場可用性測試?yán)锏哪康模壕珳?zhǔn)的定位問題，以及挖掘問題發(fā)生的原因。

那么，我們還需要一些方法來將測試的過程更加的精細(xì)化。在這里我采用了設(shè)置觀察點(diǎn)的方法，這種方法的機(jī)制是：盡量將頁面上可能的觸點(diǎn)羅列出來，而所有的觸點(diǎn)分為和任務(wù)主流程有關(guān)的觸點(diǎn)（A）和無關(guān)的觸點(diǎn)（B）。

在用戶完成任務(wù)時，我們需要觀察所有的觸點(diǎn)，此時對A類觸點(diǎn)的觀察可以覆蓋到所有和測試目標(biāo)有關(guān)的用戶行為，而對B類觸點(diǎn)的觀察可以覆蓋到系統(tǒng)里一些其他的可用性問題。

在用戶完成任務(wù)后的復(fù)盤過程中，我們需要就關(guān)鍵的，以及剛才出現(xiàn)問題的觸點(diǎn)與用戶進(jìn)行訪談，以便確認(rèn)問題發(fā)生的原因。這個方法的意義在于，在訪談的過程中，觀察者可以帶著目的和清晰地條例去觀察用戶行為，在之后的復(fù)盤中，可以更加系統(tǒng)的去還原用戶的行為，特別是那些通過直接觀察沒有辦法得出結(jié)論的點(diǎn)。

打個比方：如下圖所示：還是預(yù)訂酒店的例子。

我們的目標(biāo)是測試酒店搜索結(jié)果頁對于一個新用戶的的可用性，用戶任務(wù)是在該頁面找到一家價格適中，位置靠近老城，評價優(yōu)異，可供全家4人住宿的房間。

在酒店信息頁，可能的A類觀察點(diǎn)就包括了展示酒店信息的所有卡片；卡片內(nèi)的所有字段，鏈接，標(biāo)簽，圖標(biāo)，按鈕；篩選控件；排序控件；地圖入口；切換瀏覽方式的控件等?？赡艿腂類觀察點(diǎn)就包括了重新搜索的控件，該目的地其他日期的預(yù)定情況等。

在一場真實(shí)的可用性測試中，我們需要知道完成任務(wù)的所有路徑，以及最高效的那些路徑，而用戶很有可能會采用一些更低效的路徑，我們需要去觀察用戶是如何做出這樣的選擇的，并且在測試完成之后的復(fù)盤中，我們需要去向用戶了解是如何去認(rèn)知其他的路徑的。

比如在這個例子中，如果用戶想要高效的找到合適的住宿，他可能需要采用地圖視圖，價格篩選器，以及按照用戶評分對列表進(jìn)行排序。而在實(shí)際的操作中，用戶有可能不會用到這些組件，他們甚至可能會不對列表進(jìn)行任何操作就直接在列表中逐項(xiàng)瀏覽。那么在測試的過程中，我們就需要去留意用戶是怎樣選擇并使用了一個組件，在過程中是否有誤操作，猶豫等。

在測試完成后，需要去詢問用戶“請問你注意到列表上方的排序控件了嗎？”，“我注意到你剛才想要去點(diǎn)擊地圖，但是最后放棄了，這是為什么呢？”，“你有沒有想過需要將可以住4人的酒店篩選出來呢？你覺得你應(yīng)該怎樣去操作才能完成篩選呢？”等。

在完成了目標(biāo)，關(guān)鍵假設(shè)和觀察點(diǎn)的梳理后，我們就可以開始拿著我們的測試計劃開始準(zhǔn)備材料，數(shù)據(jù)，腳本以及用戶招募了。但是在走進(jìn)房間開始和用戶進(jìn)行近距離接觸之前，我通常會建議團(tuán)隊再做以下這件事情：對可用性測試的計劃本身進(jìn)行一次測試。一是為了保證測試過程的流暢，二是為了再次檢查我們的測試方案是否已經(jīng)足夠細(xì)致和全面了。

在這樣一個非正式的測試?yán)铮覀兺ǔ堃粋€同事（被試者對系統(tǒng)的熟悉程度需要根據(jù)測試目的來定），并嚴(yán)格按照正式測試的環(huán)境和流程進(jìn)行。

在這個流程中，我們可以看到準(zhǔn)備的材料和數(shù)據(jù)是否合理，能否覆蓋我們的測試目的；對于那些設(shè)計多平臺多設(shè)備多端口的任務(wù)，我們需要去保證數(shù)據(jù)和流程的流轉(zhuǎn)可以正常的進(jìn)行。在這樣的測試?yán)铮玫降年P(guān)于可用性的結(jié)論是沒有太大參考意義的，但是我們可以通過走完一個完整的流程對之前列出的觀察點(diǎn)進(jìn)行查漏補(bǔ)缺。

最后就是招募用戶的數(shù)量。根據(jù)Nielsen和Landauer的研究，可用性測試發(fā)現(xiàn)系統(tǒng)中問題數(shù)量與測試人數(shù)遵循以下公式：

P=N （1-（1- L ） n ）

其中P為發(fā)現(xiàn)問題的數(shù)量，N是系統(tǒng)中存在問題的總量，L是通過研究單個用戶可以發(fā)現(xiàn)的用戶比例，根據(jù)經(jīng)驗(yàn)L的值一般被定義為31%。

此時我們可以繪制出P關(guān)于n的曲線，如下左圖所示。

此外，Nielsen還給出了以下的一份數(shù)據(jù)：根據(jù)83例NNgroup最近進(jìn)行過的可用性咨詢的案例分析可以得出下右圖的可用性問題數(shù)量——招募用戶數(shù)量的關(guān)系。我們可以看到，在招募5-8名用戶的時候，就足以暴露出系統(tǒng)中的大部分可用性問題了。而此時再測試更多的用戶，并不會為我們的洞察帶來明顯的提升。

因此在我們的可用性測試中，我通常會遵循以下的原則——這也是其他定性用戶研究用戶招募的一個通用原則——至少對5名用戶進(jìn)行測試，當(dāng)測試完第五名用戶的時候，如果我們發(fā)現(xiàn)問題的分布足夠集中，或者是不再出現(xiàn)新的問題，那么針對這個目標(biāo)的可用性測試就可以結(jié)束了。如果此時還在暴露出新的問題，那么我們就還需要繼續(xù)進(jìn)行測試，直到不再暴露明顯的新問題為止。

測試的過程

關(guān)于測試的過程我就不在這里詳細(xì)描寫一次可用性測試所有的步驟了，下面列出幾個我認(rèn)為可以最大程度上提升研究質(zhì)量的點(diǎn)。

不要試圖去消滅測試的“人為因素”

一次典型的實(shí)驗(yàn)室環(huán)境的可用性測試包括了一把椅子，一張桌子，用戶坐在屏幕前完成任務(wù)，由錄像機(jī)和各種傳感器來追蹤所有發(fā)生的事情——包括眼動，面部表情，身體語言等等。這樣做的目標(biāo)就是試圖消滅掉試驗(yàn)中的一切實(shí)驗(yàn)因素。甚至有一些用研人員建議“不要和用戶說話”。

雖然我完全同意傾聽多于說話的觀點(diǎn)，但是——即使我完全保持沉默，甚至是躲在另外一個房間，用戶總是會知道他們是正在被觀察著的，我不用做任何事情，我的身份就是一個觀察者，這個時候適得其反的事情就發(fā)生了。

用戶會把我視作一個標(biāo)桿或者權(quán)威，他們會用他們的答案和行為來取悅我
因?yàn)樗麄儜峙略谖已壑酗@得愚蠢，因此他們會懼怕犯錯
他們的行為模式會和自然狀態(tài)下截然不同，他們會使用一些前所未有的方式去和我們的產(chǎn)品交互

我們需要意識到的是，可用性測試對于用戶來說本來就是一件不自然的事情——包括馬上我要說的Think Out Loud——就像洗澡的時候突然有人拉開浴簾問我水溫如何一樣。因此，我認(rèn)為消滅測試的“人為因素”是一件徒勞的事情，相反，我們應(yīng)該向前一步，去接受實(shí)驗(yàn)環(huán)境和現(xiàn)實(shí)不同的這個事實(shí)。

去扮演一個友好的角色，我習(xí)慣于在正式的測試開始之前和用戶有一個簡短的寒暄，講兩個適當(dāng)?shù)亩巫?，一些和用戶貼近的小問題，注意自己的語氣和身體語言——事實(shí)上，這樣的開場適合于所有的定性研究。

總之，創(chuàng)造一個輕松的氛圍，讓自己看上去親和友好，向用戶傳達(dá)我們是多么高興他可以幫助我們發(fā)現(xiàn)系統(tǒng)的問題。當(dāng)用戶愿意走出他的舒適區(qū)時，我們就可以得到更多有價值的信息了。

Think Out Loud&測試后的復(fù)盤

測試的目的之一是挖掘出更多的信息，而用戶的操作只能展示出測試時所發(fā)生的事情的很小一部分，除了仔細(xì)的觀察之外，我們會要求用戶在使用時將自己的思考/決策過程說出來，包括

當(dāng)進(jìn)入這個頁面的時候，我首先注意到了哪些東西？
我認(rèn)為這個頁面是做什么用的
我下一步想做什么？我覺得頁面上哪些元素可以幫助我？
當(dāng)我完成某一操作后，我預(yù)期會有怎樣的反饋？那真實(shí)的反饋是怎樣的？
界面上有哪些元素是我不明白的？
我進(jìn)行了誤操作，我應(yīng)該怎么消除這個錯誤？

……

這樣，我們就可以保證我們設(shè)置的觀察點(diǎn)得到了充分的覆蓋，并且可以幫助我們對界面以及產(chǎn)品結(jié)構(gòu)進(jìn)行更全面的洞察。當(dāng)然，Think Out Loud是建立在第一條的基礎(chǔ)上的，只有當(dāng)用戶在一個足夠放松和信任的狀態(tài)下，他才會保持一個說話的狀態(tài)。

在用戶完成任務(wù)之后，我們已經(jīng)收集到了足夠多的信息，但是如何保證信息的精確性呢？我使用的方法是進(jìn)行一次復(fù)盤。我們需要回顧用戶剛才的路徑和所有操作，去確認(rèn)每一個決定的原因，以及用戶沒有說出來的東西，比如：

你為什么要點(diǎn)擊多次撤銷，而不去點(diǎn)擊清空按鈕呢？
我注意到你將鼠標(biāo)移到了A按鈕上，但是最后又沒有點(diǎn)擊呢？
我注意到你在進(jìn)行B操作的時候顯得有些焦躁，這是為什么呢？
……

保證信息的完整和精確，我們就可以告訴用戶說今天你的測試已近完成了。

對測試方案的迭代

如果我說“我需要在研究的過程中修改我的研究方案”，很多研究者心中的第一反應(yīng)多半是WTF？我理解很多人將中途修改方案視為洪水猛獸，因?yàn)檫@和“得到一個客觀的結(jié)論”的目的似乎是相悖的。他們說你需要5名用戶去做一模一樣的任務(wù)，這樣才能得到一個有意義的結(jié)論。

我當(dāng)然同意要想辦法得到更客觀的答案，但是這并不意味著我們的研究方案就自始至終一成不變的了。我們應(yīng)該在保證目標(biāo)和關(guān)鍵假設(shè)不變的前提下，在每一次測試之后，對我們的觀察點(diǎn)以及復(fù)盤時的問題進(jìn)行迭代——這個習(xí)慣同樣適用于其他的定性用戶研究方法——因?yàn)槲覀兊挠^察點(diǎn)和問題的擬定都建立在我們對系統(tǒng)了解的基礎(chǔ)上，但是有的時候，用戶和我們設(shè)計的體驗(yàn)是兩回事情，曾經(jīng)有同事反饋說，自己設(shè)置的觀察點(diǎn)很多都沒有用上，而用戶的很多行為完全出乎了他的意料。

打個比方，如果前兩個用戶在任務(wù)的最開始都統(tǒng)統(tǒng)選擇了一條我們預(yù)料之外的路徑，而我們都沒有在這條路徑上設(shè)置任何的觀察點(diǎn)與問題。那么，如果我們不在后續(xù)的研究上加上“你為什么會點(diǎn)擊這個入口”這樣的問題，那么我們永遠(yuǎn)也不會知道用戶這樣奇怪舉動背后的原因。