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

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

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

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

三、跨頁一致的狀態，讓體驗可預期，晚上整合膚質檢測與通知，又碰到導覽列連結與個人頁檢測卡片的狀態同步問題。選擇用 context 統一狀態，不是為了技術的優雅，而是為了「可預期」：用戶不需要猜測系統現在怎麼想，界面與資料說的是同一件事。可預期是降低認知負擔的第一原則。

四、面向未來的資料約束 最後重構問卷系統的 API 與資料庫模型，將版本檢查與新格式建立寫成自定義驗證器，要求問題結構一致。這種工程活用戶不會注意，也沒有即時的「哇感」。但它讓維護成本下降、迭代速度提升，避免因版本分叉把團隊的精力消耗在補洞與例外處理上。產品的速度，常常取決於資料是否被良好約束。

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

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

明天繼續，方向不變：用看不見的執念，換用得見的信任與留存。