用戶體驗與可用性測試 | 讀書筆記

第一章 以用戶爲中心的設計概論

1.1 UX 和 UCD

1.1.1 體驗的價值

1.1.2 UX 的構成

<體驗經濟> 按照經濟價值來計算一杯咖啡的價格

加瑞特倡導的 <用戶體驗要素> , 多數和 UX 相關的內容必需要從框架層和框架層來了解

1.1.3 UX 的實現方法

UCD: 調查 > 分析 > 設計 > 測評 > 改進 > 反覆

1.1.4 UCD 的要點

流程的質量 / 螺旋上升的設計流程 / 用戶的參與

1.1.5 專欄: UX 的國際標準

ISO 13407

ISO 9241-210

UX 的定義

1.2 產品可用性不等於產品易用性

1.2.1 產品可用性無關緊要嗎

usability 是基本需求, 不是魅力需求

1.2.2 根本無法用的產品

亂七八糟的搜索引擎: 搜到的全是廣告; 弄錯了大小寫就搜不到東西

繁瑣的訂單頁面

無法後退的網站

1.2.3 產品可用性的定義

Effectiveness: 作對事情, 達到目的

Efficiency: 最短路徑

Satisfaction: 有沒有不愉快的體驗? (好比註冊時須要提供太多隱私信息)

1.3 產品失敗的緣由

1.3.1 橡膠用戶

把用戶羣假設爲 ''關注時尚, 注重自個人成年人'' , 就和沒有定義對象用戶同樣. 一個產品不能把全部的人都當作用戶, 好比 ''敞篷越野麪包車'' .

橡膠用戶 (Elastic User) 能夠根據設計人員的想象而爲所欲爲地變化 —— Alan Cooper

1.3.2 產品的使用背景

1.3.3 用戶體驗的點與線

1.4 UCD 的最新四原則

1.4.1 不要盲從用戶的意見

以 ''知足用戶要求'' 爲前提的開發搬來就是錯的

不能盲目聽錯諸如 ''大家的產品若是有這樣的功能就行了'' , 這樣的用戶意見. 用戶所說的是對本身的體驗作出了分析的結果, 不能保證用戶分析的正確性. 咱們要關注的是用戶體驗, 是未經分析的第一手數據 (FACT)

1.4.2 只爲一人設計

事先要捉摸清楚, 哪些人, 爲了什麼目的, 使用咱們的產品

大膽的設想 ''不要爲全部的用戶設計, 而只爲一我的設計產品'' .

1.4.3 邊作邊想

一邊思考, 一邊繪製簡單的示意圖

1.4.4 早期試錯

Early / Samll / Often / Smart

第二章 用戶調查法

2.1 老套的訪談方法

2.1.1 用戶意見的侷限性

爲了給改善界面, 必須先收集問題相關的數據, 再從數據中分析緣由 (界面元素/界面變換/信息等), 最終才推導出解決方案. 咱們要作的是摒棄用戶的意見, 分析用戶的行爲 (FACT) , 行爲數據是未經分析的新鮮數據, 設計團隊要知足用戶本身都沒有發現的潛在需求.

2.1.2 小組訪談的侷限性

Focus Group Interview: 通常會按照年齡, 性別, 經驗, 生活方式等等劃分小組, 每一個小組 6 我的左右

缺點:

小組訪談的獲得的大多數都是意見, 而不是 Fact

每一個人發言時間有限

參加人員之間發言互相影響, 會對故事加以潤色

2.1.3 訪談的侷限性

按照計劃問題進行

用戶回答的都是概括過的信息, 不會事無鉅細的告訴你交通路線, 玩了什麼, 等了多長時間等等, 並且用戶通常都只說標準狀況, 不會提到特殊狀況

2.2 師徒式訪談

2.2.1 背景式訪談

採訪人員拜入用戶門下 >

用戶一邊演示體驗一邊說明 >

採訪人員遇到不懂的地方時提問 >

採訪人員將本身理解的內容複述給用戶聽(覈實)

Contextual Inquiry ——Karen Holtzblatt

2.2.2 徒弟的思想準備

只有清楚了用戶行爲的背景和細節的前提啊, 才能提出有用的問題. 所以, 問題是隨着談話內容的推動 (瞭解了用戶行爲以後) 而天然出現的.

• 訪談步驟: 請教 > 刨根問底 > 覈實
• 不能讓用戶察覺出你是專家
• 不要去驗證你的假設 (不要問: 若是有 XX 功能的話你以爲怎麼樣. 這樣收集到的是用戶意見, 而不是用戶體驗)
• 不要再無效的問題上糾纏

2.2.3 選擇師父的方法

師傅的技術和經驗比較重要

實際操做時, 用戶羣通常設定爲 3~6 組, 每一個用戶羣大概 5~6 人

使用調查公司的樣本庫招募志願者或者經過本身的人脈

---

📌 案例: 背景式訪談

訪談人員: 您天天要瀏覽 50 封以上的郵件雜誌, 還要把他們分類, 這很耗時吧? ^請教^

用戶: 還好, 雖然說是瀏覽, 其實也就是一目十行地讀. 通常狀況下, 光從寄件人和標題就能大概判斷出內容了, 以後在快速掃一眼正文的目錄就差很少了. 再者, 大多數的郵件雜誌都是把吸引眼球的內容放在正文的開頭和結尾部分. 先看一下最下面的文字, 若是感興趣的話, 再返回開頭仔細地閱讀.

訪談人員: 吸引眼球的內容是指哪些內容呢? ^刨根問底^

