大型公共服務平台的分眾設計，關鍵不是替每種身分各做一個網站，而是讓使用者一進來就確認「這裡有我要辦的事」，再用任務帶他走完流程。以KYART光沅創意參與設計的財政部電子發票整合服務平台為例，同一個平台要服務營業人、消費者、專業代理人、受捐贈機關或團體及政府機關5類使用者，我們的做法可以濃縮成三句話：身分當入口提示、任務當主幹、手機當預設情境。
5種使用者共用一個平台，最大的難題是什麼？
最大的難題是：使用者不一定知道自己屬於哪一類。消費者想設定載具、查中獎，營業人要處理發票，受捐贈機關要看捐贈資料；但一位開小店的老闆，下班後同時也是消費者。Nielsen Norman Group談分眾導覽時就提醒，分類若彼此重疊、名稱又用內部術語，使用者得先花力氣猜「網站把我歸在哪裡」，還會擔心別的分眾裡藏著更適合自己的資訊。
所以在這個專案裡，我們沒有把分眾做成彼此隔開的子網站，而是把身分當成「快速篩選」：選了某個身分，相關服務往前排；但任何人都能隨時切換，也能直接用任務名稱或搜尋找到功能，不會被關在某一扇門後面。
分眾設計為什麼要以任務為主幹？
因為使用者來平台是為了辦事，不是為了認識組織架構。手機條碼的說明與申請、載具設定、中獎資訊這類高頻任務，我們把它們放在最容易觸及的位置，用直白的標籤說明「可以做什麼」，再把同一任務的說明、申請與常見問題收在同一條路徑上，減少使用者在不同頁面之間來回比對。
這也呼應英國政府數位服務(GDS)設計原則中的「Start with user needs」與「Do the hard work to make it simple」：背後的申報、驗證與資料交換再複雜，前台都應該替使用者把步驟整理成一條清楚的路。
分眾是為了讓人更快找到自己，不是把人分進不同的房間。
手機優先，在大型平台裡要顧到哪些細節？
結論是：把「通勤途中單手操作」當成預設情境，逐一檢查每個畫面。電子發票的使用場景大量發生在手機上，這個專案我們特別重視行動版體驗，類似規模的平台，我們會用這幾項當檢查清單：
- 可點擊目標至少符合WCAG 2.2「2.5.8目標尺寸(最小值)」的24×24 CSS像素，常用操作再留足間距，降低誤觸。
- 表單分段呈現，一次只問必要欄位，錯誤訊息就出現在出錯的位置，並說明怎麼修正。
- 捨棄過度裝飾，文字與按鈕維持清楚對比，讓全年齡層都辨識得出來。
這些規則我們會寫進設計系統的元件規範，讓前端互動與Vue開發團隊在不同頁面重複使用時，品質不會走樣。
公開數據要怎麼設計，民眾才看得懂？
先決定「民眾想回答什麼問題」，再決定圖表形式。平台整合了愛心溫度計、發票中獎與兌領獎分析、觀光景點消費熱度、消費通路發票統計、所得房價消費分析等數據主題。我們的原則是一張圖只講一件事，標題直接點出要看的重點，讓一般民眾不必懂統計也能讀出趨勢，需要深入研究的使用者則能再往下細看。
這套分眾設計方法，也適用在內部系統嗎？
適用，而且更需要。我們在大型內部資訊系統的整合設計裡，同樣常遇到一個後台要服務承辦、主管、稽核與外部廠商等多種角色。「身分決定預設、任務決定路徑、元件規範守住一致性」這套思路，從對外服務平台到前後台整合都成立；差別在於內部系統的權限控管與資安要求更嚴謹，需要在設計初期就和開發、雲端維運團隊一起把角色與權限訂清楚，而不是上線前才補。
簡單從來不是少做，而是我們先把複雜的部分扛下來，使用者才能輕鬆。
參考資料：
KYART作品：財政部電子發票整合服務平台(kyart.com.tw)
財政部電子發票整合服務平台(einvoice.nat.gov.tw)
Audience-Based Navigation(nngroup.com)
Government Design Principles(gov.uk)
Understanding SC 2.5.8: Target Size (Minimum)(w3.org)
