紙?jiān)蜏y試來源：mediamatic.nl

可用性測試方法

產(chǎn)品可用性測試方法分為分析法和實(shí)驗(yàn)法。

1. 分析法

讓產(chǎn)品可用性工程師及用戶界面設(shè)計(jì)師等專家，基于自身專業(yè)知識和經(jīng)驗(yàn)進(jìn)行評價(jià)的一種方法。

特點(diǎn)：主觀、評價(jià)結(jié)果是假設(shè)的、時(shí)間少、費(fèi)用少、評價(jià)范圍廣、設(shè)計(jì)初期也可以評價(jià)。

分析法常用于可用性檢查階段，常見的分析法包括但不限于：

專家評審：評審由精通設(shè)計(jì)可用性概念的專家進(jìn)行，基于自身專業(yè)知識與經(jīng)驗(yàn)對產(chǎn)品進(jìn)行審查。

啟發(fā)式評估：讓可用性專家判斷每個(gè)頁面及元素是否遵循已確立的可用性原則。

認(rèn)知走查：設(shè)計(jì)師模擬用戶在使用產(chǎn)品過程中的每個(gè)操作步驟所遇到的問題，檢查用戶的任務(wù)目標(biāo)和心理認(rèn)知是否可以順利執(zhí)行下一步操作？

針對每步操作提出四個(gè)問題：

1. 用戶是否知道自己要做什么？

2. 用戶在探索用戶界面的過程中是否注意到操作方法？

3. 用戶是否把自己的目的和正確的操作方法關(guān)聯(lián)到一起？

4. 用戶能否從系統(tǒng)的反饋中判斷出任務(wù)是否在順利進(jìn)行？

通過回答每個(gè)操作步驟的問題，就能發(fā)現(xiàn)可用性問題。

多元走查：認(rèn)知走查的變體，使用小組會(huì)議，其中用戶、開發(fā)人員和人為因素讓人們在場景中逐步討論操作流程中的每個(gè)交互頁面及元素。

一致性檢查：讓代表多個(gè)其他項(xiàng)目的設(shè)計(jì)人員檢查界面，以查看它是否以與他們自己的設(shè)計(jì)相同的方式進(jìn)行操作。

2. 實(shí)驗(yàn)法

收集真實(shí)的用戶使用數(shù)據(jù)，比較典型的是用戶測試法，問卷調(diào)查等方法也屬于此類。

特點(diǎn)：客觀、評價(jià)結(jié)果是事實(shí)、時(shí)間長、花費(fèi)大、評價(jià)范圍較窄、為了做評價(jià)，必須準(zhǔn)備原型。

實(shí)驗(yàn)法常用于可用性測試階段（用戶測試階段），常見的實(shí)驗(yàn)法包括但不限于：

• 卡片分類：通常用于測試分類或?qū)Ш浇Y(jié)構(gòu)，讓用戶將一組寫有信息的卡片分組，并為其分配名稱或標(biāo)簽?？ㄆ诸愑兄诹私庥脩羧绾慰创齼?nèi)容以及他們?nèi)绾谓M織信息，從而決定在每個(gè)頁面放置什么，對于頁面或功能分類很有幫助。

• 面對面測試：由一個(gè)或多個(gè)觀察者在諸如會(huì)議室的固定環(huán)境中運(yùn)行，或者與小團(tuán)體或個(gè)人進(jìn)行。要求用戶完成一組任務(wù)，觀察者可以隨時(shí)與他們交互以提出問題或進(jìn)一步探究。

• 遠(yuǎn)程測試：在遠(yuǎn)程測試中，用戶在自己的環(huán)境中執(zhí)行一系列任務(wù)，通過軟件記錄完成任務(wù)的過程，軟件自動(dòng)記錄用戶的點(diǎn)擊位置和交互過程，并記錄他們在使用網(wǎng)站或應(yīng)用程序時(shí)發(fā)生的關(guān)鍵事件以及用戶提交的反饋。這種類型的測試可以由主持人（使用網(wǎng)絡(luò)研討會(huì)或電話會(huì)議技術(shù)）完成，也可以作為自我測試。

• A / B測試：為網(wǎng)站或應(yīng)用程序的界面或流程制作兩個(gè)（A/B）或多個(gè)（A/B/n）版本，在同一時(shí)間維度，分別讓組成成分相同（相似）的訪客群組隨機(jī)的訪問這些版本，收集各群組的用戶體驗(yàn)數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，最后分析評估出最好版本正式采用。

• 走廊測試：使用隨機(jī)的人來測試網(wǎng)站，而不是那些在測試網(wǎng)站方面訓(xùn)練有素和經(jīng)驗(yàn)豐富的人。這種方法對于在開發(fā)過程中首次測試新網(wǎng)站特別有效。

• 紙張?jiān)蜏y試：創(chuàng)建一個(gè)粗糙的，甚至是手繪的界面圖形以用作設(shè)計(jì)的原型。讓用戶通過原型來執(zhí)行任務(wù)，該方法能以極低的成本在編碼完成之前對設(shè)計(jì)進(jìn)行測試。

• 問卷調(diào)查：問卷的優(yōu)勢在于可以收集結(jié)構(gòu)化的數(shù)據(jù)，且價(jià)格低廉，不需要檢測設(shè)備，結(jié)果反映了用戶的意見。

分析法與實(shí)驗(yàn)法的主要區(qū)別在于：是否有用戶參與其中？

分析法的參與者是具備可用性知識的設(shè)計(jì)師與工程師；而實(shí)驗(yàn)法的參與者是目標(biāo)用戶或小白用戶。從某種程度而言，分析法和實(shí)驗(yàn)法是一種互補(bǔ)的關(guān)系。

一般，在設(shè)計(jì)用戶測試時(shí)，先在可用性檢查階段通過分析法去排查可用性問題，把排查出的問題按重要程度排序，然后在可用性測試階段通過用戶測試去重點(diǎn)觀察和驗(yàn)證。

分析法的最大缺點(diǎn)是：它得到只是分析者的假設(shè)或觀點(diǎn)，在團(tuán)隊(duì)意見不一致時(shí)，并不能夠提出支持自己意見的有力證據(jù)。為了結(jié)束爭論，就只能通過實(shí)驗(yàn)法。

接下來重點(diǎn)介紹分析法中的啟發(fā)式評估法與實(shí)驗(yàn)法中的一對一用戶測試。

可用性測試實(shí)驗(yàn)室 來源：u-sentric.com

