敏捷開發和傳統開發最大不同之處, 是以疊代的方式, 每次交付一些東西, 快速得到回饋, 然後再調整方向. 因此在 agile UX 中, 我們的重心就會從循序地大批次處理, 轉換成小批次的交付以及協同合作.
在傳統 UX 中, 有個項目叫做易用性測試, 它會透過用戶的使用, 來評估產品的使用經驗. 它可於產品前期設計, 或者產品中期改進時進行, 但是這是配合瀑布式開發的做法. 那在敏捷開發時, 這樣的測試該如何調整呢? 這篇文章中, 作者提出了他們的做法, 就讓我們來看看他們的一些建議:
1. 為大於其細
每次找 3 個人測試. 以前在 waterfall 時, 5-8 人是比較理想的數字. 但是在敏捷流程中, 易用性測試的重點, 是要搬開路上的大石頭, 而不是要確保任何細節都正確無誤. 所以要先確認核心流程是否正確, 讓我們可以早點修正.
此外, 也因為只對 3 個人測試, 所以所需時間會比較少. 以前可能要花 1-2 天, 才能完成 5-8 人的測試, 現在可能只需半天就可以做完. 所以你可能不見得需要專職的研究人員, 或許只要有人每週可以支援 1-2 天, 就可以完成準備, 測試以及整理報告的工作.
2. 每週都進行
每週可以找一天來進行易用性測試. 最好是每週都是同一天. 讓你的團隊, 相關的利害關係人, 以及被邀請的測試人員都知道是哪一天, 這樣他們就容易配合你的節奏.
也因為這樣的固定節奏, 開發團隊和 UX 人員可持續洞察使用者的反應, 大家在下次疊代的 planning meeting 中, 就會比較容易做出正確的決策.
3. 準備好就展示
只要你有些想法, 你就可以找人來測試. 不管他是已經寫好的程式, 或是 wireframe, 還是 mockup, 都可以展示給使用者看, 讓他們給你回饋. 這些都會比空口說白話好多.
4. 邀請每個人
為了讓測試結果能夠放到下一個 iteration 中, 關鍵是要讓團隊和組織能夠認同你的測試. 最有效的方法, 就是讓團隊成員, 產品經理, 以及相關的利害關係人能夠直接參加你的易用性測試.
為了要能讓他們參加, 你必須要確保他們是很容易加入這個會議. 尤其是可以讓不同地區的人也能加入. 因此像是 WebEx, GotoMeeting 等工具, 是非常需要的. 讓他們可以從各地加入, 一起觀察, 一起討論.
5. 快速回報
當你做完測試後, 你要盡快和你的團隊分享這個資訊. 這時候你不需要精美的報告, 或者是神奇的簡報, 只需用個 email 或 wiki 等等就可以. 內容裡面要包含簡單的摘要結論, 告訴大家你找到的客戶的痛點.
這樣做有兩個目的: (1) 你的團隊可以很快根據客戶的回應調整方向 (2) 可以跟大家講, 雖然你腳步移動很快, 但是還是都有去真實世界驗證這些做法是否正確.
當然啦, 這些只是其中一種做事的方式, 你可以有你自己的做法. 但是要記住, 你要著重的是 outcome, 而不是 output, 這樣去做 UX 才會合乎 agile 的精神.
參考文獻
5 Effective Ways for Usability Testing to Play Nice with Agile
全站熱搜
留言列表
