空狀態設計，指的是畫面「沒有資料可以顯示」時該呈現什麼。在大型系統裡，同一句「查無資料」背後至少有三種完全不同的原因：還在載入、真的沒有資料、或是權限與系統出了問題。Nielsen Norman Group把「傳達系統狀態」列為空狀態的第一條準則，我們在專案現場的體會也一樣：分不清原因的空白，最容易讓使用者以為系統壞了。
為什麼設計稿裡常常少了空狀態？
因為設計稿多半用「資料填滿」的理想畫面在溝通。我們在驗收現場很常遇到這一幕：承辦人點進剛開通的新模組，表格一片空白，第一句話是「是不是還沒接好？」其實功能完全正常，只是還沒有任何案件。那一刻缺的不是功能，而是一個把話說清楚的畫面。
大型系統的空狀態設計，可以分成哪幾種？
我們習慣在設計系統裡把空狀態拆成三類，各有固定的元件與文案規則，這也和IBM Carbon設計系統的分類方式相近：
- 第一次使用：說明這裡之後會出現什麼，並給一個「新增第一筆」的主要動作。
- 操作後沒有結果：例如搜尋或篩選條件太嚴，放一個「清除篩選」，比只寫「查無資料」有用得多。
- 錯誤或權限不足：用白話說明原因與下一步，例如該向誰申請權限，不要只丟一串錯誤代碼。
交給工程師時，要多交代什麼？
結論是：每個列表、圖表與儀表板區塊，都要附上三種空狀態和載入中的樣子。前後端整合時，我們會和工程師先約定API要能區分「0筆」與「錯誤」，否則畫面再怎麼設計也分辨不出來。無障礙方面，空狀態要直接取代原本的表格，不要留一個空表格給螢幕報讀器；搜尋後動態出現的結果訊息，則依WCAG 2.2的4.1.3「狀態訊息」準則，用role="status"讓輔助科技讀得到。
空白不是沒有內容，而是系統在跟使用者說話的時刻。
在KYART光沅創意，我們把空狀態當成和主畫面同等重要的交付項目。使用者第一次打開系統時看到的，往往不是滿版的資料，而是這一頁空白；把它說清楚，信任就從這裡開始。
參考資料：
Designing Empty States in Complex Applications: 3 Guidelines(nngroup.com)
Empty states pattern – Carbon Design System(carbondesignsystem.com)
Empty States – SAP Fiori Design Guidelines(sap.com)
Understanding Success Criterion 4.1.3: Status Messages(w3.org)