啟發(fā)式評估

1. 啟發(fā)式評估簡介

因?yàn)閷＜以u審過度依賴于自身的專業(yè)知識與經(jīng)驗(yàn)，為了得到一個(gè)更客觀的結(jié)果，Jakob Nielsen根據(jù)多年可用性工程的經(jīng)驗(yàn)創(chuàng)造了啟發(fā)式評估法。

啟發(fā)式評估使專家按照公認(rèn)的可用性原則，來審查用戶界面中的可用性問題，然后通過一系列原則對它們進(jìn)行分類和評分。Jakob Nielsen的十種啟發(fā)式評估原則（尼爾森十大交互定律）是行業(yè)中最常用的可用性評估原則。

除此之外，還有Gerhardt-Powals的認(rèn)知工程原理、Weinschenk和 Barker的分類、ISO 9421 對話原則等。

2. 啟發(fā)式評估原則

Jakob Nielsen倡導(dǎo)的啟發(fā)式評估十原則內(nèi)容如下：

1. 系統(tǒng)狀態(tài)的可見性：系統(tǒng)應(yīng)該在合理的時(shí)間內(nèi)做出適當(dāng)?shù)姆答?，始終讓用戶了解正在發(fā)生的事情。

2. 系統(tǒng)與現(xiàn)實(shí)世界的匹配：系統(tǒng)應(yīng)使用用戶的語言，用戶熟悉的詞語和概念，而不是系統(tǒng)導(dǎo)向的專業(yè)術(shù)語。遵循現(xiàn)實(shí)世界的慣例，使信息以自然和合乎邏輯的順序出現(xiàn)。

3. 用戶控制和自由：用戶有時(shí)會(huì)誤操作，要提供任何時(shí)候都能從當(dāng)前狀態(tài)跳出來的出口，保證能夠及時(shí)取消或者再運(yùn)行執(zhí)行過的操作（支持撤消和重做）。

4. 一致性和標(biāo)準(zhǔn)化：不應(yīng)讓用戶懷疑不同的詞語、情況或行為是否意味著同一件事。保證用戶在同樣的操作下得到相同的結(jié)果。

5. 預(yù)防錯(cuò)誤：提前預(yù)防錯(cuò)誤的發(fā)生，這種防患于未然的設(shè)計(jì)要比適當(dāng)?shù)腻e(cuò)誤提示更勝一籌。消除容易出錯(cuò)的條件或檢查它們，并在用戶采取行動(dòng)之前讓用戶再次確認(rèn)是否進(jìn)行該操作。

6. 識別而不是回憶： 通過使對象，動(dòng)作和選項(xiàng)等可視化，從而最大限度地減少用戶的認(rèn)知負(fù)擔(dān)，使用戶無需回憶，一看就懂。盡量不要讓用戶從當(dāng)前對話切換到別的對話時(shí)還必須記住某些信息，系統(tǒng)的使用說明應(yīng)該是可見的，或者適當(dāng)時(shí)可以輕易地檢索。

7. 靈活性和效率：加速器功能（初次接觸的用戶看不到該功能）通常可以提升專家用戶的操作效率，從而使系統(tǒng)能夠迎合無經(jīng)驗(yàn)和有經(jīng)驗(yàn)的用戶，允許用戶能夠單獨(dú)調(diào)整會(huì)頻繁使用的操作。

8. 審美和極簡主義設(shè)計(jì)：對話不應(yīng)包含無關(guān)或極少需要的信息，對話中的每條附加信息都會(huì)與關(guān)鍵信息形成競爭，并降低其相對可見度。

9. 幫助用戶識別，診斷和從錯(cuò)誤中恢復(fù)：錯(cuò)誤消息應(yīng)以簡單的語言表示，精確地表明問題，并建設(shè)性地提出解決方案。

10. 幫助和文檔：即使系統(tǒng)在沒有幫助文檔的情況下也可以使用良好，但還是有必要提供幫助和文檔。這樣的信息應(yīng)該易于搜索，針對用戶要執(zhí)行任務(wù)列出具體步驟。

3. 啟發(fā)式評估法的實(shí)施步驟

STEP 1：招募評價(jià)人員

Jakob Nielsen認(rèn)為：一個(gè)人評價(jià)大約只能發(fā)現(xiàn)35%的問題，因此大概需要3~5人才能得到穩(wěn)妥的結(jié)果，能夠勝任啟發(fā)式評估職位的人可以是用戶體驗(yàn)設(shè)計(jì)師、交互設(shè)計(jì)師、UI設(shè)計(jì)師等。界面的原設(shè)計(jì)師是不適合評價(jià)界面的，因?yàn)樵u價(jià)結(jié)果可能會(huì)不夠客觀抑或是發(fā)現(xiàn)問題直接就進(jìn)行修改而不會(huì)反饋。

STEP 2：制定評價(jià)計(jì)劃

評價(jià)產(chǎn)品的所有功能是比較困難的，所以要事先定好要評價(jià)界面的哪些部分，以及依據(jù)哪些原則進(jìn)行評價(jià)（Gerhardt-Powals的認(rèn)知工程原理、Weinschenk和 Barker的分類、ISO 9421 對話原則等）。

STEP 3：實(shí)施評價(jià)

最好對界面進(jìn)行兩次評價(jià)：第一次檢查界面的流程是否正常，第二次詳細(xì)檢查各界面是否存在問題。評價(jià)人員之間應(yīng)禁止相互討論，以避免評價(jià)結(jié)果被權(quán)威人士所影響。

STEP 4：召開評價(jià)人員會(huì)議

評價(jià)人員完成了各自的評價(jià)后，要集中開會(huì)以匯報(bào)評價(jià)結(jié)果，會(huì)議上描述問題的同時(shí)將界面顯示出來會(huì)更有效率。

啟發(fā)式評估的優(yōu)點(diǎn)是：通過單獨(dú)評價(jià)和評價(jià)人員之間的討論這二次過濾，可以發(fā)現(xiàn)單獨(dú)一人不能發(fā)現(xiàn)的跨度較大的問題。

STEP 5：總結(jié)評價(jià)結(jié)果

匯總所有的評價(jià)結(jié)果后，就可以整合評價(jià)的問題列表了，可能會(huì)有一個(gè)問題存在多種表達(dá)方式，所以需要對問題列表進(jìn)行適當(dāng)?shù)恼怼?/p>

STEP6：輸出總結(jié)性報(bào)告