用戶: 好比說像 ''獎金 100 萬! '' 這樣的懸賞是確定會看的. 還有, 我訂閱的郵件雜誌中有一些很是流行的專欄, 通常登再郵件雜誌的最後部分

......

採訪人員: 申請不少郵件雜誌的話, 慢慢的雜誌數量會愈來愈多, 關於這點, 您通常怎麼處理呢? ^請教^

用戶: 登陸以後, 最新的五封郵件我都會仔細閱讀. 這樣的話, 基本就能清楚這些雜誌主要講的是什麼內容, 若是對這家咋着的主題沒什麼興趣的話就會退訂.

採訪人員: 退訂的操做是什麼樣的呢? ^刨根問底^

用戶: 比較簡單, 通常的郵件雜誌, 最下方都會有退訂連接. 單擊這個連接, 就會發送取消郵件, 或者跳轉到退訂的頁面上去.

採訪人員: 有不是這樣的狀況嗎? ^刨根問底^

用戶: 有, 還不在少數. 郵件裏並無推定的網址連接, 就只好到它的官方網站上去取消, 若是找不到的話就沒有辦法了. 還有的狀況是想退訂, 卻發現忘記了用戶名和密碼. 此時就會用出生年月, 地址, 電話號碼之類的逐個嘗試, 仍是不行的話, 也就沒有辦法了. 找客服也比較麻煩, 因此不會去找. 這樣的郵件雜誌, 即使收到了也不會看, 會馬上刪除.

採訪人員: 原來如此, 看來發送退訂的郵件是最簡單的, 並且若是利用用戶名和密碼能夠方便地取消的話就行了. ^覈實^

用戶: 我也這麼認爲. 另外, 也有一些網站是輸入口令就能退訂, 我以爲這個方法也不錯.

---

2.3 訪談實踐

2.3.1 如何設計訪談

漏斗形訪談框架, 先從職業, 興趣等範圍比較大的話題開始

2.3.2 訪談的地點, 設備, 人員

2.3.3 進行訪談

• 構建信賴關係

• 把握用戶我的信息

• 把握用戶使用狀況

  請教 / 刨根問底 / 覈實

  引出具體例子

  使用小道具

• 驗證假設型訪談, 通常會安排在背景式訪談以後, 切忌放在背景式訪談中

---

📌 案例: 訪談大綱

就辦公自動化設備的使用狀況進行訪談的大綱

用戶的平常業務內容

由於什麼開始使用這個辦公自動化設備

使用特定辦公自動掛設備進行的業務的具體內容

失敗的教訓

使用的竅門

其餘相關業務等等

1. 引子

   • 寒暄 / 錄音許可 / 相關信息公開受權 / 注意事項

2. 用戶檔案

   • 目的: 掌握業務內容
   • 問題示例: 首先, 可否請您介紹一下您的工做內容 / 公司概況 / 資歷 / 專業知識技能等

3. 使用狀況1

   • 目的: 掌握正常的使用狀況

   • 問題示例:

     我看您在工做中彷佛用到了 XX 辦公自動化設備, 可否談一下您平時是如何使用的? 何時 / 爲了達到什麼目的 / 在哪裏/和誰一塊兒使用等

     能都介紹一下最近一次使用 XX 辦公自動化設備的狀況呢?

     據說您有本身首創的使用方法, 那您是否有獨特的心得體會呢?

4. 使用狀況2:

   • 目的: 掌握特殊的使用狀況

   • 問題示例:

     您在使用 XX 辦公自動化設備時, 是否碰到過讓您不知所措的狀況呢? 可否介紹一下這段經歷呢?

     您在使用 XX 辦公自動化設備時, 確定碰到過須要暫時中斷, 先要處理其餘事情的狀況. 通常是處理什麼事情呢? 暫時中斷的話設備會怎麼樣呢?

     XX 辦公自動化設備的功能裏, 有什麼事您偶爾使用或者根被沒有用過的功能嗎? 有您開始時會使用, 但慢慢地不會再使用的功能嗎? 請您說一下緣由?

5. 但願

   • 目的: 掌握明確的用戶需求背後的使用狀況

   • 問題示例:

     您對 XX 辦公自動化設備是否有 ''若是能有這樣的功能就行了‘’ , 或者 ''這裏若是能變成這樣就行了'' , 之類的想法嗎? 爲何會這麼認爲呢?

6. 結束

   • 結束語 / 支付酬金 / 送客

---

2.4 情景劇本

2.4.1 文檔化的必要性

有效的再現用戶體驗的場景, 支持設計團隊討論的工具 —— 情景劇本 (Scenario)

2.4.2 什麼是情景劇本

scenario 就是用戶使用系統或產品時的情景劇. 以寫故事的手法, 吧用戶使用系統或產品時的背景, 達到何種目的, 如何使用及其結果描繪出來.

寫故事能夠完整的描述用戶在什麼狀況下, 採起了什麼樣的行動, 最終致使了什麼樣的結果. 能夠用操做步驟示意圖, 照片等補充情景劇本.

---

📌 案例: 在線詞典 Scenario

• 用戶我的信息

  T 先生 (30 多歲的中年男性) , 是某軟件開發公司的工程師. 因爲工做性質, 須要瞭解最前沿的 IT 資訊, 而這些資訊主要來源於國外的網站和郵件新聞. 可是 T 先生的英語不太好, 兩年前參加託業考試時, 才考了 600 多分. 雖然說與專業有關的英語大概能看個明白, 可是想要精確地把握含義的話, 就要藉助詞典了.

