可以這樣問
「你按下儲存後，預期會發生什麼？」
「剛才停在這個畫面時，你在思考什麼？」
第 05 課 ／ 用觀察更新需求
用戶調查與需求迭代
帶著第 4 週可在 iPhone 上運行的原型，請別人完成一個核心任務。觀察他怎麼理解、在哪裡停下來，再把發現整理成下一版的改動。
本課流程示意
從假設到回饋，再回到下一版
- 01
寫下假設
痛點 · MVP
Persona · Happy Path - 02
試用與觀察
操作核心任務
說出想法，記錄卡點 - 03
整理回饋
比對原先假設
決定需求優先順序 - 04
開分支修改
與 Agent 小步實作
在 iPhone 驗證 - 05
找新用戶重測
另外兩位測試者
確認改善與新問題
依重測結果更新假設與需求，開始下一輪。
課堂：至少兩人演練 ／ 回家：至少五位符合 Persona 的用戶完成第一輪測試
01 ／ 驗證流程：先寫下預設
你期待誰，解決什麼問題？
- 重新界定痛點
誰在什麼情境遇到什麼困難？現在如何處理？造成什麼成本？寫下一個具體問題，以及需要向使用者確認的假設。
- 檢查 MVP 是否回應痛點
對照原型現有功能：使用者能否從開始到完成核心任務？哪些功能直接解決問題？哪些只是附加功能？標註模擬資料與尚未實作的部分。
- 界定 Persona
描述目標使用者的目標、行為、使用情境、經驗與限制。Persona 先作為待驗證的假設；招募條件要能實際篩選，例如最近曾遇到這個問題。
- 畫出 Happy Path
列出從打開 App 到完成任務、看到結果的正常流程，包含每一步的預期結果。這份流程留給觀察者比對，測試時只給任務情境。
- 準備一句話介紹
用「這個 App 幫助［誰］在［情境］完成［事情］」說明目的。避免先教按鈕位置，讓使用者自行探索。
02 ／ 課堂試用：輪流至少兩人
讓測試者操作，你在旁邊觀察
每位同學的 App 至少由兩人分別試用。測試者拿 iPhone 操作，作者在旁邊觀察並記錄；輪流交換角色，每次約 5–10 分鐘。
- 介紹目的與核心任務
先用一句話介紹 App，再提供任務情境。可以說：「我們想知道這個 App 哪裡需要改善，請照平常的方式操作。」
- 請他說出心中所想 · Think Aloud
請測試者邊操作邊說：「我看到什麼、我想做什麼、我預期接下來發生什麼。」沉默時，用「你現在在想什麼？」輕輕提醒。
- 觀察，先讓他自行嘗試
記下停頓、返回、誤觸、反覆尋找與預期落差。先給探索的時間；若必須協助才能繼續，記下協助的內容與時間點。
- 卡住時詢問他的理解
問「你現在在找什麼？」「你原本預期會看到什麼？」避免提示正確按鈕。不要把不熟悉介面的使用者當成操作錯誤。
- 完成後，用開放式問題追問
問「這個過程哪裡和你平常做法不同？」「哪一步最不清楚？」「你現在怎麼處理這個問題？」「什麼情境下你會用它？」記下具體經驗與原話。
改寫會引導答案的問題
「是不是這個按鈕太小？」→「你怎麼找到下一步的操作？」
「你喜歡這個 App 嗎？」→「它能幫你處理哪一個實際情境？」
課堂互測用來練習方法與發現操作問題。同學是否符合 Persona，要另外確認；若要錄音或錄影，先取得測試者同意。
03 ／ 比對假設，整理下一版
先記證據，再解讀原因
| 預期／假設 | 觀察與原話 | 解讀／待確認 | 下一版改動與驗證 |
|---|---|---|---|
| 儲存後能看見剛新增的作業。 | P01 儲存後回到空白清單，說「是不是沒存到？」並再次新增。 | 可能是目前篩選條件讓作業不可見；需要確認資料是否真的儲存。 | 顯示儲存結果並提供查看入口；重測是否能找到作業且不重複新增。 |
- 對照測試前的預設
痛點是否存在？Persona 是否合適？MVP 是否幫助完成任務？實際路徑與 Happy Path 哪裡不同？標記得到支持、受到挑戰或仍未確認的假設。
- 將問題分組與排序
優先處理阻礙核心任務、造成資料錯誤或明顯困惑的問題，再處理操作摩擦與介面細節。保留測試者代號、出現情境及是否需要協助。
- 形成下一版需求
每個改動寫清楚：要解決的問題、依據、預期行為、驗收條件。使用者提出的功能是線索，先追問背後的需要，再決定解法。
04 ／ 修改流程
開分支修改：Git 指令與 Sublime Merge
以下提供命令列與圖形介面兩種操作方式。選擇你熟悉的一種，完成建立分支、審查差異、提交與合併；兩者使用同一份 Git repository，也可以交替使用。
Sublime Merge ↗ 是圖形化 Git 工具，可以查看分支與 commit 歷史、閱讀 diff，並選擇要暫存與提交的檔案。從官網下載 macOS 版本後，開啟你的 App 專案所在的 Git repository。
- 保留原型基準，建立分支
檢查 Git 狀態並提交這次原型的相關修改後，再建立測試迭代分支。讓前後版本可以比較。
- 引導 Agent 小步修改
提供選定問題、觀察證據與驗收條件。逐次審查 diff、建置並在 iPhone 操作，記下已修正與仍存在的限制。
- 找另外兩位測試者
使用相同核心任務，找沒有參加上一輪的人重測；優先選符合 Persona 的人。比較卡點是否改善、是否仍需協助，以及有沒有新問題。
- 依結果決定後續
把測試結果帶進第 6 週，持續在分支修改功能與設定，並理解 View 結構及 App 架構。第 7 週再建立 PR、Review 與 Merge，加入 SwiftFormat 和 GitHub Actions 檢查。
本週先練習分支修改與測試紀錄；下方保留完整 Git 與 Sublime Merge 操作供查閱，合併步驟銜接第 7 週的 PR 協作實作。
Sublime Merge 操作步驟
- 保留修改前版本
在 Pending changes 檢查相關檔案與差異。使用 Stage file、Stage hunk 或 Stage lines 暫存本次原型的修改，檢查 Staged files，輸入清楚的訊息並按 Commit，例如「保留第一輪用戶測試原型」。
- 建立並切換分支
在目前原型的 commit 上開啟右鍵選單，選 Create branch at commit…，命名為
user-feedback-v2。也可按 macOS 的⌘P，搜尋 Create Branch…。建立後切換到新分支，確認目前分支名稱，再讓 Agent 修改。 - 檢查與提交每次修改
Agent 修改後，在 Pending changes 閱讀 diff；只暫存這次要驗證的修改，確認 Staged files 後 Commit，例如「補上儲存結果與查看入口」。Commit graph 可用來比較第一版與第二版。
- 在 iPhone 重測
從新分支建置並運行 App，找另外兩位使用者完成相同任務。把測試結果對應到 commit，確認觀察的是哪一版。
- 確認改善後合併
先切回要接收修改的主分支（例如
main）。在 Locations 的分支清單對user-feedback-v2開啟右鍵選單，選擇把它合併到目前主分支；確認合併方向後再執行。若出現衝突，閱讀雙方內容並決定保留的結果，合併後重新建置與操作核心流程。
提交、合併都可以在本機完成；若要同步到 GitHub，再執行 Push。回家功課可附上目前分支、commit graph 與關鍵 diff 的畫面。
Sublime Merge 官方入門：分支、提交與合併 ↗Git 命令列操作步驟
先保留原型基準，再建立分支。將範例中的檔案路徑換成實際修改的檔案；若主分支名稱不是 main，使用你的主分支名稱。
git status
git switch -c user-feedback-v2
# 完成修改後檢查差異
git diff
# 暫存本次要提交的檔案
git add path/to/changed-file
# 檢查準備提交的內容
git diff --staged
git commit -m "Improve flow from user feedback"
# 在 iPhone 重測並確認改善後，切回主分支合併
git switch main
git merge user-feedback-v205 ／ 回家功課
找至少五位符合 Persona 的使用者
先寫出招募條件，確認測試者有相關情境或痛點。至少五位目標使用者完成第一輪測試；若課堂測試者符合條件，可計入。修改後，再找另外兩位未參加第一輪的人重測。
- 測試前準備痛點、MVP 對照、Persona 與招募條件、一句話介紹、Happy Path 及任務情境。
- 第一輪紀錄至少五位目標使用者的代號、符合條件的原因、觀察、原話、完成情況與協助紀錄。
- 回饋與需求迭代假設比對、問題優先順序、選定改動與驗收條件；說明接受或暫不處理的理由。
- 修改與重測分支及版本紀錄、iPhone 運行證據、另外兩位新測試者的結果，以及下一步。
五人是這次質性可用性測試的課堂起點，用來找出問題並迭代；不保證找出所有問題，也不足以推論整體市場比例。若有不同 Persona，分別記錄各組結果。
延伸閱讀：五位使用者與質性測試 ↗