最近整理一份現場系統的使用回饋，內容看起來都不是什麼驚天動地的大功能：日期能不能用日曆選、清單能不能搜尋或排序、數字小數位不要太長、報表能不能匯出、某個預設值可不可以先留空。很瑣碎，甚至有點像待辦清單。
但我越來越覺得，真正會決定內部系統好不好用的，常常就是這些小事。
現場不會照著你的流程慢慢操作
工程師在開發企業系統時，很容易把流程想成一條乾淨的路：先選單據，再填數量，再確認，再送出。每一步都有明確欄位，每個欄位都有資料來源，狀態也都在資料庫裡定義好了。
可是現場使用不是這樣。
現場的人通常是在一堆干擾裡操作系統：旁邊有人問問題，機台在跑，資料可能晚一步才同步，手上可能還有紙本或其他工作要顧。他們不會想欣賞你的資訊架構，也不會想理解欄位命名背後的 domain model。他們只想快速找到現在要處理的那一筆，確認數字沒錯，按下去，然後繼續工作。
所以當使用者說「工單太多不好找」時，表面上是搜尋功能，實際上是在說：系統沒有幫我縮短決策路徑。
當使用者說「日期最好可以直接選」時，表面上是 date picker，實際上是在說：不要讓我把腦力浪費在格式輸入上。
當使用者說「小數點太多」時，表面上是顯示格式，實際上是在說：我只需要能判斷工作的精度，不需要看到資料庫把浮點數尾巴全攤開。
內部系統的 UX，很多時候是資訊密度的控制
做 SaaS 或消費產品時，UX 常常會談視覺、動線、轉換率。但企業內部系統有另一種很現實的 UX：資訊密度。
同一個畫面到底要顯示多少資料？哪些欄位要直接露出來，哪些可以收起來？排序預設依照時間、狀態、急迫程度，還是使用者最常處理的順序？搜尋要支援代號、日期、批號、關鍵字，還是全部都要？
這些決定看起來不炫，但它們會直接影響每天的操作成本。
一個清單如果沒有好的排序和篩選，資料越多就越像雜物間。功能沒有壞，資料也沒有錯，但使用者還是會覺得難用。因為他要花太多時間在「找東西」，而不是「完成工作」。
我現在看這類回饋，會先把它們分成幾種成本：
- 尋找成本：找不到資料、清單太長、缺搜尋或排序。
- 輸入成本：日期格式、預設值、欄位太多、要刪掉不需要的內容。
- 理解成本：欄位語意不清楚，例如兩個數量看起來很像，但代表的業務意義不同。
- 驗證成本：數字位數太長、缺少彙總、沒有匯出，使用者很難交叉檢查。
- 交接成本：資料只能留在系統裡，無法產出 CSV、報表或連結給其他角色。
這樣分類之後，需求就不只是「加一個功能」。它會變成一張可以排優先順序的改善地圖。
欄位語意比欄位名稱更重要
這次回饋裡，我特別在意的是「某兩個數量差在哪裡」這類問題。
在系統設計裡，我們很容易以為欄位名稱已經足夠清楚。資料表有欄位，API 有 schema，前端有 label，看起來一切都合理。但對使用者來說，如果兩個數字都像是「可以做多少」或「已經做多少」，那它們就會在操作時互相干擾。
欄位語意不清楚，後果通常不會立刻爆炸。它比較像慢性病：使用者每次操作都多猶豫一秒，主管每次看報表都多問一句，工程師每次追問題都要回去查資料流。久了之後，大家會說「這個系統很難用」，但其實難用的根源不是畫面，而是語意沒有被產品化。
好的企業系統不只是把資料顯示出來，而是把資料放在使用者能理解的工作脈絡裡。
如果某個數量代表理論值，另一個代表現場可執行值，就不要只靠兩個相似的名詞硬撐。該補說明就補說明，該改名稱就改名稱，該在畫面上呈現計算來源就呈現。內部系統不是考試，不需要讓使用者猜題。
預設值也是一種產品立場
另一個很小但很典型的回饋，是「某個欄位預設空白就好，不要讓使用者還要多刪一次」。
這種需求很容易被低估。工程師可能會想：多按一次 delete 有差嗎？
有差。
如果這個動作一天只做一次，可能沒差。如果一天做五十次，一個月做一千次，那就很有差。更重要的是，預設值會暗示系統期待使用者怎麼做。錯的預設值會讓使用者不斷和系統對抗：系統先填一個東西，使用者再把它刪掉；系統先假設一種情境，使用者再修正成另一種情境。
久了之後，使用者會形成肌肉記憶，但那不是好的肌肉記憶，是被迫繞路。
我會把預設值視為產品設計裡很重要的判斷：如果大多數情境需要某個值，就預填；如果不確定，寧可空白；如果不同角色有不同習慣，就讓系統記住上一次選擇，而不是用開發者腦中的預設情境套所有人。
匯出不是附加功能，是工作流出口
很多內部系統做到最後，都會遇到「能不能匯出 Excel / CSV」這件事。
工程師有時候會覺得：都已經有系統了，為什麼還要匯出？是不是又要回到人工整理？
但從管理流程看，匯出不一定是退步。它常常是工作流的出口。
資料在系統裡是結構化的，但人與人之間的協作不一定都在同一個系統裡。現場要交班、主管要彙整、會議要討論、其他部門要對帳，這些情境未必都適合直接登入同一套後台。CSV、報表、連結，都是把系統資料帶到下一個工作場景的方式。
所以我不會把匯出視為「使用者想偷懶」。更準確地說，使用者是在告訴你：這個系統目前還沒有覆蓋完整工作流，中間有一段需要被攜出、分享、核對或歸檔。
這時候要問的不是「要不要給匯出」，而是：
- 匯出的對象是誰？
- 他要拿去做什麼決策？
- 需要明細還是彙總？
- 每天固定產出，還是需要依條件產出？
- 匯出後有沒有版本、時間、來源可追溯？
這些問清楚，匯出功能就會從「多一顆按鈕」變成資料治理的一部分。
把抱怨翻成設計語言
技術主管在面對使用者回饋時，最重要的工作之一，就是不要只照單全收，也不要防衛性地反駁。
使用者說的通常是症狀，不一定是解法。他說要搜尋，可能其實需要更好的預設排序；他說要匯出，可能其實需要固定日報；他說欄位看不懂，可能其實是業務語意沒有被整理；他說按起來很煩，可能是預設值和實際流程不一致。
我們要做的是把抱怨翻成設計語言，再翻成工程可以執行的規格。
這也是我覺得企業系統有趣的地方。它不像做一個漂亮 landing page，可以很快用視覺抓住人。企業系統的價值常常藏在很無聊的細節裡：少找十秒、少刪一次、少問一句、少匯整一份重複報表。
這些小改善單獨看都不性感，但累積起來，就是使用者願不願意每天打開系統的差別。
漂亮畫面當然重要，我也喜歡乾淨的 UI。但在現場系統裡，真正的 UX 往往不是從漂亮開始，而是從尊重使用者每天重複一百次的小動作開始。