• 使用在線詞典的原委

  之前 T 先生主要使用電子詞典. 雖然攜帶方便, 但輸人不方便, 並且顯示屏幕過小, 要一直翻頁閱讀, 這讓 T 先生很不滿意. 更加讓 T 先生不能忍受的是, 不少 IT 相關的專業術語常常查不到.

  所以, 大概從兩年前開始, T 先生就使用了免費的在線詞典網站. 該網站不只普遍收錄了各專業的術語, 並且還及時收錄了當前的流行語. 另外, 它的翻譯並不生硬, 這點令 T 先生很滿意. 所以, 不管是在公司仍是家中的計算機裏, T 先生都把該網站添加進了網址收藏欄, 以便在須要查詢時隨時訪問. 現現在, 己經徹底用不到電子辭典了 (T 先生的公司和家裏均可以上網) .

• 使用場景 1: 簡單使用

  若是是比較短的英文 (一頁 A4 紙的長度) , T 先生通常都在電腦上閱讀. 若是遇到了不認識的單詞, 就新打開一個瀏覽器窗口, 經過書籤訪問在線辭典網站.

  有時 T 先生會直接在檢索框內輸人要查詢的單詞, 通常經過簡單的複製粘貼查詢單詞, 由於若是手動輸入不當心拼錯單詞的話, 就什麼都搜索不到. 之前使用電子詞典時, 就算是拼錯了單詞, 也會提示相似的單詞一覽以供選擇. T 先生認爲在這一點上, 電子詞典卻是很是方便.

  確認了單詞的含義後, 再經過任務欄切回到英文網站. 若再看到不認識的單詞, 仍然須要切換到在線詞典進行搜索. 可是, 若是要查找單詞的數量比較多, 就要頻繁地切換窗口, 使用上有點不方便.

• 使用場景 2: 複雜使用

  要閱讀長篇的英文時, T 先生通常都會先把文章打印出來. 這樣作, 一是由於在電腦上看太累, 其次是由於在電腦上閱讀的話不能添加標註. 不懂的單詞仍是得經過在線辭典網站查詢. 雖然說 T 先生已經特別注意不拼寫錯誤, 可是也會出現因拼寫錯誤而查不到的狀況.

  確認了檢索結果後, T 先生會把他認爲最合適的解釋標註在英文單詞旁的空白處. 由於在比較長的英文文章中常常會發生, 讀了幾段以後又重頭讀起的狀況, 若是不把翻譯的結果標註在文章裏. 極可能下一次又要從新查一遍.

  儘管如此, 仍是會發生同一個單詞檢索屢次的狀況. 由於對於一篇幾十頁的文章來講, 很難記住上一次查詢的結果標註在了哪一頁, 與其回頭找, 不如從新查詢一次比較快. 所以, T 先生認爲, 若是在線詞典服務能把以前查過的單詞以列表方式顯示出來的話, 那就方便多了.

• 使用場景 3: 特殊狀況

  在寫英文郵件時, T 先生偶爾也要使用日英辭典. 這時也是使用在線詞典網站. 然而, 該網站默認使用的是英日翻譯. 要想使用日英翻譯, 就必須每次都轉換一下設置. 由於 T 先平生時使用的都是英日翻譯, 因此不少時候只有在檢索結果爲 0 時, 才注意到設置沒有更改. 因此，T 先生認爲若是可以自動識別語言種類的話就更好了.

---

2.5 分析情景劇本

2.5.1 情景劇本的寫法

• 創做單個的小故事

  能夠把一整塊的內容整成單個的故事, 也能夠把散落在筆記各處的內容整理成一個故事.

• 推敲情景劇本

  把小故事都寫好以後, 就能夠把他們組合成情景劇本了. 能夠按時間排序, 能夠更具相互間的影響調整順序, 或者按照因果, 包含等關係, 把多個小故事合併成一個.

  通常一個 1 h 的訪談, 情景劇長度在 3~4 頁 A4 紙, 須要時間通常爲 2~3 小時.

2.5.2 測評情景劇本

邀請用戶面對面再進行一次溝通, 請他本人來檢查情景劇本

2.5.3 情景劇本的使用方法

完成情景劇本後, 要向全體成員公開. 讓擁有不一樣背景的成員從各自的角度閱讀情景劇本並提出修改意見. 同時, 在說明本身的創意時, 也能夠參照情景劇本. 情景劇本中最有價值的信息就是 "貨真價實的任務" 和 "真正的用戶需求" .

• 貨真價實的任務

  設計人員根據主觀臆想產生的是假任務, 真正的任務能夠從情景劇本中發現

  使用詞典閱讀英語短文

  使用詞典閱讀英語長文

  使用詞典寫英文郵件

  "查詢單詞含義並非真正的任務" , 由於即便作查詢一個列表的單詞的含義的測試, 也不會發現這個在線詞典真正存在的問題.

• 真正的用戶需求

  即便沒有用戶明確說明, 根據上下文也能夠推斷出的必備的需求 (隱藏的需求) .

  用戶用打印網頁的功能時, 不經處理打印的話, 就會把導航欄也一塊兒打印出來, 或者出現網頁過寬, 與打印紙大小不符等狀況. 用戶可能並無對此表示特別的不滿, 可是也應該注意到此類需求.

2.5.4 探索用戶需求

1. 分解

   根據用戶行爲, 場景等的切換進行情景劇本的分解. 注意撰寫情景劇本時候, 不要在單個句子中包含用戶的多個行爲或要求.