啟發(fā)式評估法的輸出成果就是產(chǎn)品可用性問題列表，但如果只給出列表，其他成員理解可能會(huì)比較困難，因此最好配上界面截圖、流程圖等輸出一份簡介的啟發(fā)式評估報(bào)告。

啟發(fā)式評估報(bào)告（HE報(bào)告）的內(nèi)容主要包括：

1. 出現(xiàn)問題的界面和位置，關(guān)鍵事件或問題出現(xiàn)在用戶界面的哪個(gè)位置？

2. 啟發(fā)式的名稱，引用了十個(gè)啟發(fā)式原則中的哪一個(gè)？

3. 被評價(jià)為否定或肯定的原因，解釋為什么界面會(huì)違反或符合該啟發(fā)式？

4. 問題的范圍，描述問題的范圍，是貫穿整個(gè)產(chǎn)品還是在某個(gè)界面？

5. 問題的嚴(yán)重程度(高/中/低），評估問題的嚴(yán)重程度。

6. 評定其嚴(yán)重程度的理由，給它高/中/低的原因。

7. 修復(fù)建議，對問題的改進(jìn)建議。

8. 可能的權(quán)衡（為什么修復(fù)可能會(huì)不起作用），提及這些權(quán)衡可以增加報(bào)告的可信度。
   

啟發(fā)式評估問題列表的示例

4. 啟發(fā)式評估法的局限性

平心而論，啟發(fā)式方法是打算作為一種幫助新手從業(yè)者進(jìn)行可用性檢驗(yàn)的“腳手架”，因此它無論如何都無法與專家可用性檢驗(yàn)方法相提并論。而且，只有專家才能通過可檢驗(yàn)方法發(fā)現(xiàn)問題，而不是使用啟發(fā)式方法的都是專家。

啟發(fā)式評估法是由多位專家基于自身經(jīng)驗(yàn)和啟發(fā)式原則，對用戶界面進(jìn)行的評判，因此勢必會(huì)發(fā)現(xiàn)很多問題。而且實(shí)施啟發(fā)式評估法需要多名專家在限定的幾天內(nèi)進(jìn)行作業(yè)，所需成本也較高。

所以應(yīng)結(jié)合實(shí)際情況對啟發(fā)式評估做簡化，可以只由一兩名專家進(jìn)行簡單審查，這種做法被成為啟發(fā)法。不過在不提供客觀的判斷標(biāo)準(zhǔn)，且檢驗(yàn)人員數(shù)量又少的情況下，評估結(jié)果可能會(huì)被指責(zé)“這些問題只是檢驗(yàn)人員的主觀想法而已”。

因?yàn)橘Y源有限而導(dǎo)致不能進(jìn)行正規(guī)的啟發(fā)式評估，而改為簡易的審查時(shí)，要注意：

1. 不應(yīng)以個(gè)人偏好，而應(yīng)以理論依據(jù)進(jìn)行評價(jià)。

2. 評價(jià)的目的不是挑錯(cuò)，更應(yīng)給出合理建議。

