Diy Usability Test

目前基本上是 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

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

雜項

  • 不要用「搜尋」功能
  • 不要離開這個網站:「不好意思,為了測試,請留在這個網站」
Creative Commons License
本站文字除特別聲明者外,係採創用 CC 姓名標示-非商業性-相同方式分享 2.5 台灣授權條款授權,利用前請見說明