2. 分析

   從分解後的段落中尋找用戶需求. 理解用戶的行爲在整個情景劇本中具備什麼樣的意義, 推導用戶的潛在需求. 注意不要把用戶需求 (What) 和解決方案 (How) 混爲一談. 用戶需求都是抽象的表現, 需求中不該出現具體的功能名稱或者界面元素.

   網上商城的情景劇本中, "網站上沒有公開的信息若是能經過郵件來諮詢就行了" , 並非真正的需求.

   真正的需求是 "但願儘快獲取網站上那些沒有公開的信息".

3. 思考

   思考能夠知足用戶需求的妥善方案, 把全部知足條件的方案整理成列表.

2.5.5 分析情景劇本的好處

2.5.6 專欄: 角色 (Persona)

Persona 是目標用戶形象, 是從調查結果中挖掘出來的, 能夠避免被橡膠用戶耍得團團轉.

• 進行訪談

  訪談對象要儘量覆蓋預想的用戶羣, 通常 20~30 人左右.

• 把用戶分組

  根據使用該產品的目的或需求, 在組織或團體裏的職責, IT 技能, 行爲類似性等, 把用戶分組. 通常 3~7 組, 每一個組取一個能表明其特徵的組名.

• 定義表明

  找到該用戶組中, 最具備表明性的用戶, 而後在該用戶體驗的基礎上, 追加同組其餘用戶的體驗. 也就是說, 綜合組內各個成員, 創造出一個 "混合體" .

• 添加我的信息

  加上姓名, 年齡, 照片等我的信息, 給人以逼真感.

• 選取主角:

  一個項目可能會有 3~7 個角色, 可是咱們要給這些角色以不一樣的優先權. 角色的優先權因項目而異. 若是各個角色恰好和細分市場一致, 那麼市場價值最大的就是主角; 若是過項目標準是誰都能使用, 那麼技能水平最低的就是主角.

---

📌 案例: 在線詞典用戶需求

---

第三章 原型

3.1 什麼是原型

3.1.1 原型的做用

3.1.2 高保真和低保真

低保真原型不是全部部分都作得粗心大意, 和測試直接相關的部分要花心思, 要能測試. 好比, 若是是爲了檢驗在線商城購物車的原型, 就必須徹底模擬購物步驟之間的跳轉和出錯的提示.

3.1.3 T 原型

水平原型, 也被叫作 "淺式原型 (Shallow Prototype) " , 只須要製做網站首頁和第一層連接頁面.

垂直原型, 也被叫作 "深式原型 (Deep Prototype) " , 只是具有某一項功能的原型.

把水平原型和垂直原型組合在一塊兒, 就是 T 原型.

3.1.4 奧茲國的魔法師 (Wizard of Oz)

讓人躲在背後代替電腦作動做, 可是從用戶的角度看上去好像是系統在運做的方法, 就是 Wizard of Oz.

3.2 原型的製做方法

3.2.1 製做工具

3.2.2 製做的重點

要讓全部的連接和按鈕均可以點擊, 一些不可用的頁面能夠代入假頁面 "目前該頁面不可用, 請返回上一頁" .

須要具備高保真度的元素:

• 界面切換 (順序, 數量)
• 界面元素互相位置關係
• 文本鏈接的內容以及按鈕上文字的內容
• 在界面中現實的指示性文字的內容
• 須要輸入的數據項目及其格式
• 操做相關的圖標設計

3.2.3 由誰來製做

3.3 卡片分類法

3.3.1 層次結構設計

在劃分層次結構時候每每會遇到問題, 這時候就須要用卡片分類法 (Card Sorting) . 卡片分類法有封閉式 (Closed) 和開放式 (Open) 兩種.

3.3.2 封閉式卡片分類法

也叫作帶有目錄的卡片分類法. 白板上已經有了各個種類的名稱, 用戶須要將記有具體素材的卡片貼到各個種類下面. ^注意在用戶操做結束後,\ 提問用戶爲何要貼在該種類下面^

同時用戶是如何移動卡片的, 卡片的移動軌跡也很重要. 若是到最後都未能決定放在哪一個分類下, 說明現有的分類不能覆蓋全部信息的種類, 或者本該相對獨立的兩個分類仍存在某種關聯.

3.3.3 開放式卡片分類法

也被稱爲不帶目錄的卡片分類法

• 聚類分析

  使用距離矩陣 (差異矩陣) 把樣本按空間距離由近到遠的順序結合, 從而產生聚類的多變量分析方法. (必須使用統計軟件) 聚類分析後就能作出表示數據層次結構的樹形圖了.

  

• 分類合併

  分類合併是合併用戶取的分類名的分析方法, 也就是把含義相同的分類名稱合併.

  好比, 某個用戶把相關素材卡片歸類後, 命名爲 "產品信息" , 其餘用戶可能命名爲 "產品" 或者 "商品" 等, 能夠把這些含義相同的分類名合併.

3.3.4 Delphi 卡片分類法

開放式卡片分類法能夠給信息設計帶來啓示, 可是並不能直接用作設計. 須要經過反覆的開放式和封閉式卡片分類法達到逐漸提升成果精確程度的目的. 這樣成本高, 因此引入了 Delphi 卡片分類法. Delphi 法也能夠用於團隊內部的討論工具, 讓你們快速統一意見.

基本流程:

1. 製做構造信息的原型 (種子) , 種子產生的影響很大, 儘可能安排經驗豐富的設計師設計種子
2. 請多位用戶分別按照本身的意願在原型上修改
3. 持續進行 1~2 步驟

第四章 產品可用性評價方法

4.1 什麼是評價

4.1.1 總結性評價和造成性評價

• 總結性評價 (summative Evaluation)

期末測驗, 爲了打分, 體現學習成果