3. 當(dāng)團(tuán)隊(duì)意見不一致時(shí)，與其爭論不如通過實(shí)驗(yàn)得出結(jié)論。
   

   用戶測試方法 來源：rainforestqa.com

   用戶測試

   1. 用戶測試簡介

   用戶測試，可用性工程師與用戶進(jìn)行一對一訪談（理想情況下，觀察者與使用者彼此不認(rèn)識，以便收集更多客觀數(shù)據(jù)），其他成員在監(jiān)聽室觀察整個(gè)訪談，而且用戶操作計(jì)算機(jī)時(shí)的界面和聲音，全程都被錄像。

   可用性測試的基本內(nèi)容是相同的：為用戶構(gòu)建一個(gè)場景，讓用戶通過產(chǎn)品完成特定任務(wù)，在用戶執(zhí)行任務(wù)的過程中觀察他們遇到的問題。

   2. 用戶測試的常見方法

   （1）發(fā)聲思考法

   發(fā)聲思考法就是讓用戶一邊說出心里想的內(nèi)容一邊操作，操作過程中用戶能夠說出“我覺得下面應(yīng)該這樣操作…”。這樣我們就能夠把握用戶關(guān)注的是哪個(gè)部分、他是怎么想的、又采取了怎樣的操作等信息，這是一種能夠弄清楚為什么會(huì)導(dǎo)致不好結(jié)果的非常有效的評估方法。

   發(fā)聲思考法觀察的重點(diǎn)：

   • 用戶是否獨(dú)立完成了任務(wù)？若不能獨(dú)立完成任務(wù)，頁面存在有效性問題。

   • 用戶達(dá)到目的的過程中，是否做了無效操作或不知所措？如果有，頁面存在效率問題。

   • 用戶是否有不滿的情緒？如果有則頁面存在滿意度問題。

    

   （2）回顧法

   讓用戶操作完后回答問題的方法。

   回顧法的限制：

   • 很難回顧復(fù)雜的情況。

   • 用戶會(huì)在事后為自己的行為找借口。

   • 回顧發(fā)比較耗時(shí)。

    

   （3）性能測試

   性能測試一般會(huì)安排在項(xiàng)目前后實(shí)施，目的是設(shè)置目標(biāo)數(shù)值、把握目標(biāo)的完成程度和改善程度。

   測試主要針對產(chǎn)品可用性三要素（有效性、效率、滿意度）的相關(guān)數(shù)據(jù)進(jìn)行定量測試：

   1. 有效性可以用任務(wù)完成率來表示：有幾成的用戶可以獨(dú)立完成任務(wù)是檢驗(yàn)里最重要的一個(gè)性能指標(biāo)，這里的任務(wù)完成指用戶正確的完成了任務(wù)。

   2. 效率可以用任務(wù)完成時(shí)間來表示：界面時(shí)為了讓用戶完成任務(wù)而設(shè)計(jì)的，因此能夠在最短時(shí)間內(nèi)讓用戶完成任務(wù)的界面才是優(yōu)秀的界面，所以需要檢測用戶完成任務(wù)所花的時(shí)間。最好限制每個(gè)任務(wù)的時(shí)間，在限定時(shí)間內(nèi)未能完成任務(wù)，就被當(dāng)做任務(wù)未完成。

   3. 滿意度可以用主觀評價(jià)來表示：任務(wù)完成后，可以就“難易程度”、“好感”、“是否有再次使用的意向”等問題向用戶提問，并設(shè)置5~10個(gè)等級讓用戶選擇。

    

   測試方法：發(fā)聲法和回顧法這樣的用戶測試都是一對一的形式，但性能測試是定量測試，參與測試的人太少可信度太低，也不能用來說明問題。因此經(jīng)常以集體測試的形式進(jìn)行，每1~2名用戶配備一位監(jiān)督者，制定測試內(nèi)容、確認(rèn)完成任務(wù)、檢測任務(wù)完成時(shí)間等。

   數(shù)據(jù)統(tǒng)計(jì)處理較多的心理學(xué)實(shí)驗(yàn)里，一般至少會(huì)收集20~30人的數(shù)據(jù)。而且所謂20人是目標(biāo)用戶的人數(shù)，因此整體而言需要40~60人。

   原則上講，一次性能測試會(huì)測試多個(gè)用戶界面。如果只測試一個(gè)用戶界面，那么即時(shí)最終得到了任務(wù)完成率和平均時(shí)間，這些數(shù)值的好壞也沒有一個(gè)標(biāo)準(zhǔn)。通過對比競爭產(chǎn)品，比較多套方案，或者對比改版前后的數(shù)據(jù)，就能進(jìn)行客觀評價(jià)了。（在讓每個(gè)用戶使用多個(gè)界面時(shí)，使用順序應(yīng)該不相同，這可以避免使用順序帶來的影響。）

   性能測試的限制：當(dāng)任務(wù)完成率只有20%時(shí)，團(tuán)隊(duì)只知道這個(gè)任務(wù)的執(zhí)行效率很低，但不知道用戶究竟是為什么沒能完成任務(wù)，因此會(huì)感覺無所適從。

   發(fā)聲思考法可以解決這個(gè)問題，但實(shí)際操作過程中，只要采訪人員不提問，用戶就不會(huì)主動(dòng)說話。如果提問的話，用戶又可能就會(huì)停下手上的動(dòng)作進(jìn)行說明，這樣一來測試完成任務(wù)的時(shí)間就沒意義了。

   缺少發(fā)生思考的性能測試沒有任何意義，但如果同時(shí)實(shí)施這兩種方法，又需要很大預(yù)算。所以只要還未明確定量數(shù)據(jù)的必要性，就不應(yīng)實(shí)施性能測試。我們沒必要把有限的資源浪費(fèi)在定量數(shù)據(jù)的測試上。相反，反復(fù)進(jìn)行的發(fā)生思考法這種只需幾個(gè)人參加的測試，可以更好的改善界面。

   3. 用戶測試的實(shí)施步驟

   STEP 1：設(shè)計(jì)任務(wù)

   可用性評估是基于任務(wù)的，任務(wù)設(shè)計(jì)的優(yōu)劣能直接影響測試結(jié)果的準(zhǔn)確性。所以在招募用戶前，應(yīng)先針對產(chǎn)品設(shè)計(jì)任務(wù)。比如：一個(gè)購物類APP設(shè)定的任務(wù)可以是：購買一件價(jià)格高于100元的T恤。

   想要設(shè)計(jì)出合適的任務(wù)須注意以下幾點(diǎn)：

   （1）選擇最核心的功能或操作流程作為任務(wù)

   一個(gè)產(chǎn)品可以執(zhí)行很多任務(wù)，不可能把所有任務(wù)都執(zhí)行一次。所以應(yīng)采用精益思維，把有限的資源放在最有價(jià)值的環(huán)節(jié)上，產(chǎn)品最核心的功能或操作流程往往是最頻繁被用戶使用的地方。

   如果這里還存在可用性問題，那么就算改善了其他邊緣地帶的可用性問題，依然對產(chǎn)品整體體驗(yàn)于事無補(bǔ)，所以設(shè)計(jì)的任務(wù)要以核心功能和操作流程為主。

   （2）任務(wù)應(yīng)符合常規(guī)操作流程

   有時(shí)設(shè)計(jì)者會(huì)把自己想要用戶做的事當(dāng)任務(wù)來測試，但實(shí)際用戶并不是按設(shè)計(jì)者想的流程去完成任務(wù)的。而且由于測試的任務(wù)較多，設(shè)計(jì)者為省事有時(shí)會(huì)把多個(gè)小任務(wù)合并為一個(gè)大任務(wù)，這樣做有時(shí)是可以的，但如果小任務(wù)之間的操作流程存在沖突，用戶測試的操作流程就是不合乎常規(guī)的。

   也就是說，用戶實(shí)際在執(zhí)行的任務(wù)在正常使用產(chǎn)品的時(shí)候，根本不會(huì)出現(xiàn)或極少出現(xiàn)，這樣的測試的結(jié)果準(zhǔn)確性令人堪憂，且還會(huì)給參與測試的用戶造成困惑。

   （3）為任務(wù)創(chuàng)建一個(gè)應(yīng)用場景

   簡短的場景描述會(huì)會(huì)對用戶執(zhí)行任務(wù)有所幫助。比如：任務(wù)是“購買一件價(jià)格高于100元的T恤”，我們可以創(chuàng)建這樣一個(gè)場景——你的同事過生日了，你想挑一件一百多塊的T恤給他，請使用XX APP來完成T恤的購買。

   這樣給了用戶一個(gè)執(zhí)行任務(wù)的理由和目的，不會(huì)使任務(wù)變得突兀，而且用戶也會(huì)變得有代入感從而更好的理解并執(zhí)行任務(wù)。注意場景描述里不要涉及用戶的直系親屬，沒人知道他們的經(jīng)歷，以免引起用戶的情緒反應(yīng)。

   （4）明確任務(wù)的起點(diǎn)和終點(diǎn)

   判斷用戶是否完成了任務(wù)的主要依據(jù)就是：用戶是否從起點(diǎn)（頁面A）到達(dá)了終點(diǎn)（頁面B）。

   所以要清晰的定義，哪個(gè)頁面是起點(diǎn)？哪個(gè)頁面是終點(diǎn)？起點(diǎn)未必一定要是首頁，起點(diǎn)位置應(yīng)根據(jù)具體場景來確定，畢竟并不是每個(gè)任務(wù)都是從首頁開始的。比如：任務(wù)是“購買一件價(jià)格高于100元的T恤”，那么起點(diǎn)頁面可以是APP的首頁，終點(diǎn)頁面就是付款成功頁面。

   不過除了檢查是否到達(dá)終點(diǎn)，可能還要檢查一些關(guān)鍵信息，比如：用戶購買的T恤價(jià)格是否高于100元、用戶是否正確填寫了地址等。如果沒有，那么我們要搞清楚原因是什么？

   （5）任務(wù)不應(yīng)過于簡單

   如果想測試用戶是否可以找到某功能，不要用類似“找到XX功能按鈕”這樣的描述，我們應(yīng)該給用戶提供一個(gè)要處理的現(xiàn)實(shí)任務(wù)，而不只是定位功能的位置。“找到退款功能按鈕”應(yīng)改為“購買一件T恤并退款。”

   （6）避免提供線索和描述操作步驟

   任務(wù)應(yīng)給出具體目標(biāo)，而不是操作步驟。

   以買T恤的任務(wù)為例：如果告訴用戶“搜索T恤，然后選擇數(shù)量和顏色，填寫地址并確認(rèn)訂單，最后進(jìn)行支付”，那么用戶在執(zhí)行任務(wù)時(shí)的思路可能是這樣的：找T恤、找數(shù)量選擇按鈕、找顏色選擇按鈕、找填寫地址的位置、找訂單確認(rèn)按鈕、找支付按鈕，一個(gè)完整的核心任務(wù)就這樣被拆分成了多個(gè)確認(rèn)功能按鈕位置的操作，引導(dǎo)性過強(qiáng)的任務(wù)失去了測試的意義。

   這樣做會(huì)錯(cuò)過用戶在任務(wù)中，執(zhí)行到某一步驟時(shí)可能提供的寶貴反饋。因?yàn)橛脩粢婚_始可能并不知道會(huì)有這些操作步驟，可能會(huì)因一些額外的操作感到驚訝或煩惱。而且用戶在實(shí)際使用產(chǎn)品時(shí)，考慮的是使用目標(biāo)，而不是具體的操作和功能。

   因此，一定要避免提供線索和操作步驟給用戶。

   STEP 2：招募用戶

   （1）要根據(jù)資金預(yù)算和日程安排來招募用戶，并給予他們一些報(bào)酬（小禮物即可）

   招募對象的選擇理論上應(yīng)該是產(chǎn)品的典型目標(biāo)用戶，但是仍然需要定義具體的用戶特征——即招募條件。

   招募條件可以從早期市場調(diào)研階段中建立的用戶畫像中提取用戶特征，要盡可能的代表將來的真實(shí)用戶。如果目標(biāo)用戶畫像分為幾類，那就要求招募的用戶中要包括所有類型的用戶。

   被招募的用戶應(yīng)具備使用產(chǎn)品執(zhí)行任務(wù)的能力，比如：我們一定不會(huì)找電腦都不太會(huì)使用的人來體驗(yàn)桌面軟件。

   通常我會(huì)找兩類用戶來體驗(yàn)產(chǎn)品：

   • 一類是有同類型產(chǎn)品使用經(jīng)驗(yàn)的用戶；

   • 另一類是完全沒使用過類似產(chǎn)品的用戶。

   因?yàn)槲业漠a(chǎn)品目標(biāo)是降低同類產(chǎn)品的操作復(fù)雜度，讓小白用戶也能輕易上手，通過這兩種用戶可能會(huì)發(fā)現(xiàn)截然不同的問題。

   （2）接下來要確認(rèn)所要招募的用戶數(shù)量

   Jakob Nielsen提出過一個(gè)法則：有5人參加的用戶測試，即可發(fā)現(xiàn)大多數(shù)（85%）的產(chǎn)品可用性問題，而且通常最嚴(yán)重的問題都是前幾名用戶發(fā)現(xiàn)的，隨著用戶數(shù)量的增多，發(fā)現(xiàn)的問題逐漸減少，被發(fā)現(xiàn)的問題數(shù)量與測試用戶的數(shù)量的關(guān)系如下圖所示。

    

   但它也存在一些局限性，比如：它只能說明發(fā)現(xiàn)的問題的數(shù)量，但不能確認(rèn)所發(fā)現(xiàn)問題的嚴(yán)重程度（還有很多局限性在此不一一列舉）。所以我們要根據(jù)我們的實(shí)際情況，來確定要招募的用戶的數(shù)量，查看每次測試的結(jié)果與迭代效果，看看是否值得投入更多資源來做可用性測試。

