在敏捷的開發環境中, 一個 sprint 的時間通常都不長, 可能是 2 週, 或者是 1 週, 因此很多人會覺得, 要進行易用性測試 (usabiity testing) 是一件非常難的事情, 因為沒有足夠的時間來進行這個活動.
在這篇文章中: A 6-Hour Usability Test in an Agile Environment, 作者介紹了他如何在六小時內進行易用性測試. 作者是對 web-app 的產品進行測試, 確認是否比前一版本好用.
10 AM: 規劃
a. 決定要用什麼工具:
作者選擇使用 Userzoom, 一種沒有主持人的遠端易用性測試工具
b. 決定要測什麼:
因為時間有限, 作者只專注在關鍵的設計改變, 而非選擇一堆功能或是發散的使用群組.
c. 選擇參與測試的使用者
d. 決定要測試的動作是那些
e. 決定要度量什麼 (動作是否完成, 花多久完成, 滿意度)
f. 準備前測的問題
g. 準備後測的問題
11 AM 建構測試
根據前面這些資料, 把他們建立到 Userzoom 上面去
12 PM 進行模擬測試
先找內部某人來模擬考, 看看是否要修正一些題目或是步驟.
12:30 PM 資料收集
作者從 http://www.measuringu.com/blog/blog.php 去找人參加這次的測試. 或者從 http://www.usertesting.com/ 中買了一些人來參與測試.
午餐用完後, 與試者已經完成測試, 並且相關資料也收集完畢
2:30 PM 分析
分析資料
觀看錄影帶
4 PM 歡樂時光
如果資料顯示使用者都還算滿意, 代表我們的設計是往正確的方向前進, 這樣我們就可以把有限的開發資源放到別的地方.
由作者的方法看起來, 個人有些感想
1. 縮小要驗證的範圍勢必要的. 畢竟時間有限, 我們無法有足夠時間驗證大規模的功能.
2. 對 UT 工具, 方法, 和度量要很熟悉. 時間只夠花在要測試的東西上面, 可能沒空讓你研究 UT 的相關資料.
3. 買人來參與易用性測試是必要的. 有時候要臨時找人來測試, 是一件不容易的事情. 有時候也需要花錢來買人來做帳, 找出我們所需要的資訊.
人家說台上一分鐘 台下十年功, 看起來如果要快, 必須要基本功扎實, 才能讓時間花在受測系統上. 似乎沒有什麼捷徑啊!!
參考資料:
A 6-Hour Usability Test in an Agile Environment
全站熱搜
留言列表