性能測試法: 安排幾十個用戶使用界面, 檢驗目標達成率 (有效性) , 所需時間 (效率) , 滿意度 (滿意度) ; 評價結果通常以 "目標達成率: 55%" , "平均達成時間: 5 分 30 秒" , 「主管滿意度: 2.8 分 (5 分制) 」

通常在設計前或設計後使用

• 造成性評價 (Formative Evaluation)

課堂後的練習, 目的是爲了改善, 而不是爲了打分

發聲思考法

會在產品設計過程當中反覆使用

4.1.2 分析法和實驗法

• 分析法 (Analytic Method)

也被稱爲專家評審 (Expert Review) , 讓產品可用性工程師及用戶界面設計師等專家基於自身的專業知識和經驗進行的評價

缺點: 主觀, 評價結果是假設的

優勢: 時間少, 費用少, 評價範圍比較廣, 設計初期也能夠評價

• 實驗法 (Empirical Method)

手機貨真價實的用戶使用數據, 好比用戶測試法, 問卷調查等

缺點: 時間長, 花費大, 評價範圍窄, 爲了作評價必須作原型

優勢: 客觀, 評價結果是事實

• 分析法和實驗法互補

設計初期階段, 沒有原型產生, 只能用分析法; 另外用戶測試以前, 自豪先用分析法進行簡單評價, 整理出用戶測試時應該要評價的重點和須要重點觀察的部分

4.2 產品可用性檢驗

Usability Inspection

4.2.1 啓發式評估

分析法是評價人員基於自身專業只是及經驗進行的評價, 評價標準很模糊. 爲了讓評價有客觀性, 就出現了各類各樣的指導手冊. 依據指導手冊進行的評估就是啓發式評估 (Heuristic Evaluation) .

4.2.2 啓發式評估十原則

• 尼爾森的啓發式評估十原則 (10 Heuristic)

  中文譯文 [掘金網]

  文章與視頻 [尼爾森網]

• 經典用戶界面交互設計黃金 8 法則 (Eight Golden Rules of Interface Design)

• IBM 設計原則 (Design Principles)

• 國際標準 ISO 9241 Part 10: 對話原則 (Dialogue principles)

4.2.3 啓發式評估法的實施步驟

1. 招募評價人員

至少3個專家: 好比產品可用性工程師, 用戶界面設計師 (不能夠是界面設計者本人)

2. 制定評價計劃

事先制定好評價界面的哪些部分; 依據那個原則進行評價;

3. 實施評價

每一個評價人員單獨進行評價. 以網站爲例, 既能夠從首頁開始, 按層次依序訪問; 也能夠假定幾個任務, 而後再執行任務的過程當中發現問題; 也能夠在輸入項中輸入一些異常值; 或者改變使用環境 (界面分辨率, 網絡速度, 不一樣的瀏覽器等)

尼爾森推薦, 第一次檢查界面的流程是否正常, 第二次詳細檢查各個界面是否存在問題

通常 2~3 天內能夠完成單獨的評價, 網站通常一個小時評價一個頁面, 手機大概一小時評價一個任務

4. 召開評價人員會議

通常持續 3~4 個小時, 首先請評價人員表明彙報評價結果, 其餘評價人員一邊聽報告, 以便隨時就本身是否也發現了相同的問題或者發現了其餘問題發言.

5. 總結評價結果

產品可用性問題列表, 配上界面截圖, 界面流程圖等, 造成簡單的報告

4.2.4 啓發式評估法的侷限性

• 查出的問題過多

• 專家費高

• 注意事項

  不以我的偏好, 而應以理論依據進行評價. 能夠不拘泥於啓發式評估原則, 但必須明確評價遵守的依據

  評價的目的不是單純的挑錯, 更應該給出一些建議

  當出現意見不一致時, 與其把時間浪費在爭論上, 不如使用實驗的方法的出正確的結論

4.2.5 專欄: 認知過程走查法

基於人類的認知模式進行檢驗的方法——認知過程走查法 (Cognitive Walkthrough).

認知過程走查法是基於界面流程圖和用戶認知模型之一的 "探索學習理論" 尋找問題. "探索學習" 指的是事先不閱讀用戶手冊, 不接受任何相關培訓, 在使用的過程當中學習使用方法.

用戶探索學習主要包含四個步驟:

1. 設定目標: 設定用戶要達成什麼目的 (任務或子任務)
2. 探索: 用戶在用戶界面裏探索究竟該作什麼操做
3. 選擇: 用戶爲了達到目的, 選擇他認爲最合適的操做
4. 評價: 用戶分析操做後的系統反饋, 判斷任務是否正常進行.

讓評價人員 (從用戶的角度出發) 回答如下四個問題, 來發現致使用戶混亂或使用戶產生誤解的地方:

1. 用戶是否知道本身要作什麼?
2. 用戶在探索用戶界面的過程當中是否注意到操做方法?
3. 用戶是否把本身的目的和正確的操做方法關連到一塊兒了?
4. 用戶可否從系統的反饋中判斷出任務是否順利進行?

📌 案例: 呼叫轉移認知過程走查

呼叫轉移的正確步驟:

1. 用戶在與對方通話中的狀態下, 按住 CLR 鍵 > 此時屏幕上顯示 "通話保持中" .
2. 用戶撥出要轉移的內線號碼 > 此時屏幕上顯示內線號碼併發出撥號音
3. 用戶在與內線通話中的狀態下, 按 HLD 鍵 > 轉移操做完成, 返回待機界面

4.3 什麼是用戶測試

4.3.1 用戶測試體驗記

惠子的故事

4.3.2 用戶測試的概要

4.4 具備表明性的測試方法

4.4.1 發聲思考法

