看不見的細節，為什麼值得？

今天的開發原本很單純：做一個訪客帳號。實作後卻發現，難的是讓它用起來一致、可信。這一整天的折返，讓我更確定：產品的差異，往往來自那些使用者不會主動說出口、卻一直感受到的細節。

一、身分與名稱要一致。一開始我以為 localStorage 放個暱稱就好。等到遇到「訪客是否能轉成正式帳號」「名稱如何同步」「初始化狀態怎麼顯示」這些情境，才知道「一致性」是一個系統性問題。把名稱同步拉回 AuthProvider，用 isInitialized 管初始化，表面上只是消除 UI 的「閃一下」，本質上是在建立信任：系統不跳針、狀態不自打臉，使用者才願意繼續用下去。

二、互動也要有界線。產品評論的設計，我刻意不讓訪客直接留言，而是用「訪客資訊提示框」引導註冊。這個取捨看似保守，目標卻很清楚：保留互動的動機，降低 spam 的風險。同時把 @ 提及從「存名稱」改為「存使用者 ID」，避免改名導致資料斷裂。互動不是越多越好，還得能長期維持整潔與一致。

三、跨頁狀態要一致。晚上整合膚質檢測與通知，又碰到導覽列連結與個人頁檢測卡片的狀態同步問題。選擇用 context 統一狀態，是希望操作結果能符合使用者的預期：使用者不需要猜測系統目前的狀態，介面與資料也會保持一致。可預期是降低認知負擔的第一原則。

四、資料也要有約束。最後重構問卷系統的 API 與資料庫模型，將版本檢查與新格式建立寫成自訂驗證器，要求問題結構一致。這類開發工作，使用者不會注意，也不會立刻覺得驚豔。但它讓維護成本下降、迭代速度提升，避免因版本分叉把團隊的精力消耗在補洞與例外處理上。產品的速度，常常取決於資料是否被良好約束。

為什麼要對「看不見的地方」執著？我也會懷疑：「用戶真的會在乎嗎？」但經驗一再證明：當狀態一致、互動邊界清楚、行為可預期、資料有約束，使用者在流程中更少被打斷，更願意把注意力放在內容本身。這些不被察覺的舒適感，累積起來就是差異。

創業和開發時，有些地方可能一開始沒想清楚，訪客帳號、評論互動、跨頁狀態、資料驗證，今天踩過的每一個坑，都在提醒我：細節不是枝節，它們是系統的骨架。

明天繼續把這些不容易被注意到的細節做好。