Resource: Nielsen Norman Group

（3）關(guān)于招募渠道

如果時(shí)間精力充裕，可以從網(wǎng)絡(luò)問卷和在市場調(diào)研階段的渠道，邀請外部用戶進(jìn)行測試。反之，則可以充分利用身邊的資源——同事和朋友，但不要找項(xiàng)目組內(nèi)部的成員，因?yàn)樗麄儗Ξa(chǎn)品過于了解，會(huì)影響測試結(jié)果的有效性。

STEP 3 ：準(zhǔn)備工作

（1）測試地點(diǎn)與工具的準(zhǔn)備

專業(yè)的用戶測試一般在實(shí)驗(yàn)室內(nèi)進(jìn)行，實(shí)驗(yàn)室有觀察室與操作室，測試人員與用戶在操作室進(jìn)行可用性測試，其他團(tuán)隊(duì)成員在觀察室中觀察，兩個(gè)房間之間通常由單面鏡隔開。

操作室內(nèi)無法看到觀察室的情況，而觀察室能看到操作室的情況。通常觀察室中還需要配備電腦或投影儀，實(shí)時(shí)顯示操作室中正在被用戶操作的用戶界面。但絕大多數(shù)公司往往不具備這樣的條件的實(shí)驗(yàn)，這時(shí)我們找一間安靜的會(huì)議室就可以了。

測試人員與用戶在會(huì)議室進(jìn)行測試，如果是PC端軟件的測試，可在PC預(yù)安裝錄播或直播軟件，便于其他成員觀看用戶操作的流程與表情。如果是手機(jī)端軟件的測試，可以直接使用同屏功能，團(tuán)隊(duì)其他成員直接在另外的PC上觀看用戶的操作即可。

推薦使用能同時(shí)錄制屏幕和用戶表情具備畫中畫功能的軟件，因?yàn)橛^察用戶屏幕幫助我們了解用戶做了什么，觀察用戶表情可以了解用戶的情緒（困惑、惱怒等）。

總之，方法和工具有很多，只要不影響用戶測試并便于團(tuán)隊(duì)成員觀察即可。

（2）任務(wù)相關(guān)資料的準(zhǔn)備