Think Aloud

觀察用戶發言與操做的重點, 要落在

1. 有效性問題: 用戶是否獨立完成了任務
2. 效率問題: 用戶在完成目的的過程當中, 是否遇到了不知所措的狀況, 或者須要用戶反覆考慮, 作了不少無效操做的狀況.
3. 滿意度問題: 用戶是否有不滿的情緒, 是否又讓用戶不舒服的界面

注意並不侷限於發現 "有效性問題, 效率問題, 滿意度問題" , 更要弄清楚爲何會致使上述結果.

4.4.2 回顧法

Retrospective Method

對用戶的提問在操做完成以後進行, 可是缺點比較多. 通常若是在操做過程當中, 向用戶提問會對操做產生較大的影響時, 採訪人員就會在操做完成以後, 使用回顧法補全想要的信息.

4.4.3 性能測試

Performance measurement

性能測試屬於總結性評價, 原則上會安排在項目前 or 項目後. 性能測試參與人員較多, 至少40~60人. 一次性能測試會測試多個用戶界面, 經過對比競爭產品 / 多套方案 / 改版先後方案的數據, 就能進行客觀評價了.

通常評估一下幾個方面:

• 有效性: 任務完成率, 有幾成用戶能夠獨立正確地完成任務

• 效率: 完成任務的時間, 操做步驟數, 鼠標點擊數

• 滿意度: 主觀評價, QUIS, SUMI, WAMMI 等問題模板 >

用戶調研之問卷製做指南 [標點符]

用戶交互滿意度量表 QUIS [標點符]

SUS 量表與問卷設計

4.5 用戶測試的基礎理論

4.5.1 產品可用性的理論基礎

若是想要作用戶測試, 至少先要作出值得測試的界面 (有原型, 作過啓發式評估)

4.5.2 用戶測試的參與人數

尼爾森的 5 人能發現 85% 的問題的學說

可是該學說也存在漏洞, 沒有反應問題的嚴重程度, 解決了這5我的發現的問題, 難道就能說該界面達到了 85 分了嗎?

4.5.3 專欄: 比較調查是失敗的根源

A 有 40 個問題; B 有 60 個問題, C 有 30 個 問題. C 必定是最好的麼? 有可能 3 個都是 0 分

4.6 用戶測試的實踐基礎

4.6.1 招募

急募! 關於食譜的訪談招募參與者!

40歲左右的女性, 平時會作飯, 平時會使用電腦, 使用智能手機的人優先

地點, 秋葉原; 日期和時間, 下週內您方便的時間; 所需時間, 約一小時; 酬金 600 人民幣

聯繫方式: XXXXXXXXX

4.6.2 設計測試

設計任務 (Task)

訪談指南 (Interview Guide)

試點測試 (Pilot Test)

4.6.3 實際操做

4.6.4 分析與報告

記錄了用戶行爲和發言的資料稱爲協議 (Protocol) , 記錄完成收, 挖掘其中的可用性問題, 分類整理, 並判斷問題的嚴重程度

4.6.5 時間與費用

招募: (2 周) ; 同時進行測試設計 (1 周)

實際測試: 2~3 天 (2 人一天)

分析和報告: 1~2 周

費用: 2 萬人民幣 / 人 / 小時

4.7 推薦 DIY 用戶測試

4.7.1 輕量化趨勢

敏捷開發, 1~4 個星期爲單元進行短時間開發迭代

4.7.2 DIY

4.7.3 二八定律

把注意力放在決定了 80% 價值的 20% 的元素上

4.7.4 DIY 基本原理

六度空間原理: 充分利用人脈

利用平常用品

原始的分析方法: KJ 法 (Affinity Diagram)

對話高於報告

4.7.5 用戶測試的失敗案例

4.7.6 專欄: 低成本用戶測試的發展

Steve Krug

<點石成金: 訪客至上的網頁設計祕籍> <Don’t make me think>

<妙手回春: 網站可用性測試及優化指南> <\Rocket Surgery Made Easy>

• 按期 (每個月 / 每日一次), 反覆地進行小規模 (3 個參與者) 的測試
• 要求相關人員參與觀察用戶測試
• 解決方案永遠沒有最好, 只有更好

第五章 用戶測試實踐篇

5.1 招募

5.1.1 招募準備

具備表明性的用戶, (被認爲) 有能力使用該產品完成任務, 通常能夠將招募條件精簡到 30 字左右

如下舉例:

[二手車網站] 正在考慮買二手車的 20 歲左右的青年男女

[婚戀網站] 準備結婚, 且在市中心工做的未滿 35 歲的女性

[防盜服務] 孩子是初中生, 住在郊區獨棟樓房的全職家庭主婦

[車載導航儀] 開低檔或中檔汽車, 住在郊區的中老年人

5.1.2 利用人脈

5.1.3 抓住一切機會

5.1.4 招募的訣竅

5.2 設計 DIY 測試

5.2.1 設計任務

任務示例:

[DVD 錄像機] 收看錄好的電視節目

[稅務網站] 作最後的稅務申報

[交通換乘app] 搜索公交車, 地鐵等的最後班次

[ 商品活動信息網站] 申請參加某化妝品的活動

[多功能數字一體機] 準備 10 分會議資料的複印件

[餐飲信息網站] 搜尋能夠開年會的飯店並預定

[車載導航儀] 去某遊樂園

[保險公司網站] 汽車保險的預估

[保健設備] 確認三個月來體重的變化

• 把精力鎖定在主要任務上

能夠從產品的研發目的角度出發, 來理解主要任務是什麼

• 從用戶的角度出發

