沒有實驗室也能做的可用性測試：新手指南

由FabricLoop團隊  ·  2026年5月  ·  4分鐘閱讀

可用性測試背負著一個不應得的名聲：昂貴又緩慢。一聽到「使用者研究」，人們腦中浮現的是單面鏡、拿著寫字板的主持人，以及長達兩週的時程。那種版本的測試確實存在，也有其用途——但它並不是大多數產品團隊在大多數時候需要的版本。

大多數團隊需要的版本更簡單：五位使用者、一個 Figma 原型或測試環境、一通視訊通話，每場 45 分鐘。做得好的話，這能在產品上線前找出大多數嚴重的可用性問題。持續去做——甚至每個衝刺（sprint）做一次——就能帶來產品品質的複利式提升，這是任何上線後分析都無法複製的。

以下是從零開始執行的方法。

四步驟的測試流程

步驟 1：招募——測試誰，比測試幾個人更重要

對大多數可用性測試而言，五位受測者是恰當的人數。Jakob Nielsen 的研究確立了五位使用者就能發現約 85% 的可用性問題，超過之後效益遞減。在設計過程的不同階段各進行三場五人的測試，比一場十五人的測試更有價值。

招募的條件比人數更重要。與目標使用者高度相符的五個人所進行的可用性測試，會揭露真正的問題；與目標不符的十五個人所做的測試，只會產生雜訊。請定義兩到三項篩選條件——角色、使用情境、對科技的熟悉程度——並嚴格遵守。

對大多數團隊來說，最快的招募途徑是寄信給已同意被聯絡的現有使用者。提供適度的誘因——一場 45 分鐘的測試，£20 的禮物卡就足夠了。目標是在同一週內安排好測試；招募到測試之間間隔越久，缺席率就越高。

步驟 2：腳本——寫情境，而不是指令

最常見的腳本錯誤，是把任務寫成指令：「點選設定，然後前往通知，並把你的偏好改成……」這等於告訴使用者該做什麼，意味著你測試的是他們能不能照著指示做，而不是介面是否直覺。

請改把任務寫成情境：「想像你最近收到太多通知，而你只想在有人直接提到你時才收到提醒。請示範你會怎麼做。」這給了使用者一個真實的目標，讓你觀察他們實際上如何操作——包括他們在哪裡感到困惑。

步驟 3：執行——你的工作是觀看，而不是幫忙

主持可用性測試最困難的部分，是克制想幫忙的衝動。當使用者感到困惑時，每一個直覺都在說要立刻插手、告訴他們該點哪裡。但困惑本身就是資料。努力掙扎的使用者，正在告訴你介面有問題——一旦你介入，就失去了這個訊號。

請使用者在整個測試過程中邊做邊說出想法：「過程中，請隨時告訴我你正在看什麼、在想什麼。」這會產生一連串關於他們心智模型的持續資料。不只要留意錯誤，也要留意猶豫——使用者在點下正確按鈕之前停頓了三秒，即使最後成功了，仍然揭露了設計上的問題。

步驟 4：彙整——歸納模式，而不是引述

彙整這個步驟，是創造最多價值的地方——也是大多數團隊偷工減料的地方。五場測試的原始筆記不是發現。當你以團隊形式進行檢討、依主題將觀察分組，並指派嚴重程度等級時，它們才會變成發現。

在測試當天、觀察還記憶猶新時進行檢討。將問題分成三類：嚴重（使用者無法完成任務）、中度（使用者完成任務，但有明顯困難或錯誤）、輕微（有摩擦但沒有妨礙完成）。嚴重問題必須在上線前修正；中度問題應在下一個衝刺中優先處理；輕微問題則放入待辦清單（backlog）。

用一頁篇幅寫下發現：最嚴重的前三個問題、各自來自至少兩位受測者的證據，以及針對每個問題建議的設計變更。任何需要超過一頁篇幅的內容，都應放在另一份文件。