服務標準
本標準定義了採用 gov.tw Design System 的數位服務應達到的品質基準。每一條標準都對應到設計原則中的一項或多項原則，並提供具體的評量方式。
這些標準參考了 GOV.UK Service Standard、WCAG 2.2 及台灣《資通安全管理法》等規範，並根據台灣政府數位服務的實務條件調整。
1. 理解使用者及其需求
對應原則：以使用者為中心
團隊必須深入理解使用者的任務、情境與痛點。不是從機關想提供什麼服務出發，而是從民眾需要完成什麼事出發。
要求：
- 在設計階段進行使用者研究（訪談、觀察、易用性測試），涵蓋不同族群
- 建立並維護使用者旅程圖（User Journey Map）
- 定期以真實使用者驗證設計假設——至少在重要改版前進行測試
- 記錄研究發現並讓團隊成員皆可取得
2. 解決使用者的完整問題
服務應解決使用者的完整需求，而非只處理單一機關負責的片段。如果民眾的一個任務橫跨多個機關，服務應盡可能整合，避免讓使用者自行銜接。
要求：
- 從使用者的任務出發定義服務範圍，而非從機關權責出發
- 跨機關的流程應有明確的銜接機制，減少使用者重複提供資訊
- 服務的起點和終點以使用者的認知為準——從「我想做什麼」到「事情辦好了」
3. 確保所有人都能使用
對應原則：無障礙與包容性
公共服務不能排除任何人。無論是否有身心障礙、數位素養高低、使用什麼裝置或網路環境，所有人都應能順利完成任務。
要求：
- 符合 WCAG 2.2 AA 標準
- 所有功能可用鍵盤操作，焦點順序合理且可見
- 色彩對比符合 4.5:1（一般文字）/ 3:1（大文字）
- 在主流螢幕報讀器（VoiceOver、NVDA）中測試通過
- 頁面在 200% 縮放下仍可正常使用
- 使用語意化 HTML，互動元件提供正確的 ARIA 屬性
- 以 axe-core 進行自動化無障礙檢測，CI 中零錯誤
4. 讓服務簡單易用
對應原則：降低使用者負擔
服務應盡可能簡單。複雜的法規和流程是政府的責任，不應轉嫁到使用者介面上。
要求：
- 每個表單欄位都有存在的必要——能省略的就省略，能自動帶入的就帶入
- 使用清晰的語言，避免法律術語和行政專有名詞
- 任務流程提供明確的進度指示
- 錯誤訊息具體說明問題所在及修正方式
- 在不同裝置（桌面、平板、手機）上皆可正常操作
5. 確保安全與隱私
對應原則：以使用者為中心
服務必須保護使用者的個人資料，並遵循台灣《個人資料保護法》及《資通安全管理法》。
要求：
- 僅蒐集完成任務所必要的個人資料
- 向使用者明確說明資料的用途與保存期限
- 傳輸與儲存使用適當的加密措施
- 進行威脅模型分析，識別並緩解安全風險
- 制定資安事件應變計畫
6. 組建跨領域團隊
服務的設計與營運需要多元專業的協作，不應只由技術人員或只由業務人員主導。
要求：
- 團隊至少涵蓋：使用者研究、設計、前端開發、後端開發、內容編輯
- 團隊成員能在整個服務生命週期中持續參與，而非專案結束即解散
- 決策過程納入設計與使用者研究的觀點
7. 採用敏捷工作方式
對應原則：資料驅動的持續改善
以迭代方式開發服務——從小規模開始，根據回饋持續改進，而非一次規劃、一次建置、一次驗收。
要求：
- 以 2–4 週為一個迭代週期
- 每次迭代有明確的目標和可衡量的產出
- 根據使用者回饋和數據分析調整優先順序
- 持續部署（CI/CD），讓發布成為日常操作
8. 定義成功指標並公開數據
明確定義服務成功的衡量方式，並讓數據驅動決策。
要求：
- 定義核心指標：任務完成率、使用者滿意度、錯誤率、平均處理時間
- 建立數據追蹤機制，定期檢視（至少每月一次）
- 將效能數據適度公開，接受公眾監督
9. 選擇合適的技術
服務應採用成熟、開放、可維護的技術，避免供應商鎖定。
要求：
- 優先選用開放標準和開源技術
- 技術選型考量長期維護成本，而非僅考量初始開發
- 避免對特定廠商或私有技術的深度依賴
- 基礎建設支援水平擴展
10. 使用並貢獻共用資源
優先採用設計系統提供的元件、模式與 token。當現有資源不足以滿足需求時，透過治理流程貢獻新的解決方案。
要求：
- 使用 gov.tw Design System 的 design token 和元件
- 新增的元件或模式透過 RFC 流程 提案回饋
- 程式碼以開源授權發布，其他團隊可直接複用
11. 維運可靠的服務
服務上線後必須持續維運，確保可用性與效能。
要求：
- 制定明確的維運計畫，包含監控、告警、事件應變
- 服務可用性目標至少 99.5%
- 頁面載入時間：首次內容繪製（FCP）< 2 秒、可互動時間（TTI）< 5 秒
- 制定災難復原計畫並定期演練
- 依賴的第三方服務有備援方案
如何使用本標準
本標準適用於所有採用 gov.tw Design System 的新建數位服務，以及進行重大改版的既有服務。
各團隊應在以下階段檢視服務是否符合標準：
| 階段 | 重點 |
|---|---|
| 探索期（Discovery） | 第 1、2 條：是否理解使用者需求、是否定義了正確的問題 |
| 原型期（Alpha） | 第 3、4、5 條：原型是否無障礙、易用、安全 |
| 測試期（Beta） | 第 6–9 條：團隊組成、工作方式、指標定義、技術選型 |
| 上線期（Live） | 第 10、11 條：是否使用共用資源、維運計畫是否到位 |
| 持續營運 | 全部 11 條：定期回顧，持續改善 |