某房地產信息網站的開發團隊把 "購買一手房" 看成了任務, 可是實際上用戶是不可能在網站上買房的, 網站主要是爲了手機房產信息, 查看本身感興趣的戶型資料等等, 以後用戶會親自看方, 在和售樓處的銷售員當面溝通後再購買. 測試任務能夠是 "申請參觀本身感興趣的房產」 .

• 明確起點和目標

用戶測試中最重要的地方就是 "用戶是否能夠完成任務", 所以要明確 "目標」 是什麼.

• 劇本化

實際使用時, 用戶會有本身的離有和目的, 再測試中, 要追加一些假設的狀況背景, 把任務潤色成故事. 好比, 假設你所工做的部門要召開一次歡送會, 恰好有你來負責準備工做, 請使用該網站尋找能夠開歡送會的地方.

5.2.2 準備實際檢查工具

5.2.3 製做訪談指南

• 測試大綱

序曲: 錄像許可, 簽定信息保密協議 NDA

事前訪談: 詢問用戶背景及任務相關內容

事前說明: 向用戶說明發聲思考法, 並對設備作簡單的操做練習

觀察任務的執行

過後訪談: 感想, 主觀評價, 指望

尾聲

• 訪談示例

5.2.4 進行試點測試

能夠找同事或者朋友測試, 目的是爲了發現用戶測試中的問題. 實際用戶測試時, 所用時間大概爲 Beta 測試的 1.5 ~ 2.0 倍.

5.2.5 專欄: 其餘與任務有關的內容

• 簡易任務的設計方法

任務必需要有目標, 不少時候, 定義目標就是定義目標頁面. 好比用手機發短信, 目標頁面就是顯示 "短信發送成功" 的頁面. 而任務就能夠在該目標頁面以前加上 "請" 字, 在這裏任務就能夠設置爲 "請發送短信」 .

• NG 任務集

請您在接下來的時間內, 隨便使用這個網站

任務必需要有目標

今每天氣特別好, 您的心情也很好吧, 這種心情特別適合......

用戶測試是要設置環境 (場景, 先後關係) , 可是心情和環境不一樣.

請 "定位" 一下店鋪

不可使用用戶界面術語

請先輸入本文, 而後以短信形式發送給 A 先生

任務應該只包含最終目標, 不能夠包含完成的步驟

請閱讀商品 A 的說明書, 若是對它感興趣的話, 請購買它

一樣, 心情是很是曖昧的東西, 做爲任務, 只要指示 "請購買商品 A" 就足夠了.

• 任務的本質

5.3 簡易實驗室

5.3.1 測試地點

5.3.2 測試設備

5.3.3 錄像方法

Camtasia Studio

Silverback

AmaRecCo

5.3.4 專欄: PinP

在圖像中再顯示一個小圖像 Picture in Picture (PinP)

5.4 訪談

5.4.1 不提問, 不回答

用戶問 "這個按鈕能夠按嗎?" , 採訪人員能夠反問 "您以爲能夠嗎"

5.4.2 實況轉播

您如今在看什麼?

您如今在想什麼?

您如今在作什麼操做?

你以爲接下來怎麼作比較好?

這是您想要的結果嗎?

您以前以爲會變成什麼樣子?

您以前爲何會這樣想?

您如今以爲怎麼樣?

5.4.3 過後詢問

您剛剛在 XX 界面作了 XX 操做, 能說一下爲何這麼作嗎?

其實就是回顧法

5.5 觀察

5.5.1 增長 "目睹者"

儘可能讓有話語權的人來觀察用戶的操做, 至少讓每一個觀察人員參加三場以上的測試. 若是隻參加了一場, 很容易只根據着一位用戶的言行決定產品的設計, 這還不如徹底不參加觀察.

5.5.2 觀察的禮儀

打招呼, 不注視, 不發聲, 不介入

5.5.3 觀察的技術

用戶測試中, 只須要觀察 "在什麼頁面發生了什麼" , 以及當時 "用戶 說了什麼" 就足夠了. 另外, 觀察不是分析, "應該把這個標籤顏色改的更亮一些" , 這是分析的結果, 而不是觀察的結果.

5.5.4 專欄: 用戶真的喜歡優惠嗎

用戶測試的參與者是從不少註冊會員中挑選出來的, 對他們而言, 網絡就是賺小錢的地方. 這些人平時就但願能從互聯網上得到儘量多的好處, 即便是執行任務, 這種想法也不會改變.

用戶測試中, 不能對用戶言聽計從, 由於意見會因環境的變化而變化, 並且很容易受到我的屬性的影響. 不要由於 5~6 個用戶說 "我對優惠信息抵抗力很弱" , 就在本身的網站裏堆滿了優惠廣告.

5.5.5 專欄: 發聲思考的理想與現實

5,6 分析

5.6.1 張貼

• 記錄下來的內容不該該是所謂的 "注意點" , 而是觀察到的 "事實"
• 從用戶的角度出發進行記述

5.6.2 映射

項目界面打印出來貼在牆壁上, 再把觀察到的數據貼在對應的位置上

某個特定頁面裏貼的卡片特別多, 那確定是有問題的

5.6.3 影響度分析

一次的測試中, 最多羅列出 10 個要解決的問題點

——史蒂夫 . 克魯格

• 問題性質

從 "效果問題 > 效率問題 > 滿意度問題" 的順序來測評問題性質

• 發生頻率

通常經過 "一我的, 幾我的, 幾乎全部人" 來劃分, 好比 5 人的例子能夠劃分爲: 1 人, 2~3 人, 4~5 人

5.6.4 專欄: 任務完成情況一覽表