要準(zhǔn)備任務(wù)提示卡，一張用于記錄用戶要完成的任務(wù)的卡片，有些任務(wù)可能比較復(fù)雜，這樣可以更準(zhǔn)確的傳達(dá)任務(wù)信息，且便于用戶主動(dòng)查看。

還要為自己準(zhǔn)備一份數(shù)據(jù)收集表格，用于收集任務(wù)相關(guān)數(shù)據(jù)，如任務(wù)是否完成、完成時(shí)間等，還要有用于記錄關(guān)鍵事件和在測試過程中觀察到的用戶體驗(yàn)問題的表格，比如：設(shè)計(jì)可能存在的問題及原因等。

（3）相關(guān)文件的準(zhǔn)備

更專業(yè)的用戶可用性測試，會(huì)與用戶簽署一些協(xié)議。

比如：

1. 用戶知情同意書，用于聲明用戶是自愿參加評估的并允許我們獲取和使用數(shù)據(jù)。

2. 可用性測試說明文件，簡單概述測試目的與對用戶的期望以及用戶要遵守的規(guī)則等。

3. 保密協(xié)議，防止用戶泄露產(chǎn)品信息。

4. 問卷與調(diào)查，充分了解用戶的背景。

有的測試可能還會(huì)用到培訓(xùn)資料，比如：某些復(fù)雜的智能硬件，可能需要用戶先閱讀說明書后再執(zhí)行任務(wù)，諸如此類在此不過多闡述。

（4）可用性測試劇本的準(zhǔn)備

可用性測試劇本指我們從接觸用戶、開場白、開始測試、事后訪談、給予獎(jiǎng)勵(lì)并送走用戶的整個(gè)過程中要執(zhí)行的行為與臺詞的集合，測試人員通過執(zhí)行劇本中的內(nèi)容來推動(dòng)可用性測試的進(jìn)行。（別忘了準(zhǔn)備報(bào)酬）

4. 可用性劇本示例

• 評測對象：XX購物APP。

• 招募條件：一二線城市90后，有在線購物的經(jīng)歷。

• 參與者人數(shù)：5名。

• 測試時(shí)間：60分鐘。

• 酬勞：咖啡一盒。

（1）開場白（3分鐘），說明訪談目的和基本流程，簽訂錄像許可與保密協(xié)議等文件

常用話術(shù)：您好，我是XX購物APP的可用性工程師，很高興見到您。今天由我來和您做這次測試，這次測試的目的是測試我們的產(chǎn)品是否便于用戶使用，接下來會(huì)拜托您通過APP執(zhí)行幾個(gè)任務(wù)，執(zhí)行任務(wù)的過程我們需要通過攝像頭記錄下來，以便于我們的重復(fù)觀察與分析。還要麻煩您對本次測試的內(nèi)容進(jìn)行保密，如果沒有什么疑問，請您在這些協(xié)議上簽字，謝謝。

（2）事前訪談（5~10分鐘），了解用戶背景，也可通過問卷來獲取信息

常用話術(shù)：方便透露下您的年齡/職業(yè)嘛，說個(gè)范圍就可以，比如：20~30/某個(gè)行業(yè)。您是否有用過類似的在線購物產(chǎn)品？有的話，感覺怎么樣？感覺優(yōu)點(diǎn)/缺點(diǎn)有哪些？如果沒有，您購物是通過什么方式呢？通過什么方式支付呢？

（3）測試說明（5分鐘），說明測試內(nèi)容與用戶應(yīng)遵循的相關(guān)規(guī)則。

常用話術(shù)：接下來請您使用我們的APP購買一件商品，任務(wù)的細(xì)節(jié)和背景都寫在這張卡片上了。需要強(qiáng)調(diào)的是：我們的APP只是一個(gè)初步版本，我們已經(jīng)知道它存在一些體驗(yàn)上的問題，想通過您的使用驗(yàn)證這些問題，所以如果遇到了什么問題，都是產(chǎn)品設(shè)計(jì)的問題，操作失敗了也請不要放在心上。

在操作過程中，希望您能一邊操作一邊告訴我您要進(jìn)行什么操作？您為什么要這么操作？您是怎么想的？這對我將非常有幫助。

最后，您在操作過程中最好不要向我提問，因?yàn)槿绻腋嬖V了您如何操作，我可能就無法找到產(chǎn)品中的問題了。所以如果您問我問題，我沒有答復(fù)您，還請見諒。

（4）觀察測試（30~40分鐘），觀察并記錄用戶在執(zhí)行任務(wù)中遇到的問題

假設(shè)目標(biāo)任務(wù)為——購買一件100元以上的T恤，起點(diǎn)為首頁，終點(diǎn)為付款成功頁。

常用話術(shù)：假設(shè)您的同事過生日了，您想送他一件100元以上的T恤，請使用這款A(yù)PP進(jìn)行購買。

（5）事后訪談（5~10分鐘），通過回顧法詢問用戶在執(zhí)行任務(wù)中遇到的問題

常用話術(shù)：您剛才用這款A(yù)PP進(jìn)行了一次購物體驗(yàn)，能談?wù)勀母邢雴幔?/p>

比如：覺得哪里比較好？哪里比較差？對比您之前使用過的同類APP感覺如何？如果要綜合評價(jià)這次購物體驗(yàn)，您會(huì)給它打幾分呢？給之用過的同類產(chǎn)品打幾分呢？為了使產(chǎn)品體驗(yàn)更好，您覺得我們有哪些需要改進(jìn)的地方呢？

雖然主流觀點(diǎn)認(rèn)為不該問用戶產(chǎn)品哪里需要改進(jìn)，因?yàn)楦倪M(jìn)產(chǎn)品是設(shè)計(jì)者的事情，用戶給出的也只是基于自身經(jīng)驗(yàn)的主觀解決方案。但是如果針對用戶的答案，繼續(xù)深挖“為什么”，可能就會(huì)知道用戶真正想要的結(jié)果是什么。

（6）結(jié)束語（3分鐘），對用于表示感謝，并初始化實(shí)驗(yàn)室準(zhǔn)備測試下一位用戶

常用話術(shù)：今天的測試到此為止啦，感謝您的配合，這次測試的數(shù)據(jù)對我們非常有用，我們?yōu)槟鷾?zhǔn)備一盒咖啡以表謝意，請笑納哈。（接著送走用戶就好）

STEP 4：試點(diǎn)測試

