第一輪 UAT 開始，什麼請況都會出現，使用者如何操作真的是很難預期。

第一批人開始操作後，有一張單據從申請、審核一路走到最後，按下結案時卻出現伺服器錯誤。

原本預計該互斥按鈕，卻可以同時勾選、選完專案沒有帶入使用者、流程走到最後無法結案，這些功能疏漏都要及時修正。

接著有人提出新的做法：把單據流程畫出來，讓使用者知道目前走到哪一步；再把不同狀態的單據分類，統一放進新的頁籤。

另一個看起來很細的問題也被提了很多次：網頁瀏覽器的 icon 沒有去背。

第一輪 UAT 同時帶回三種聲音：會卡住工作的功能疏漏、使用者真正想要的新功能，以及開發者容易略過的畫面細節。

一張單據，要經過好幾個人的工作

DAP 服務超過 100 位使用者。有人提出權限申請後，單據還會經過主管覆核、預算審查、執行主管分派、執行人處理，最後回到申請人確認。

第一輪 UAT 由熟悉各科作業的人進行。他們知道每一張單應該送到哪裡、誰要接手、畫面該顯示什麼狀態，也知道什麼資料必須跟著單據往下走。

UAT 準備時，我把兩輪驗證整理成 13 個功能情境。第一輪開始後，我把檢查單位往外拉，沿著一張單據的完整旅程往下看：

申請人填單
  ↓ 互斥選項是否真的只能選一個
主管與流程人員審查
  ↓ 目前狀態、下一位處理人是否清楚
執行人收到單據
  ↓ 選完專案後，使用者與申請資料是否帶入
執行人處理
  ↓ 單據是否進入正確分類
申請人確認與結案
  ↓ 最後一步是否真的完成

每一個箭頭都是可能的斷點。

先修會卡住人的功能疏漏

第一類回饋指向原本功能的疏漏。

同一組按鈕有互斥規則，勾選 A 後，B 應該直接停用；當時的畫面仍讓兩個選項同時存在。使用者勾選專案後，系統應該帶入相關使用者，畫面卻沒有顯示。前面那張無法結案的單，也屬於同一類。

這類問題會讓資料錯誤、操作中斷，或讓整張單停在最後一步。它們要先修，修完後再用同一個情境重跑。

使用者走過流程，才會提出下一步

我還在記錄功能疏漏時，同一輪 UAT 已經開始出現新功能建議。

第一個建議是把單據流程視覺化。申請人送出後，可以直接看到目前停在哪個步驟、正在等待誰，以及後面還有哪些階段。

第二個建議是替單據分類。待處理、進行中、已完成的單據可以統一整理，再用新的頁籤切開。使用者進到單據中心後，不必在同一張長清單裡找自己的案件。

這些建議讓 DAP 從「完成一張申請」繼續往前走。使用者還需要掌握進度，也需要整理每天要處理的單據。

被回饋很多次的，是一個沒有去背的 icon

第一輪還有一個很細的觀察：瀏覽器中頁籤的 icon 沒有去背。

單據仍然可以往下走，功能也能操作。那塊背景卻一直留在畫面上，而且被不同使用者回饋了很多次。

這件事很容易被開發者排到最後。使用者每天看到的是整個畫面，icon、欄位文字、狀態名稱都會影響他對平台的感受。多人重複指出同一個細節，也代表它已經明顯到會打斷注意力。

同一個畫面會被使用者反覆打開，一個細節也會被看見很多次。UAT 讓我知道，功能正確和使用感受需要一起收尾。

我把「完成」的終點往後移

第一輪 UAT 後，我檢查一項功能時，會沿著單據多看幾步：

• 按鈕規則與資料帶入是否正確。
• 下一位處理人是否收到完整資料。
• 使用者能否看懂進度並找到自己的單據。
• 最後一位處理人能否結案，申請人能否收到結果。
• 被多人指出的畫面細節是否完成調整。

以前的情境常停在「按下送出，看到成功訊息」。現在的完成點會寫到最後一個角色。頁面、JSON 與按鈕仍要驗證，單據也要走完整條路。

你可以做一次跨角色走查

挑一條會經過 3 到 5 個角色的流程，請熟悉作業的人陪你走一次。每個交接點都留下紀錄：

# Role-based Walkthrough

- 情境：
- 起點：
- 完成點：

| 角色 | 收到什麼 | 要做什麼 | 應看到的狀態 | 交給誰 | 實際問題 |
| --- | --- | --- | --- | --- | --- |
| 申請人 |  |  |  |  |  |
| 審核者 |  |  |  |  |  |
| 執行者 |  |  |  |  |  |

走查時先把問題原樣記下來。缺陷、規則、介面與文件的分類，可以等情境走完後再處理。這樣比較不會為了現場討論修法，漏看後面的交接。

第一輪結束，問題回到開發端

前面的工程檢查確認畫面與輸出，第一輪 UAT 補上各科實際接單與作業的視角。參與 UAT 的同事操作 DAP，我負責把他們遇到的問題帶回開發流程。

第一輪回饋最後形成三條待辦：功能疏漏要立即修正，新功能建議要確認範圍，畫面細節也要逐項收尾。距離 7 月 31 日上線剩不到一個月，這些問題要重新送回開發流程。

Day 23，我會整理這批回饋如何變成可追蹤的修正任務。