昨天談到，UI/UX 是很重要的，雖然功能可能都正常，都有滿足需求，但是可能因為 UI/UX 的不良設計導致讓人選錯紀錄對象、看錯單位，或以為資料已經存好了。當我們發現這些問題之後，接下來要做什麼？我認為不能停在「介面要清楚一點」，而是要回頭看需求：我們到底有沒有寫清楚，遇到這些情況時，軟體應該怎麼做？

Day 8 談的是把使用者需求寫成可以查證的軟體需求。當時很容易先想到順利完成的流程（Happy Path）：選一位家人、輸入體溫、按下儲存，然後看到紀錄。但在 Day 10 的風險分析和昨天的介面檢查之後，我們知道事情不一定會照這個順序走。使用者可能忘了切換對象，資料可能缺少單位，網路可能在送出時中斷。這些不是規格寫完後才「順便處理」的小事；有些情況會改變紀錄的意思，甚至讓人相信一筆其實不存在或不屬於這個人的資料。

先問：出問題時，系統要留下什麼結果？

假設需求只寫「使用者可以新增家庭成員的體溫紀錄」，工程師確實能做出新增功能，測試也能確認按下儲存後出現一筆資料。但這句話沒有回答：沒選對象能不能送出？單位沒填怎麼辦？連按兩次會存幾筆？畫面說「完成」時，資料是只在手機裡，還是真的同步到伺服器？

補邊界條件時，先把問題分成三類：

• 第一類是資料能不能被正確理解，例如數值有了，單位卻不明。
• 第二類是操作會不會落在錯的對象或時間，例如切換家人後，表單還留著上一人的資料。
• 第三類是失敗與重試後會留下什麼，例如網路逾時，使用者不確定有沒有存成功，又按了一次。

每一類都要寫出能看見、能檢查的結果。「避免輸入錯誤」太籠統；「未選擇紀錄對象時，不建立紀錄，並在送出位置提示先選擇對象」就清楚得多。

延續昨天的家庭紀錄案例

昨天的例子裡，照護者記完爸爸的體溫，接著想記媽媽的數值，卻忘了切換頁面。昨天我們問的是：畫面有沒有讓人看出目前在記誰？今天要再往前一步：如果表單開啟時已經帶入爸爸的名字，切換對象後，未送出的數值該保留還是清空？送出前是否能核對對象？資料真正寫入時，又要以哪個對象為準？

只在畫面上加一行姓名，並不能保證資料會存到正確的人名下。需求還要約束寫入行為：表單顯示的對象與實際儲存的對象必須一致；切換對象後，不能默默沿用上一人的待送出資料。這個教學案例先選擇清空未送出的數值。真正產品也可能先詢問是否保留草稿，但要依實際使用流程決定，不能靠文章替所有產品定一種做法。

同一筆體溫還可能遇到單位問題。若數值有了，單位卻缺失，軟體不能自己猜它是攝氏還是華氏，再把它放進趨勢圖。需求可以寫明：單位不明時不建立可用於趨勢的有效紀錄，並告訴使用者哪個資訊需要補齊。若產品允許保留原始資料，也應把「暫存但不可判讀」與「有效紀錄」區分清楚。

接著是儲存。假設按下送出後網路中斷，畫面不能只給一個「完成」。它要讓使用者知道目前是哪一種狀態：尚未存入、已存於本機但未同步，或已成功同步。若使用者重試，需求也要定義如何避免同一次輸入變成兩筆紀錄。否則「請再試一次」這句提示，可能反而帶來新的問題。

這張表不是要把所有例外一次列完，而是示範一種寫法：從具體的失敗或誤用情境出發，寫出預期行為，再想好如何查證。測試通過能證明軟體依規格處理這些情境；使用者能不能看懂提示、在壓力下做出正確選擇，還需要另外透過預期使用者與使用情境評估。

小結

寫需求時，我們常把「可以完成什麼」寫得很清楚，卻漏了「做不成、做錯或做到一半時會怎樣」。Day 11 幫我們找到介面可能讓人誤解的地方；今天則把這些發現轉成軟體必須做到的行為與可以查證的結果。當對象、單位、時間、保存狀態和重試結果都說得清楚，團隊才有辦法檢查：這項功能除了能用，出錯時是否也不會悄悄留下令人誤解的紀錄。