能夠發現哪些任務被發現了不少問題

◯ : 用戶獨立完成任務, 且其中基本爲發生混亂或繞了彎路.

▲ : 雖然完成了任務, 可是期間饒了彎路, 或者被觀察到在操做過程當中又出現困惑的狀況, 另外, 也包含用戶表達了強烈不滿的狀況.

× : 用戶被認爲未能獨立完成任務.

5.7 再設計

5.7.1 交談比文檔更值得重視

敏捷開發宣言: 工做的軟件高於詳盡的文檔

最具備效果並富有效率的傳遞信息的方法就是面對面交談. 可是能夠作一份 "最低限度」 報告, 具有任務完成一覽表, 映射結果清單, 附帶優先級的問題點列表等必要元素, 大概 2~3 頁 A4 紙, 最後添加上映射結果的照片.

5.7.2 解決問題

有 10 個問題並不意味着要有 10 個對策. 若是能深刻分析每一個問題的內部構成, 就可以作到一個對策解決多個問題點.

5.7.3 反覆設計

設計解決方案 > 測試 > 迭代設計解決方案 > 測試 > 迭代解決方案 > 測試 > ......

5.7.4 專欄: 小變動帶來大成果

• IME 手寫文字輸入
• 傾斜 13 度
• 海外郵寄的 "您的" 和 「他們的「

5.7.5 專欄: 頭腦風暴法

嚴禁批判, 自由奔放, 量比質重要, 歡迎搭便車

可視化, 嚴禁跑題, 每次一人發言

5.8 隱私與倫理

5.8.1 我的信息保護

5.8.2 倫理上的責任

5.8.3 專欄: 不要輕易測試

第六章 超越 UCD, 走向敏捷 UX 開發

6.1 推薦非瀑布型 UCD

6.1.1 瀑布型與敏捷開發流程差別

類型 A : 各個步驟按順序進行

類型 B : 各個步驟以首位部分迭代的方式進行

類型 C : 多個步驟以重疊的方式同時進行

6.1.2 溝通方式的差別

6.1.3 "慢慢地" 差別

6.1.4 敏捷開發與 UCD

6.2 敏捷開發的潮流

6.2.1 敏捷 UX 簡史

6.2.2 敏捷 UX 的原則

• 由內至外

不開發多餘的功能, 從對用戶最有價值的核心功能開始開發, 慢慢擴展到可選功能上

• 平行推進

開發和 UX 設計同時完成, 平行軌道法

• 輕裝上陣

減小複雜的流程和大量的文檔

6.2.3 敏捷 UX 的理論基礎

敏捷開發理論

UCD : 用戶爲中心的設計

UCD : 使用爲中心的設計 <面向使用的軟件設計> , 從用戶使用案例 (用戶故事) 到用戶界面的設計流程理論

敏捷開發 + 用戶爲中心的設計 + 使用爲中心的設計 = 敏捷 UX 開發模式

6.3 使用敏捷 UX 開發

1. 思考產品的概念是什麼 (爲了誰, 作什麼)

能夠先作個簡單的調查, 遊擊調查 (Guerrilla Research) . 記住絕對不要問 "您想要什麼" , "您須要什麼" , 而應該深刻探求 "有什麼地方讓您困惑」

2. 有了範圍以後, 能夠研究解決方案了

頭腦風暴, 尋找新的創意

遊戲風暴 (Game Storming)

3. 立項前的概念測試

立項前, 通常要對創意進行驗證. 通常經常使用的方法是, 製做故事板和模型, 進行投票, 或者在網站上投入家的產品廣告確認用戶反應. 另外在創意達到用戶承認的程度以前, 須要反覆進行調查, 構思, 檢驗.

Elevator Pitch

4. 組織團隊

敏捷開發通常都是自組織化的多功能型團隊, Scrum 團隊

5. 創建臨時虛擬角色 (Pragmatic Personas)

敏捷開發的 UX 項目並不具有製做正式 Persona 的充分數據, 所以, 先基於已知信息來定義用戶角色, 以後再對該用戶進行擬人化, 生成臨時的虛擬角色

6. 經過用戶故事 (User Story) 定義需求

以虛擬角色爲主語, 用相似 "XX 是誰, 他想幹什麼, 出於什麼目的" 這樣的短文章, 把需求分割成許多小的特性, 以小故事的形式記錄在卡片上

7. 預估各類各樣用戶故事的做業規模

不使用具體的 (人/月) 做爲計量單位, 而是用故事點 (Story Points) 來衡量工做量的多少, 故事點是一個相對度量單位，用於表示完成某項工做所需的全部工做量的估算結果.

預估工做主要使用計劃撲克的遊戲形式來進行的.

什麼是故事點 [Scrum中文網]

什麼是計劃撲克 [archimetric]

其餘敏捷估算的方法 [簡書]

8. 決定用戶故事的實現順序

利用用戶故事映射 (User Story Mapping) 二維表, 綜合考慮各功能之間的相互做用, 市場變化等與產品相關的各類因素, 來作出決策

用戶體驗地圖徹底繪製手冊 [優設]

用戶故事地圖之起牀故事 [簡書]

9. 開發

1~4 周左右的迭代期, 迭代期內儘量實現有限的用戶故事, 開發團隊的做業進展狀況會在任務面板 (Task Board) 上更新. 同時用戶界面應與與開發同步進行, 能夠利用草圖板 (Sketch boards). 製做好原型以後, 應當即利用用戶測試進行檢驗

6.3.5 專欄: RITE 法

Rapid Iterative Testing and Evaluation 快速迭代式測試和評估