FindSkin：從命名到體驗，把混亂收回來

這兩天都在跟「膚質分析」這件事纏鬥。原本系統裡有「膚質檢測」、「肌膚分析」、「問卷調查」三種叫法，越看越不順，乾脆全部統一成 FindSkin。結果一改名才發現，牽一髮動全身：API 路徑、資料表、前端組件、token 邏輯都得一起動。commit 的時候我一直在念自己：「當初命名到底在趕什麼？怎麼會放著這麼不一致的東西不管。」還好順手把 API token 的處理重構掉，意外抓到一個埋在 URL 裡的空格，難怪之前測試總有股不對勁。

回頭看問卷流程，沒有進度條這件事說不過去。現在誰還做問卷不給進度？所以加了狀態管理跟進度顯示，提交後自動跳結果頁。前端則把標語做成堆疊，抓重點字句，層次清楚很多。這段時間確實花在 CSS 和排版上不算少，我也不免自問：「是不是又過度設計了？用戶真的在意透明度 0.6 跟 0.7 的差別嗎？」但看見成果那刻，的確覺得值得。

隔天接著把首頁和問卷的介紹區塊重做。之前的文案太像課本，密密麻麻，難怪完成率低。樣式改用 alpha 函數統一透明度處理，視覺舒服很多。接著檢查問卷邏輯，發現有歷史紀錄的用戶在重複登入時會出現詭異狀態，最後在組件裡加了明確的登入狀態與初始化日誌，之後 debug 至少不用猜。順便把後端舊的問卷文件清掉，資料夾瞬間乾淨，心情也跟著清了。

還有一個小洞：後端沒驗證問卷輸入值。於是加了限制，回答必須在 1 到 4 之間；如果有人提交了奇怪的數字，直接記 log，連同用戶 ID 一起留痕，出了問題回頭查就快多了。延伸一併把膚質評估結果整合進 UserProfile，之後要做推薦或是讓用戶看歷史，不用再到處撈資料。

這些看起來都是小改，但做著做著就會懷疑：「這些真的有必要嗎？」我自己的答案是：有。因為當產品開始有人用、甚至越來越多人用，維護成本差就在這些細節上累積。與其等到 production 被抓包再來補洞，不如現在把路理清。

最後，還是留給自己一句提醒：我想做的是一個用起來舒服、說得清楚的產品。這種執著有時候很累，也不一定馬上看見成效，但它讓混亂慢慢退場，讓東西往正確方向走。FindSkin 的這次整理，就是朝那個方向踏實地往前一步。