《用戶體驗與可用性測試》

1 前言

一直想一個吸引眼球的副標題忌栅，最后還是覺得書名上的這個副標題，最能體現(xiàn)這本書的核心内边。

這是一本入門書籍榴都，所以非常適合我這種交互的初學者。這本書給我的最大啟發(fā)漠其，就是發(fā)現(xiàn)測試的重要性嘴高，之前重點一直關注上設計的理論和技巧上，而驗證設計這個重要的過程沒怎么關注和屎。這可能也跟我所在的公司環(huán)境有拴驮，公司從制造行業(yè)發(fā)展而來，在軟件開發(fā)過程中能引入UI/UX設計柴信，在領導看來已經(jīng)算難能可貴了吧（現(xiàn)狀是幾個項目共用一個UI套啤，UI兼任UE）。

雖然公司一直喊著以客戶為中心随常，但UE設計人員短缺潜沦，更別提對設計的可用性測試萄涯，通常對發(fā)出的設計稿就是小組內(nèi)部評審下。如果按照書中的分類應該屬于用戶可用性成熟度模型（作者根據(jù)經(jīng)驗設定的一種類似于CMM的模型）中的搖籃期

設計流程大致分成三部分調(diào)研唆鸡、設計和測試窃判。

3 調(diào)研（用戶訪談的技巧）

用戶訪談的技巧

2.1 傳統(tǒng)訪談方式的局限

反饋意見。反饋意見經(jīng)常用戶的建議和行為并不一致喇闸，比如用戶說“我覺得習慣了的話還是很好用的”袄琳，但事實上要真的習慣這個產(chǎn)品，用戶可能要話費很大精力燃乍。

假如用戶真的可以想出很實用的點子唆樊，并且愿意無償提供給企業(yè)的話，那么專業(yè)的設計團隊還有存在的必要嗎刻蟹？

小組訪談（焦點小組）參與人數(shù)比較多逗旁，每個人發(fā)言時間有限，收集來的多是意見舆瘪、體驗比較少片效；發(fā)言時容易被別人的觀點影響；因為是在眾人面前發(fā)言者英古，發(fā)言者難免會對發(fā)言內(nèi)容進行加工和潤色淀衣。

一對一訪談。無論是計劃好的問題召调，還是開放的問題膨桥。用戶的一般的回答也是歸納過的，缺乏細節(jié)唠叛。

2.2 師徒式訪談

師徒式訪談（contextual inquiry）只嚣，也譯作背景調(diào)查法，現(xiàn)場調(diào)查法艺沼。它的基本基本步驟是：請教 -> 刨根問底 -> 核實

請教册舞。訪談暖場后，慢慢將話題移到需要的主題障般，進而引出深入的交談调鲸。

刨根問底。跟傳統(tǒng)訪談的目的是獲取信息不同剩拢， 師徒式訪談更重視完全理解用戶所講的內(nèi)容线得。

核實。大致理解后徐伐，把理解的內(nèi)容復述給用戶進行核對贯钩。

訪談結束后將記錄內(nèi)容整理成情景劇本。訪談的記錄無論是語音還是文字，缺乏使用背景角雷，對于用戶發(fā)言祸穷，分析時可能會有不同的理解。而是用情景劇本將用戶發(fā)言內(nèi)容用故事的方式來記錄勺三，則會更嚴謹雷滚，便于理解。一般地吗坚，情景劇本包括：

• 用戶的個人信息
• 使用產(chǎn)品的背景
• 使用場景

3 原型（原型制作的要點）

原型制作的要點

3.1不要忘記做的假頁面祈远。

在制作界面時確保錯有的菜單都能點擊，讓用戶在測試的時候更加自然商源、流暢车份。一個簡單的方法是，無需測試的功能就統(tǒng)一跳轉到一個界面牡彻，顯示“目前該頁面不可用扫沼，請返回上一頁”。

3.2 元素的保真度區(qū)分對待庄吼。

原型中的內(nèi)容缎除，如網(wǎng)站中的新聞、產(chǎn)品列表总寻；操作中的提示框等器罐。而另一些元素如果跟實際開發(fā)的相差很遠，用戶使用原型時將無法得到設計人員想要的結論废菱。這些元素包括：

• 界面順序技矮、數(shù)量
• 界面元素的位置
• 鏈接和按鈕上的文字
• 界面上的提示性文字
• 輸入項和格式
• 操作相關的圖標

3.3 制作原型所需的技能

絕大部分的原型不需要高深的藝術素養(yǎng)或專業(yè)的程序開發(fā)技能，更需要的是深入理解用戶需求殊轴，分析測試所需的邏輯能力，不局限于已有概念的發(fā)散思維能力袒炉。

不需要區(qū)分崗位旁理，或是需要一個人同時具備這些技能。開發(fā)團隊可以一起討論好細節(jié)我磁，然后由界面設計人員或是開發(fā)人員制作具體的原型孽文。

4 測試（用戶測試的方法）

用戶測試

4.1 用戶測試

用戶測試是一種典型的實驗型產(chǎn)品可用性評價，它是一系列用戶參與評估的方法的總稱夺艰，這些方法包括：

4.1.1 用戶測試

發(fā)聲思考法（Talk Alound Method）芋哭。用戶一邊說出心里想的內(nèi)容一邊操作，有助于弄清楚為什么會導致用戶操作出現(xiàn)問題的原因郁副。在用戶發(fā)言和操作的同時减牺，注意一下三點：

1. 用戶能否獨立完成任務（有效性）
2. 用戶在使用過程匯總，是否做了無效操作或是不知所措的情況（效率）
3. 用戶是否有不滿的情緒（滿意度）

4.1.2 回顧法

回顧法（Retrospective Method）。用戶操作后回答問題拔疚，補充想要了解的用戶信息肥隆，這樣可以避免打斷用戶的操作。但回顧法缺點比較明顯稚失，如復雜的操作很難回顧栋艳；用戶一般在回顧時會自行總結，遺漏很多細節(jié)句各；比較耗時等吸占。正因如此，一般較少使用回顧法凿宾。

4.1.3 性能測試

發(fā)聲思考法和回顧法都屬于定性分析矾屯，如果需要定量分析，則可以進行性能測試（Performance Measurement）菌湃。

前兩種方法一般是一對一问拘，但性能測試參與人數(shù)較多，一般采用集體測試的方式惧所。測試場所用隔板簡單劃分后骤坐，每次5_{10人進行測試，每1}2人配一個監(jiān)督者（可以讓兼職大學生擔任）下愈，參與測試者需要20以上纽绍。

測試主要對產(chǎn)品三要素（有效性、效率势似、滿意度）拌夏，定量體現(xiàn)在：

• 有效性可以用任務完成率來表示
• 效率可以用任務完成時間來表示
• 滿意度可以用主觀評價來表示，一般用調(diào)查表的形式
  性能測試缺點很明顯履因，一是時間障簿、金錢成本太高；二是設計團隊無法從測試結果中栅迄，找到用戶不能完成任務的原因站故。

4.2 DIY用戶測試

隨著敏捷開發(fā)的迅速普及，正規(guī)用戶測試的時間毅舆、金錢的成本難以承受西篓。但絕不能因此而放棄測試，在保證測試環(huán)節(jié)下憋活，進行簡化的DIY測試也能達到預期的效果岂津。