前一篇提到的 RITE 就是種「可用性測試」的方法,照傳統的 UX 流程,可用性測試會排在開發後期才製作 Prototype 進行測試,到這階段要修改什麼都太遲了,所以 Lean UX 的作法才會推行用 MVP 執行 RITE。這篇要敘述的就是傳統 UX 做可用性測試的方法。

此外,雖然免洗專案很多,但也很多是需要持續追蹤改版的產品。搞定一回合的專案還會有下一回合要戰,需要透過研究方法去追蹤使用者對推出後的產品有什麼回應,像是「網路分析」。

可用性測試 Usability Testing

以使用者和他們的任務為焦點,找出實際證據,改善介面的可用性。

測試將以任務和情境故事為設計中心,要能反應出典型使用者的目的。不能用任務和情境故事來影響受測者以某種特定方式解決問題,也不能用它來證明產品的規格沒有問題(這反應的不是使用者的目的,而是開發人員的目的)。

任務

需要明確、具體,且反應目標族群的真實目的。

情境故事

為任務設定背景,並提供完成任務所需的額外資訊。

受測者有可能會出現各種反應,觀察者和評估者需要依此找出錯誤或是做得好的部份。

  • 了解任務,但無法在合理的時限內完成。
  • 了解目標,但必須另闢徒徑才能完成任務。
  • 在過程中投降或放棄。
  • 完成任務,但非指定的任務。
  • 出現驚訝或愉快的反應。
  • 出現挫折、困惑,或責怪自己無法完成任務。
  • 指出哪裡有問題或不合理。
  • 對介面或事件流程提出建議。

易用性測試能幫助你出問題點,但不能告訴你怎麼解決問題。即使受測者提出建議,也不見得就是解決問題的方法。

參考:
简单快速的可用性测试 | 网易用户体验设计中心
About Usability可用性测试杂谈
Usability Testing Demystified

網路分析 Web Analytics

讓組織深入瞭解使用者在線上做些什麼、以及為什麼要這樣做的原因。

你必須清楚說明希望用那些資料做什麼?

請盡早把想要評估的目標和意圖清楚表達出來,並和團隊取得共識,實作人員才有辦法用更好的方式架構內容、分析計畫、區分訪客、評估需要哪些商業和流程工具。

網路分析在組織內失敗的原因

其中之一是組織沒有將這些報告公開分享,讓報告中的發現有效傳達出去。組織在審查這類報告時通常會當成「已經發生的事情」而非「我可以做什麼」的依據,所以就變成有做有保祐求心安的擺設。要不就是一次執行改變太多,卻沒制定任何方式追蹤改變的結果。

1. 了解和改善

顧客調查,並用質化分析法交叉驗證,了解使用者意圖,並執行改善計畫。

2. 評估

分析使用者資料、研究使用者生命週期各面向。

3.分析

找出績效指標與內部預期和目標之間的模式和趨勢(關鍵績效指標)。

4.測試

建立假設,用各種實證測試法測試改善成果。

參考:(基本這就是 GA 啊,放一些我覺得有用的流量網站了。)
Google Analytics (分析) 官方網站 - 網頁分析和報表功能 – Google Analytics (分析)
Website Traffic & Mobile App Analytics | SimilarWeb(我滿喜歡這個站的,隨便抓個網址扔進去都可以知道流量排行等資訊。)

心得

可用性測試對 UX 來說根本做到爛,好像 UX 除了不停抓人做實驗之外就沒別的事好做…別忘記統計數據、寫報告、寫文件也是很重要的工作。研究方法整理好幾篇,都要收尾了才發現根本沒提到最後產出的報告文件要怎麼寫。再想想看怎麼訂定…

是說現在網站或 APP 沒有埋 GA 的很少了吧?頂多看一下今天有幾個人來訪、怎麼來、怎麼去,然後看一下整年份的紀錄說一句「很好有進步」就沒了,埋 GA 根本埋心酸。我一直認為沒有把驗收也放入工作項目之內,就像寫完考卷交出去然後不知道自己考得怎麼樣一樣,寫來打發時間嗎?不都說了透過檢討、反省、改良才能有成長,改良在哪裡?改良的依據又在哪裡?

不是有改就會變好啊,很有可能越改越爛啊!不然怎麼會常常聽到改了20次結果回到初稿的燒錢行為?很多事不是 UI/UX 喊一喊就有效,但不喊就絕對沒有用…


本文內容部份取自 設計的方法,這是本 UX 必備的工具書,整理大量的研究、實驗方法,讓 Designer 可以照著做,產出有模有樣的文件。以上是我自己掏摸的心得。

注意,本文所寫內容不應該是一個人的工作,UX 研究都該是由兩人小組、甚至由團隊執行,但業界環境不許可、當公司喊 UX 同等喊反清復明的情況下,能靠自己的力量扭轉多少才是重點。

comments powered by Disqus