內部系統不好用，很多時候不是按鈕不夠漂亮，而是資料來源、權限和狀態流程一開始就沒有理清。畫面只是把這些問題顯示出來，不一定是問題本身。
如果資料不知道誰負責、權限不知道誰能改、狀態不知道下一步去哪裡，UI 再怎麼調都會卡。因為使用者真正需要的是知道現在發生什麼、輪到誰、能不能處理。
這篇核心結論
內部系統要先整理資料、權限和狀態，再開始追求畫面細節。否則 UI 只會一直替流程問題擦屁股。
我做內部系統時會先問四件事
系統開工前
- 資料從哪裡來，哪一份才是權威來源？
- 誰能看、誰能新增、誰能修改、誰能刪除？
- 狀態有哪些，每個狀態代表誰要做什麼？
- 如果資料錯了，誰能修，系統要不要留紀錄？
這四題如果沒有答案，畫面一定會越做越複雜。因為每個例外都會變成一顆新按鈕、一個新欄位或一段新說明。
很多畫面問題，其實只是資料問題長出來的樣子
例如列表太亂，可能不是表格設計不好，而是資料狀態沒有分層。搜尋不好用，可能不是 input 位置錯，而是欄位命名和資料格式不一致。權限看起來複雜，可能是角色邊界一開始就沒定。
| 表面問題 | 可能的根因 |
|---|---|
| 列表資訊太多 | 沒有分清主要狀態和補充資訊 |
| 按鈕越加越多 | 流程責任和下一步動作不清楚 |
| 權限一直出錯 | 角色模型沒有先定義 |
權限和狀態要在最前面拆
內部系統最怕做到一半才發現「主管看到的資料不一樣」、「承辦只能改一部分欄位」、「已送出後不能再編輯」。這些都不是小 UI 問題，而是資料和權限模型。
所以我會先畫狀態表和角色表，再做畫面。畫面可以迭代，但資料邊界如果一開始錯，後面每個功能都會被拖下去。
一個判斷方式
如果某個 UI 需要很多說明文字才能讓使用者不做錯，通常代表資料狀態或權限邏輯還不夠清楚。
常見 FAQ
FAQ
- 內部系統可以先做畫面 prototype 嗎？
可以，但 prototype 要拿來驗證流程和資料，不要太早把視覺當成完成標準。 - 權限規則可以後面補嗎？
高風險系統不建議。權限會影響資料結構、API 和 UI 狀態，太晚補會重工。 - 怎麼知道資料來源是否清楚？
如果同一個欄位有多個地方可以改，而且沒有同步或權威來源，就還不清楚。
結論
內部系統要好用，不能只從畫面開始。先把資料來源、權限、狀態和責任邊界排清楚，UI 才能簡單。否則畫面只會越補越亂。