試點(diǎn)測試可以理解成可用性測試之前的彩排，無論進(jìn)行了多么周密的計(jì)劃，不實(shí)踐一下是不會(huì)發(fā)現(xiàn)計(jì)劃中的問題的，試點(diǎn)測試的目的就是對測試計(jì)劃進(jìn)行測試，以便于發(fā)現(xiàn)測試計(jì)劃中的疏漏，及時(shí)修復(fù)，以免浪費(fèi)測試資源。

試點(diǎn)測試的用戶一般找同事充當(dāng)即可，但要保證測試的地點(diǎn)和相關(guān)資料都與實(shí)際測試時(shí)完全一致。

然后即可開始可用性測試的流程，要重點(diǎn)關(guān)注：

• 臺詞和任務(wù)卡片的設(shè)計(jì)，是否可以準(zhǔn)確傳達(dá)信息？

• 臺詞和任務(wù)卡片是否透露了操作步驟，用戶是否很快的完成任務(wù)？

• 任務(wù)時(shí)間安排是否合理，用戶是否可以在規(guī)定時(shí)間內(nèi)完成任務(wù)？

• 任務(wù)流程安排是否合理，用戶是否感到莫名其妙？

最后，根據(jù)試點(diǎn)測試中發(fā)現(xiàn)的問題，對測試計(jì)劃進(jìn)行修復(fù)，完善測試計(jì)劃。

STEP 6：觀察&訪談

（1）邀請關(guān)鍵干系人觀察測試

建議邀請產(chǎn)品的核心研發(fā)、設(shè)計(jì)師、項(xiàng)目經(jīng)理等來觀察測試，因?yàn)檫@樣可以是測試結(jié)果更有說服力。如果沒有這些人來觀察測試，測試結(jié)果得可信度對他們來說就大打折扣。因此，越多關(guān)鍵干系人觀察到了測試，越有利于后續(xù)產(chǎn)品優(yōu)化方案的執(zhí)行。

（2）不要干擾用戶執(zhí)行任務(wù)

進(jìn)入正式測試環(huán)節(jié)后，測試人員就不能像在事前訪談一樣不斷的像用戶提問了，用戶測試的主角是用戶，測試人員應(yīng)安靜的觀察用戶的操作并記錄，不要干擾用戶執(zhí)行任務(wù)。

當(dāng)用戶對當(dāng)前操作存在疑問時(shí)，比如：“我現(xiàn)在可以按這個(gè)按鈕嗎？”

測試人員不可以直接回答用戶應(yīng)該如何操作，以及每個(gè)按鈕代表什么。也不可以無視用戶的問題，因?yàn)檫@樣可能會(huì)引起用戶的不滿情緒。

此時(shí)，最合適的方式應(yīng)該是回復(fù)“您覺得應(yīng)該是怎樣呢？是什么讓您覺得應(yīng)該是這樣？您怎么想就怎么做，沒關(guān)系的。”把問題推回給用戶，并讓其有一定安全感，做錯(cuò)了也沒關(guān)系。我們只負(fù)責(zé)告訴用戶“做什么”，至于“怎么做”這是要用戶通過操作反饋給我們的信息。

（3）適當(dāng)干預(yù)用戶的操作

用戶測試中最常用的方法就是發(fā)聲思考法，它要求用戶在進(jìn)行操作的同時(shí)將所思所想大聲說出來，以便測試人員了解用戶的心理活動(dòng)，以及用戶在每個(gè)操作流程中關(guān)注了哪些元素，如何看待這些元素？知道了這些才能更好的根據(jù)用戶心智模型來改進(jìn)產(chǎn)品。

但在實(shí)際測試中，用戶很少會(huì)把自己所思所想直接說出來，有的是因?yàn)楹π?；有的是因?yàn)楦械讲蛔栽?，難以做到。

這時(shí)就需要測試人員進(jìn)行適當(dāng)?shù)母深A(yù)，比如：您正在看什么呀？您現(xiàn)在想進(jìn)行什么操作呀？這是否和您的預(yù)期一致呀？通過這類問題試探用戶的想法，并鼓勵(lì)其發(fā)生思考。

原則上，只要用戶操作的很順利就不需要人為干預(yù)，我們只在用戶碰到問題時(shí)進(jìn)行干預(yù)，進(jìn)而了解用戶遇到了什么問題。用戶的困惑除了發(fā)生思考，還可以從其肢體語言表達(dá)出來。比如：用戶皺眉、發(fā)出語氣詞、喘粗氣、清嗓子、撓頭、突然停下動(dòng)作等，這都暗示了用戶在當(dāng)前界面遇到了麻煩，所以測試人員應(yīng)重點(diǎn)留意用戶的肢體語言。

但切忌幫助用戶進(jìn)行預(yù)判斷和給予用戶提示，比如：“這個(gè)按鈕可能設(shè)計(jì)的不太合理…”。測試人員只負(fù)責(zé)觀察和記錄用戶的行為，不能引導(dǎo)用戶操作和幫助用戶判斷。

（4）重點(diǎn)觀察和記錄用戶在什么界面說了什么做什么了

記錄這些客觀事實(shí)即可，不要帶著自己的觀點(diǎn)去觀察，比如：為了證明某個(gè)設(shè)計(jì)是對的/錯(cuò)的，帶著尋找證據(jù)的心態(tài)去觀察可能會(huì)忽略一些信息，因?yàn)槿藗冎豢吹阶约合胍吹降摹?/p>

記?。何覀円涗浀氖强陀^事實(shí)，而不是自己基于客觀事實(shí)的推斷和分析?？赡芪覀兛吹接脩舻牟僮餍睦眈R上就有了一個(gè)推斷，這沒問題，但要區(qū)分出客觀事實(shí)和推斷。因?yàn)榉治?，是這個(gè)階段收集完數(shù)據(jù)之后在下一個(gè)階段應(yīng)該做的事。記錄問題的同時(shí)，也要關(guān)注用戶操作流暢的地方，避免最后修改了不必修改的地方。（記錄的數(shù)據(jù)，是繪制用戶體驗(yàn)地圖的關(guān)鍵）

（5）使用回顧法進(jìn)行提問

有時(shí)，用戶測試中出現(xiàn)了問題，但出于某種原因我們不便于打斷用戶深入提問，或者用戶通過發(fā)生思考法遺漏了某些信息。這時(shí)，測試完成后，測試人員要對測試中發(fā)生的問題進(jìn)行提問。

比如：“您剛才在XX界面停留了很久，能告訴我當(dāng)時(shí)您在思考什么嗎？”這樣就能通過回顧法補(bǔ)全測試中遺漏的信息。

