昨天談動效,把「介面看起來如何」這條線收了尾——過去這段時間我們走過排版、色彩、間距網格、設計系統、無障礙,一直到動態的節奏與轉場,全都在回答同一個問題:怎麼把介面做得順眼、做得專業。但漂亮不等於好用。一個轉場流暢、對比合格、元件一致的介面,使用者照樣可能卡在第二步、找不到按鈕、看不懂欄位在問什麼。今天把方向轉過來:不再問「我這樣做好不好看」,而是問「我怎麼知道使用者到底用不用得起來」。這就是使用者研究與可用性測試——把設計從「我覺得」變成「我看到」。
📖 學
質性 vs 量化:回答的是不同問題
研究方法先分兩大類,別混用。**質性研究(qualitative)**回答「為什麼、怎麼發生」,樣本小、觀察深,產出的是理由與行為模式——你看著一個人卡住,聽他喃喃自語,就知道問題出在哪。**量化研究(quantitative)**回答「有多少、多常、多快」,樣本大、可統計,產出的是數字與趨勢——任務成功率 62%、平均花 48 秒。兩者不是誰比較高級,而是階段不同:設計早期你需要質性去「發現問題」,上線後你需要量化去「衡量規模」。最常見的錯誤是拿五個人的訪談去講百分比,或拿一萬筆點擊數據去猜使用者的動機。
探索性 vs 評估性:先摸清楚,再驗證
另一條軸是研究的時機。**探索性(generative / exploratory)**方法用在你還不確定要做什麼的時候:深度訪談挖需求與心智模型、**田野觀察(contextual inquiry)**看使用者在真實情境怎麼做事、**日誌研究(diary study)**讓使用者記錄一段時間內的真實遭遇。這些幫你定義「該解決什麼問題」。評估性(evaluative)方法則用在你已經有東西(草圖、原型、成品)要檢驗好不好用,主角就是可用性測試(usability testing)。一句話記法:探索性告訴你「做什麼」,評估性告訴你「做得對不對」。
可用性測試怎麼做:任務導向 + 放聲思考
可用性測試的核心不是問使用者「你覺得這介面怎樣」——那只會得到客套話。而是給他真實任務,看他實際能不能完成。做法有幾個要件:
- 任務導向:設計具體任務(「請找出這張訂單什麼時候會到貨」),而不是叫他「隨便逛逛」。任務要貼近真實目標,別在題目裡洩漏答案(別說「點右上角的追蹤按鈕」)。
- 放聲思考(think-aloud):請使用者邊操作邊把腦中想法講出來——「我在找登入……欸這個是註冊還是登入?」這是 NN/g 稱為「頭號可用性工具」的技巧,因為它讓你看見「誤解」發生的那一刻,而不只是結果。
- 主持 vs 非主持:主持式(moderated)由研究員在場,可即時追問、釐清,適合複雜或早期原型;非主持式(unmoderated)用工具讓使用者自己完成,速度快、成本低、能跑較多人,適合驗證明確任務。遠距工具如 Maze、Lookback、UserTesting 讓非主持測試變得容易鋪量。
樣本數迷思:五個人真的夠嗎
「測五個人就能找出約 85% 的問題」——這句話出自 Jakob Nielsen 2000 年的文章,背後是一條數學曲線:每多測一人,新發現的問題遞減,測到第五人邊際效益就明顯下降。但這條規則有嚴格前提,常被斷章取義:它只適用於質性可用性測試(觀察任務完成),而且使用者族群要相對同質。如果你的產品有多個差異很大的族群(例如買家和賣家),就得各族群分別測。它也不適用於量化研究——你要算出可信的成功率,五個人遠遠不夠。實務折衷:每輪測 5 人、快速修、再測 5 人,用多輪小樣本取代一次性大樣本。
引導性問題與觀察者偏誤
研究最容易毀在主持人自己身上。引導性問題(leading questions)會污染資料:「這個新功能是不是很好用?」幾乎注定得到「嗯還不錯」。要改成中性開放式:「你會怎麼完成這件事?」「剛剛那一步你在想什麼?」使用者卡住時忍住別救援、別解釋,沉默是你的朋友。另一頭是觀察者偏誤(observer / confirmation bias):你會不自覺放大支持自己設計的證據、忽略打臉的訊號。對策是任務前先寫下假設、找第二位觀察者各自記錄、優先記「使用者實際做了什麼」而非「我覺得他為什麼這樣做」。
可用性指標:把「好用」變成可比較的數字
質性發現要能追蹤,就需要指標。常用四項:任務成功率(完成任務的比例)、任務時間(花多久)、錯誤數(過程中犯錯次數)、以及主觀的 SUS(System Usability Scale,系統可用性量表)。SUS 是 John Brooke 1986 年設計的 10 題問卷,正反題交錯、換算成 0–100 分,業界普遍以 68 分當基準線(50% 的產品落在其上下)。SUS 的價值在於它標準化——你可以拿改版前後、或和競品比較。記住:指標是用來「衡量改善幅度」與「排優先序」的,不是用來自我感覺良好的。
A/B 測試與研究的分工
A/B 測試常被誤當成可用性測試的替代品,其實兩者分工清楚。A/B 測試是量化、評估性的:它告訴你 A 版和 B 版哪個轉換率高,但不告訴你為什麼——它需要大流量、要有明確的量測指標,適合上線後在既有選項間做取捨。可用性測試是質性、診斷性的:它告訴你使用者為什麼放棄,但樣本小、不能宣稱統計顯著。健康的流程是:先用可用性測試找出「哪裡卡、為什麼卡」,產出候選解法,再用 A/B 測試在真實流量上驗證哪個解法真的贏。先診斷,再放大。
把發現轉成設計決策
研究不落地就是浪費。收尾時把觀察整理成三件事:問題(使用者在哪一步、發生什麼)、嚴重度(影響多少人 × 多痛,決定修的優先序)、建議方向(不是直接抄使用者說的,而是回到問題本質提解法)。用「多少人踩到 + 阻礙程度」把問題排成 P0/P1/P2,別被「最吵的那個聲音」帶著走。最後把它接回設計系統:如果同一類問題反覆出現,該修的往往不是單一畫面,而是元件或模式本身——這時研究就閉環回到我們前幾天談的那套介面基礎。
🧠 記
- 漂亮 ≠ 好用;研究的任務是把設計從「我覺得」變成「我看到」。
- 兩軸分類:質性(為什麼/小樣本深觀察)vs 量化(多少/大樣本統計);探索性(做什麼)vs 評估性(做得對不對)。
- 可用性測試三要件:任務導向、放聲思考、選對主持/非主持模式。
- 「五個人找 85% 問題」只在質性 + 同質族群下成立;實務用多輪小樣本迭代。
- 兩大污染源:引導性問題(用中性開放題)與觀察者偏誤(先寫假設、雙人記錄)。
- 指標四件套:成功率、時間、錯誤數、SUS(基準 68);A/B 先讓可用性測試診斷、再放大驗證。
✍️ 實踐
挑一個你手上正在做或常用的產品,寫出三個任務情境(例如「取消一筆已下的訂單」),找一位不熟這產品的朋友當受測者。全程只做兩件事:給任務、請他放聲思考;你閉嘴記錄——記下他卡在哪一步、講了哪句透露誤解的話、以及他實際點了什麼(不是你以為他該點什麼)。刻意練習忍住不救援,體會沉默逼出真實行為的威力。
測完後把觀察轉成決策:列出所有問題,各標「幾個人踩到 × 有多痛」,排成 P0/P1/P2。挑最上面那一項,寫一句假設(「因為 X,所以使用者 Y」)與一個具體的設計修改方向。若條件允許,讓受測者填一份 SUS 問卷,記下分數當作下次改版的基準線——這樣你的下一輪就有得比。
🔗 延伸學習
- Why You Only Need to Test with 5 Users(NN/g,Jakob Nielsen)
- How Many Test Users in a Usability Study?(NN/g)
- Thinking Aloud: The #1 Usability Tool(NN/g)
- Usability (User) Testing 101(NN/g 入門總覽)
- User Testing: How Many Users Do You Need per Method?(Maze)
💬 問 AI
把你的一段設計丟給 AI,請它幫你設計一場可用性測試腳本,順便當你的偏誤檢查員:
我正在測試一個[產品/功能,例如:外送 App 的結帳流程],目標使用者是[描述族群]。
請幫我:
1. 設計 3 個任務導向的測試情境,任務要貼近真實目標、且不能在題目裡洩漏操作步驟或答案。
2. 針對每個任務,列出主持人可以問的中性開放式追問句,並標出我應該避免的引導性問法。
3. 建議這次該用主持式還是非主持式測試,以及理由。
4. 列出我該記錄的可用性指標(成功率/時間/錯誤/SUS),並說明各自怎麼收。
5. 最後提醒我 3 個最容易犯的觀察者偏誤,以及當場怎麼避免。