Google IO – UX research Practice

Agile UX Research Practice in Android text 敏捷式開發 – UX 研究方法 (資料來源:Google Developers)

 

一直很想寫一些真的會用到、簡單又好操作的 UX 方法論,覺得 Google分享的這些方法實在是很實用,以下由google介紹的方法,都不需要龐大的人力和時間,很適合新創公司/團隊來執行。完整影片:https://www.youtube.com/watch?v=6MOeVNbh9cYt=937

1.Heuristic Evaluation 啟發式評估 (量化評估) (所需人力:一位研究員,時間:兩小時up)

簡單來說,就是從易用性原則來衡量一個產品的好壞,這些所謂的衡量,會受到每個人專業及觀點上的差異,而產生不同見解。這是一般業界常見的做法,因為省時又省人力成本,但是必須注意的是,此方法沒有辦法面對真實的使用者,呈現的評量結果也會受到研究員背景的影響,這是此研究法較不客觀的原因,但是確實可以幫助你瞭解自己的產品以及競爭對手的產品。

  • 研究步驟如下: {1.設定可量化問題(EX:競爭產品的操作設定頁面需要花多久時間?) -> 2.訂定衡量指標(EX:頁數、點擊次數、輸入文字的次數、loading 時間、有多少令人困惑的文字語言…) -> 3.展開團隊觀察與研究(EX:和產品經理、設計師、stakeholders等人,一起針對提出的項目討論) -> 4.彙整各方針對設定指標的看法 -> 5.調整畫面再開發,以節省大家時間}

sharing-ownership-of-ux.jpg

[圖片來源:uxmatters]

2.RITE – Rapid Iterative Testing Evaluation 快速反覆測試法 (所需人力:一研究員 + 一位設計師 + 六位受測者,時間:兩天up)

此方法論最初是由微軟的一位UX研究員所建立,適用於需要反覆測試、不斷優化的原型設計,非常接近傳統的易用性測試。

  • 研究步驟如下:
    {1.快速收集回饋 -> 2.製作原型,召集團隊 -> 3.展開測試研究 -> 4.每修改一次,針對每位受測者,再反覆執行測試。}
  • <兩天方法>:
    Day one: 以V0.1測試三位使用者 (A/B/C),測試後立即針對 issues 進行修正,產出V0.2。
    Day two: 以V0.2測試三位使用者 (D/E/F),測試後立即針對 issues 進行修正,產出V0.3。
    …. continue the procee until the product achieves perfect!
    此方法有許多優點,尊循敏捷式開發流程、測試真實使用者 ; 且因為需要在短時間內針對每一項問題找出解法、達成共識,將有助於團隊默契的培養。因為此測試著重在介面的調整,反覆優化也能引領團隊更重視介面設計的細節,並思考解決方案。

anime_scrum_overview_small[圖片來源:scrumprimer]

3.Cafe Study 咖啡廳研究 (所需人力:一研究員 + 一位助理 + 十八位受測者,時間:一天up)

Google非常流行的易用性測試方法,快速又真實。因為是訪問真實生活中忙碌的人們,所以往往只有幾分鐘時間去測試一兩個情境,導致實驗結果非常寫實。測試問題如:「你知道如何分享照片嗎?」「你知道設定完成的下一步會是?」此研究法適用於較小且獨立的功能(喝咖啡的人應該也不想被長時間打擾吧)。

124999520_71n

圖片來源:星巴克(荷蘭阿姆斯特丹)]

  • 研究步驟如下: { 1.易用性測試問題設定 -> 2.準備好各式 Prototypes & several devices -> 3.去咖啡廳/賣場(公共空間)尋找有意願受訪的人,花五分鐘訪問他們 -> 4.實驗結果如:總計訪問了21個人(使用90種不同的原型)5.測試結果如:毫無一人在解鎖後有點擊 widget。}

4.Pulse Study (所需人力:一研究員 + N位觀察員 + 六位受測者,時間:一週up)

整合上述研究方法,應用於Scrum,run sprint plan(每週一次),持續監督產品的健康品質,

  • 研究步驟如下: 在此之前,要先找好適合的六位 “目標使用者”,以進行之後的易用性測試。 { 1.Scrum Meeting: 決定本週測試項目為何? -> 2.決定測試方法、安排測試項目/內容 -> 3.準備好 Prototypes -> 4.向三個人測試 (A/B/C)、列出bugs、整理backlogs -> 5.再向三個人測試 (D/E/F)、列出bugs、整理backlogs。}

每一位使用者只花一小時測試/受訪,只花“一小時”訪問會讓整個過程更加聚焦,每一次測試結束都會發現問題、bugs、或是新的使用情境,並將這些結果整合到 Sprint planning 中,整體而言此方法非常彈性且敏捷,研究方法可以依照產品屬性/測試內容做調整,不受限制。此研究方法,很適合搭配 Sprint planning、mockups、demos,進行開發。此為一整合型的研究方法。

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s