柏強的網路探險記

目前基本上是 Rocket Surgery Made Easy 的筆記，加上一些自己的經驗與認知。

Ch1 基礎認知

• 這不是給「以做 Usability test 維生」的人，書中簡化了很多東西，包括可以做的方式、時間、內容等，為了讓大家都可以實戰。
• 簡單說就是「看人家用你做的東西」以
  1. 讓它更好用 （本書的目標）
  2. 證明它好用
• 來的人是參與測試，非「接受測試」。所以一般我們稱其為「受訪者」、「參與者」，不稱「受測者」、「受試者」。測試的主體是網站。
• 本書的東西屬於質性測試，不是為了證明什麼、而是為了找出不好用的地方（以便使其更好用）。
• 到底有沒有用？不用擔心，一定有用，做一次你就知道了。坐在（幾乎任何人）隔壁看他用你的產品，都可以找出使用性問題。
• 大部分嚴重的問題都很容易發現：
  • 大家都看得出來，只是你太靠近了、了解太多，沒發現
  • 又，當然還是有些比較細微、很難發現的問題，但以本書的目的，是先把資源放在容易發現的，多測、常改。
• 多觀察使用者有助你成為更好的設計師，提高設計智商、就像旅行豐富你的人生經歷一般。
• 一般來說，不做使用性測試的常見理由是：
  • 沒時間，所謂的「先求有再求好」 — 其實 DIY 使用性測試不花你很多時間，精煉過的走道測試甚至就都是五分鐘解決、而即便是本書提倡的方式每個測試對象也只花一小時。
  • 「我們已經知道有很多問題了」 — 一方面其實你知道的方式可能跟真正使用者不同，二方面經由測試知道哪些是比較常見的問題，也不錯。也可以設計一些訪談在那些已經知道的問題上，多了解使用者發現這個問題的原因，與可能的解決方案。
• 量化分析可以告訴你訪客在網站上幹嘛，但不能直接告訴你訪客行為的緣由。（按：但，量化分析仍可有效縮減猜測方向、提升分析的精準度）

Ch2 影片

要點

• 照著念，避免錯
• 「我要測的是網站，不是你」要具體說明
• 放聲思考練習
• 中途是可以休息的
• 要提示「會錄影」，簽同意書
• 在受訪者停止發言的時候，就問
• 受訪者找到答案時，也可以問他對於答案的想法

Ch3 簡化

每月一次的理由

• 不要少於一個月一次，養成習慣
• 平衡負擔，「以能負擔的方式，產出所需的結果」
• 「例會」式的排法，讓公司參與的人有預期心理

其他變化

• 敏捷開發：次數增加、人數減少、時間減少
• 測後簡報：隔天其實也可以，不見得要在當日（Bob：個人覺得當日還是比較好的），但為了方便觀察員出席，測試本體在一天內結束還是比較好的。

其他要點

• 如果沒時間把東西做完，就用 Paper Prototype
• 給受訪者的費用約當 USD 50-100，沒錢就送禮物

Ch4 測什麼？

何時測？多早都可以，越早越好，比你以為夠早的時間再早一點。常見問題：

• 還沒東西可以測：即使只是秀設計概念都可行
• 什麼都還不確定是要測什麼：那麼，受訪者可能更願意批評（他們會認知到自己的意見確實可以改變未來）
• 都快改版了，還測他幹嘛：首先改版上線時間可能比你想像中來得晚，但問題現在已經存在；再者，測試舊版可能抓到一些能讓新版參考的問題。

測試的對象

• 測自己的網站
  • 目標：了解目前的錯誤
  • 行動：同時修正目前的版本及開發中版本
• 測別人的網站（對手，或有相同功能的）
  • 給受訪者的任務，就是你想在自己網站上放的功能
  • 可以同一個人做不同網站
  • 訪後簡報時，主軸放在：
    1. 有效、及無效的事情
    2. 可以適用於我們自己網站的事情
  • 測敵手網站可以有效吸引管理者介入，畢竟他們也對別人的狀況有興趣
  • 還有個優點是比較不會有防衛心態
• 測草圖
  • 朋友遇到就測，不用花太多時間，五分鐘足矣
  • 第一步問題是「這是什麼站」，接著是進一步問題
  • 目標：確認網站的概念是否容易理解
• 測互動樣本
  • 目標：測跟導覽相關的東西
  • 「你點選了這個連結，會想看到什麼？」
• 測視覺設計
  • 要求受訪者描述看到視覺設計後的想法
  • 留意主頁面與內頁的樣板有沒有問題
• 實測（上線前網站）
  • 就，實測

Ch5 找人測

問題

• 測誰？（哪種人？）
• 測幾個？
• 怎麼找？
• 如何回饋（付費、送禮物）

是否一定要找「真的使用者」？重要性可能沒有你想像中高：

• 迷思般的共識：「我們不關心本來就不會用我們服務的人」，但使用者可能跟你想像中差別很大
• Domain Knowledge 可能也沒有那麼重要
  • 剛入門的人沒有 domain knowledge，但可能也是目標族群
  • 就算有相關知識，用的詞彙可能也與你不同
• 最嚴重的問題，經常不需要 domain knowledge 也能發現
• 先從所有人都碰得到的問題下手，有必要進一步理解真正使用者時，再做。
• 「非真正」使用者遇到問題的時候，就問你自己：那麼，真正使用者是否也會遇到一樣的問題？

只做三人的理由

• 三人就可以抓到大問題
• 只找三個簡單很多，簡單才能吸引你持續做、多做（而次數跟頻率比單次人數重要太多了）
• 佔用時間較少，比較容易約觀察員，也比較專心
• 四個以上發現的問題可能多到修不完，模糊重點

找人

• 給外包最好
• 聯絡要點
  • 看他們有沒有空
  • 是否真的符合最低需求
  • 告知內容（一小時、會錄影）
  • 回饋方式
• 回信要點
  • 告知交通方式、停車資訊
  • 告知你的（或某人的）電話
  • 有保密條款的話，先附上

其他事項

• 禮券是不錯的回饋方式（比較節省！又有機會找贊助！）
• 萬一有參加者沒出席、觀察員會覺得空下來的時間浪費了，所以原來就要預備候補
  • 沒有先約的話，附近的人，誰都行
  • 或者找親友，有必要時遠端測試
• 同一個網站不要找同一個人重複測（但，一個人測多次不同網站沒問題）

Ch6 測的內容

• 拿紙列出 5-10 項人們來網站想做的事
• 一般 50 分鐘的測試，會花大概 35 分鐘在任務上
• 多準備幾個任務，因為每個人速度不同

怎麼挑？

1. 不做會死的事
2. 讓你半夜嚇醒的事
3. 曾被反應不好用的事

劇本

• 角色描述（「你是 ….」）
• 行為動機（「因為你想要 …」）
• 要做的事（「所以你…」）
• 補述
• 不要含括任何任務提示
  • 別只是把關鍵字打上去
  • 任何介面上會出現的文字都是提示，盡量別出現
  • 「找出有沒有適合你領域的編輯」 看看幫你改文件的人到底了不了解你的領域
• 前測：了解劇本用詞是否準確，不致誤解 （找誰來測都好，公司內的人也行）
• 印出：每張一個任務，避免分心。（不過，給自己及觀察員的，就通通印同一張即可。）
• 不要加上編號，因為有時需要亂跳

Ch7 Checklist

• 一定要好好跟，不能漏掉，跟講稿可混合編排。

雜項

• 不要用「搜尋」功能
• 不要離開這個網站：「不好意思，為了測試，請留在這個網站」