前一篇提到的 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 同等喊反清復明的情況下，能靠自己的力量扭轉多少才是重點。