STEP 7：分析

（1）整理數(shù)據(jù)，判斷產(chǎn)品是否需要迭代

通過用戶測試，我要們判斷交互設(shè)計(jì)是否滿足了用戶體驗(yàn)?zāi)繕?biāo)水平。分析數(shù)據(jù)的第一步是整理出測試結(jié)果，通常要繪制一份表格，表格內(nèi)容通常包含：任務(wù)、用戶體驗(yàn)?zāi)繕?biāo)、任務(wù)基準(zhǔn)值、任務(wù)目標(biāo)值、是否完成目標(biāo)等信息。

如下圖所示：

可用性測試數(shù)據(jù)整理表的示例

接著我們直接通過比較觀測結(jié)果和用戶體驗(yàn)?zāi)繕?biāo)，就可以知道哪些用戶體驗(yàn)?zāi)繕?biāo)已經(jīng)達(dá)到、哪些沒有達(dá)到。如果體驗(yàn)?zāi)繕?biāo)沒有達(dá)到且資源充足，那么產(chǎn)品就需要進(jìn)行迭代。這時(shí)就要具體分析每個(gè)用戶體驗(yàn)問題，并輸出解決方案。

（2）分析問題的影響程度

并非所有的問題都是平等的，一些問題會(huì)帶來負(fù)擔(dān)，用戶必須先處理才能繼續(xù)原來的問題。其他錯(cuò)誤可能會(huì)帶來用戶的情緒問題，讓用戶重復(fù)操作，但不會(huì)引發(fā)新的問題。

了解問題的嚴(yán)重性，能幫助我們更好的對用戶體驗(yàn)問題優(yōu)先級進(jìn)行排序，我們通過問題性質(zhì)和問題發(fā)生頻率來確定問題的影響程度。

問題性質(zhì)，一般要通過效果問題＞效率問題＞滿意度（或者速度＞錯(cuò)誤＞滿意度）的順序來評價(jià)問題的性質(zhì)。

效果相關(guān)問題導(dǎo)致用戶無法完成或幾乎無法完成任務(wù)，效率問題導(dǎo)致用戶做無用功，或過多思考、執(zhí)行更多錯(cuò)誤操作。滿意度問題導(dǎo)致用戶表達(dá)不滿意情緒，問題發(fā)生頻率，通過發(fā)現(xiàn)問題的人數(shù)來決定。

不管測試了多少人，我們用三個(gè)范圍來表示頻率：1個(gè)人、幾個(gè)人、所有人（幾乎所有人）。比如：10個(gè)人可能就被分為：1個(gè)人、2~7人、8~10人三個(gè)范圍。

然后我們基于問題性質(zhì)和發(fā)生頻率建立一個(gè)表格，如下圖所示：

問題影響度分析表的示例

列代表問題發(fā)生頻率，行代表問題性質(zhì)。把標(biāo)記黃色的問題定義為必須要解決的問題，把標(biāo)記綠色的問題標(biāo)記為最好去解決的問題，把標(biāo)記為藍(lán)色的問題標(biāo)記為資源充沛的話，可以去解決的問題。資源總是有限的，不可能每個(gè)問題都去修復(fù)，我們必須通過分析問題的影響程度確定要修復(fù)的問題。

（3）制作用戶體驗(yàn)問題描述

以表格來維護(hù)用戶體驗(yàn)問題的數(shù)據(jù)比較簡略，不利于其他人了解詳細(xì)情況和參考，所以我們需要對每個(gè)問題進(jìn)行一些信息補(bǔ)充，讓用戶體驗(yàn)問題的實(shí)例在數(shù)據(jù)分析中變得更有價(jià)值。

我們需要做的就是——了解每個(gè)問題及其產(chǎn)生的原因和可能的解決方案，將表示同一個(gè)用戶體驗(yàn)問題的多個(gè)用戶體驗(yàn)問題進(jìn)行合并（肯定會(huì)有重復(fù)出現(xiàn)的問題），并認(rèn)清各個(gè)問題之間潛在的關(guān)系。

一份用戶體驗(yàn)問題描述通常包含如下信息：

• 問題概述：從用戶角度描述產(chǎn)品存在的問題，比如：“沒有返回按鈕”應(yīng)描述為“用戶無法返回上一級頁面”。

• 用戶任務(wù)：提供問題發(fā)生的背景，幫助我們了解用戶想進(jìn)行什么操作時(shí)發(fā)生了什么樣的問題。

• 用戶目標(biāo)：一個(gè)任務(wù)可能會(huì)分為多個(gè)目標(biāo)，用戶目標(biāo)描述用戶具體為了達(dá)到什么目標(biāo)時(shí)碰到的問題。

• 問題詳述：對用戶體驗(yàn)問題詳細(xì)的描述，比如：用戶在什么頁面，進(jìn)行了什么操作，界面發(fā)生了怎樣的交互等。

• 問題分析：從設(shè)計(jì)師角度對問題進(jìn)行分析，比如：為什么產(chǎn)品沒有按用戶期待的方式運(yùn)行？是什么導(dǎo)致了用戶無法完成任務(wù)或產(chǎn)生消極情緒？這樣的解釋會(huì)往往會(huì)為可行的問題解決方案提供線索。

• 解決方案：針對問題產(chǎn)生的原因提出可能的解決方案。

STEP 7：重新設(shè)計(jì)

通常來講，我們會(huì)針對每個(gè)問題，給出一個(gè)解決方案。但事實(shí)往往并非如此，問題和解決方案之間有時(shí)并不是一一對應(yīng)關(guān)系。如果針對每個(gè)問題都給出解決方案，可能導(dǎo)致產(chǎn)品的復(fù)雜度提升。

有時(shí)，一個(gè)解決方案就能解決多個(gè)問題，這就需要我們對每個(gè)問題的聯(lián)系及其產(chǎn)生原因有深刻的洞察，若是能從根本解決問題，產(chǎn)品的品質(zhì)會(huì)得到極大提升。

這需要我們跳出原有的一對一的思維，先從宏觀層面整體分析這些問題組，而不是孤立的一個(gè)個(gè)問題。在設(shè)計(jì)出解決方案后，還要對解決方案的成本和優(yōu)先級等信息進(jìn)行梳理，以便于更好的管理問題&解決方案信息表格，可以把這些用戶體驗(yàn)問題與其解決方案當(dāng)做產(chǎn)品需求來管理。

如下圖所示：