為增進機關網站的易用性與親和性，並協助機關規劃網站服務時，更有效率地導入使用者中心設計（User-Centered Design, UCD）理念，本規範參照「政府數位服務指引」及ISO 9241-210[1]之使用者中心設計相關內容，並融合敏捷開發精神，於附錄增訂「使用者中心設計建議」，提供機關人員於規劃網站時，瞭解使用者中心設計內涵與相關流程，並可參考提供之相關案例，研擬使用者需求調查之執行規劃。

什麼是使用者中心設計

　　過去常見在規劃網站服務的過程中，只顧慮到「服務提供者」（例如機關）的任務，並未考慮「服務接受者」（例如民眾）的需求，因而容易產生盲點而不自知。網站設計的目的在於引導使用者完成操作，若操作介面沒有妥善引導使用者的行為時，使用者就會產生困擾與不確定感。

　　使用者中心設計即在設計的過程中，以使用者的需求及體驗為中心的設計模式。在開始設計之前，必須深入了解使用者的能力與限制、洞察使用者的需求；在完成設計之後，必須評估功能與效率是否滿足使用者的期待、產品的互動與操作是否可為使用者所理解與掌控。這些內容應在設計前、後期，從使用者角度進行深入思考與探討，即以使用者為中心的設計思維。

　　在規劃服務或網站之前，不應以「技術規格」為出發點，也不從「機關想達成的任務」出發，而是先了解使用者需求，找出「使用者面臨的困境」與「機關想達成的任務」之間的差異，再思考以什麼樣的技術規格來達成任務目標。

　　換言之，依據不同網站服務的任務及規模，其所需要進行使用者研究的範圍、所需資源（例如預算、時間）都有所不同，建議機關承辦人員在計畫啟動前先進行小規模的使用者研究，可先從3~5位使用者開始調查，建立整個任務的基礎架構。

導入「使用者中心設計」的步驟

 　　依據國際標準ISO 9241-210，使用者中心設計包含：瞭解及確認使用者情境、確認使用者需求、產生符合使用者需求的設計方案、依據需求進行評估、以及(前置的)規劃使用者中心設計程序與(結尾的)符合使用者需求的成品等環節。

　　為協助機關於設計網站服務時，快速地導入使用者中心設計理念，本設計建議聚焦機關網站之操作易用性，搭配實際案例，著重在使用者需求調查及驗證產出成果是否滿足使用者實際需求。步驟如下：

一、定義使用者與利害關係人

1-1 分析任務目標、定義使用者與利害關係人

　　以網站改版為例，網站改版的目標是什麼？為了增加使用數量、服務特定的使用者群體、改善服務流程的流暢程度、或減少業務同仁的負擔？不同的任務目標，所影響的使用者也不同。為了進行接下來的使用者調查，應先排序網站專案要解決的問題，再評估需要研究那些類型使用者，除了使用該服務或網站的一般民眾，可能也包括機關相關的第一線服務人員，只要是會使用到該服務或網站的人員也應一併考慮進來。此外，在服務設計中，有所謂「利害關係人」的概念，專案過程中會出現的各部門負責人員與長官、執行廠商等，皆可能影響專案進行，調查中應盡可能了解主要使用者與利害關係人的真實想法。

　　應列出專案的任務目標、使用者與利害關係人，再依據重要性排列任務目標、列出相對應的使用者類型與利害關係人，可將結果透過視覺化(Visualization)[2] 的方式，協助專案成員以容易理解的方式，釐清利害關係人之間的相互關係，有效分配專案資源。

1-2 製作顧客旅程地圖

　　列出任務目標、使用者與利害關係人後，可參考以下幾種常用的使用者調查方式整理出共同的痛點及面臨的困境，製作任務目標、使用者與利害關係人的「顧客旅程地圖」，並從中進一步定義出需要解決的題目。

• 訪談法（User Interview）

　　訪談（或深度訪談）能比問卷更有脈絡地了解使用者的態度、行為、渴望，而半結構式訪談（Semi-structured Interview）則是最常使用的方式；半結構式訪談在開始前需先設定訪談大綱，但題目及訪談順序可能會依現場實際訪談情況進行調整，通常情況下，建議可從3~5個人次以上的訪談著手。

• 影子觀察法（Shadowing）

　　在不影響使用者的前提下，深入觀察使用者的使用服務完整過程，記錄使用者的行為、情緒、對話。優點是可直接觀察使用者的相關行為，找出使用者沒說出的感受。

　　完成使用者調查後，應將調查結果進行整理，並將其轉化為「顧客旅程地圖」（Customer Journey Map[3]），此為本階段應有的產出文件。顧客旅程地圖能從較全面的角度觀察使用者在使用服務或網站前、中、後的體驗，並看出使用者在各階段遇到的情境與問題，製作顧客旅程地圖時，以時間軸列出各階段的接觸點、行動、情緒、痛點等。 

 顧客旅程地圖：

1-3 進行現有設計易用性測試

• 易用性測試（Usability test）

　　根據國際標準ISO 9241-11[4]的定義，易用性是產品或服務提供特定使用者在特定的使用脈絡與情境中，以效率(Effectiveness)、迅速(Efficiency)、滿意(Satisfaction)完成執行任務的目標。易用性測試經常被用來作為檢驗網站設計是否良好的標準，目的是先檢視既有的網站與服務，其使用者在操作的過程上碰到什麼問題、面臨什麼阻礙。通常會設定任務請使用者執行，並在旁觀察使用者操作遇到的問題。 

　　易用性測試可用來了解提供的服務介面及流程中，是否足以讓使用者完成行動。當資訊傳遞有落差（如文字不易閱讀），就會觀察到使用者產生疑惑，感受到不確定性，操作錯誤甚至放棄使用。

　　執行易用性測試時，建議可採用表格形式紀錄結果，紀錄使用者於各頁面（或階段）之操作過程，並以白色（表示可順利通過）、黃色（表示有疑惑但可通過）、紅色（表示無法通過或操作錯誤）來標示各頁面通過的順暢程度，測試結果即可一目瞭然，了解使用者在哪幾個頁面（或階段）較易遇到問題。

易用性測試文件：

二、定義問題與設計解決方案

2-1 定義各階段需求，研擬對應設計方案

　　此階段為「使用者中心設計」的關鍵階段，並影響下一階段的設計方向及主軸。雖然上一階段已可由顧客旅程地圖看到流程中的問題，但發現問題後，仍應深入挖掘問題背後使用者真正的需求，經由整合並分析獲得的資訊，解讀出獨特的觀點，定義出精準的題目，如此才能避免後續的設計方法有偏差。於此階段機關可搭配使用者經驗(UX)設計專家，以及與使用者共同合作，劃分使用者在各個操作階段所遇到的困難，並定義各項待改善需求的優先次序。

       不同的服務中，使用者會有不同的行為，以申辦服務為例，可從使用者申辦過程中找出下列行為：1.確認需要、2.選擇、3.準備、4.檢查、5.執行、6.進度、7.調整、8.完成。使用者在不同階段可能面臨的問題也不同，以下提供可做為參考的改善建議。

【服務前】

2-1-1協助使用者確認網站所提供的服務內容

以使用者能夠理解的用語介紹服務內容

案例：密西西比州政府提供民眾使用的網站，其文字用語使用民眾日常生活的常見詞句，並加上簡短的文字說明該項目所提供的內容。

2-1-2協助使用者進行選擇

提供明確的資訊，協助使用者選擇適合的申辦類型與方式

案例：以報稅網站為例，原有報稅網站只列出可申報綜所稅的選項，新版報稅網站分析使用者選擇時會碰到的困難後，列出可以協助選擇的資訊來減少使用者進行選擇時所花費的時間。

2-1-3協助使用者完成事前準備

以簡明易懂的方式介紹申辦步驟，協助使用者準備完成服務申辦的資料

案例：網站服務除了「提供文件資料」，更需要「協助了解並釐清內容」；未經整理編排的說明文字可能造成民眾不容易閱讀，建議以視覺化的方式呈現申辦各階段所需的文件資料及執行步驟。

2-1-4協助使用者檢查完備所需資料

提供檢查清單，協助使用者檢查完備所需資料

案例：部分政府服務可能仍需臨櫃申辦，若申辦業務時缺少必備的資料，可能造成無法當下即完成申辦，民眾需要花費額外的時間重新申辦。協助民眾檢查備齊所需的申辦文件，可讓民眾使用政府服務時更便利。

【服務中】

2-1-5協助使用者順利地申辦服務

提供相關參考訊息，協助使用者順利完成申辦資料的提交

案例1：填寫文件時，使用者可能因看不懂表格欄位或未填寫必要資訊，而無法順利完成；提供明確的範例說明做為填寫時的參考，可避免使用者因無法順利完成而產生挫折與焦慮。

案例2：若需要臨櫃申辦，順利抵達受理申辦的地點也可能成為難題；在提供地址資訊時，可提供相關輔助訊息，例如網路地圖服務或建築物外觀照片，可協助民眾儘快找到正確的地點。

【服務後】

2-1-6提供申辦進度查詢

提供查詢，讓使用者掌握申辦進度

案例：使用者完成提出申請的步驟，不代表整個申辦服務的程序也完成，若需後續審查等相關程序，應提供查詢方式，讓使用者掌握申辦的進度。

2-1-7提供便利的補件及資料變更機制

提供使用者便捷與快速的補件及資料變更機制，避免重覆要求補充資料

案例：在合適的情況下，提供使用者透過網路工具提交補件資料的方法，相較於提交紙本文件資料，可節省使用者的寶貴時間，省去不必要的麻煩。

2-1-8通知完成服務申辦

主動協助使用者確認其申辦的服務已完成

案例：主動透過文字訊息(例如SMS)或信函，通知使用者申辦的結果。

2-2 協調團隊，調整需求優先次序與確認方案

       了解使用者在各階段的需求以及可能的改進方向後，下一步可列出這些需求與改進方向相對應的解決方案，建議尋找各利害關係人共同參與討論，以此確認解決方案在執行上的難度、必要性與開發順序。

• 工作坊（Workshop）

　　工作坊是一種適合團隊或多數人共同進行對話、思考、調查、規劃與設計、形成方案、決策等行為的一種方式，並能提出推動的方案、甚至發展成實際的行動。

　　工作坊的實際運作常透過一種比較輕鬆或有趣的互動方式來進行，它的目的主要在於引發參加者的興趣、促進眾人的互相認識與溝通介面、激發參加者的想像與創造力、整合不同意見、形成共識、共同研擬方案等，因此工 作坊不僅是規劃的過程，也是自主表達、學習與成長的過程。

三、驗證與調整

3-1 測試新設計易用性，依結果快速迭代調整

　　此階段應製作設計原型並進行易用性測試，確保新設計有達到改善原設計痛點與困難的目標。此階段的重點在於「快速驗證」，在網站服務設計進入程式開發階段前，應先進行易用性測試，檢驗當前的設計成果，故一開始不需太精緻，先做到能表達服務或網站概念，讓使用者可以理解即可，在快速測試後再進行迭代修正，剛開始時，設計原型的製作形式可以是低擬真的線框稿（Wireframe），再逐漸調整為高擬真的可互動原型（Prototype），例如可點擊互動的網頁原型。

• 以新設計線框稿或可互動原型進行易用性測試

　　線框稿是一種低擬真設計原型，用來呈現設計方案的版面結構、功能、內容規劃，而不強調視覺設計細節。線框稿通常只會使用方框、線和灰階色塊，並使用文字來表示初步的內容（例如圖片、影片等）。目的在於使專案成員可專注於功能面、資訊架構面、使用者體驗、操作流程、使用性及使用者介面等的討論，避免視覺設計的干擾，而無法快速的收集測試回饋。
　　可互動原型可呈現使用者與介面之間的互動，例如說按鈕按下後會出現的操作方式與呈現等，用來模擬設計方案的視覺呈現與體驗。原型可用來對真實的使用者進行測試，好處是可以在專案的前期階段即發現問題並修正，節省許多後期調整的時間與成本。

• 依易用性測試結果快速迭代調整

　　迭代（Iterative）是指在設計的過程中，快速地經歷一個較小規模的完整作業流程，包含需求調查、分析設計、實作和驗證。在一次迭代過程中，僅進行一部分的設計或服務的調整，再依據使用者測試結果，開始新一輪的迭代。

一、說明

本設計原則整合網站設計親和性指標，分為「首頁親和設計」、「任務導向」、「導覽及架構」、「網頁及內容設計」、「搜尋機制」、「服務可信度」等6大原則，定義政府網站設計原則，訂定網站架構、版型設計及內容管理共同規範，以達民眾利用政府網站易用性，提供政府網站管理者設計維護網站時之快速導讀。

二、設計原則

壹、簡介

一、 目的

二、 範圍

貳、網站服務上線交付項目

一、 網站服務上線清單

二、 功能模組清單

三、 相關附屬文件

參、上線及資料移轉作業程序

一、 上線作業程序

二、 資料移轉作業程序

三、 環境需求與資源配置

四、 上線時程與說明

五、 上線驗證作業流程

肆、潛在風險與緊急應變處理

一、 上線影響

二、 緊急因應措施

三、 溝通、支援及訓練計畫

伍、其他

網站服務架構與單元名稱建議：

註：以*標示者代表重要的內容單元，建議可列為網頁的重要元素，放置在更清楚的位置。

外語版網站服務架構建議：

註：以*標示者代表重要的內容單元，建議可列為網頁的重要元素，放置在更清楚的位置。

政府網站資料開放宣告範例如下，由機關擇一適用：

壹、範例一：選用政府資料開放授權條款-第1版(OGDL-Taiwan-1.0)

貳、範例二：選用CC授權條款 姓名標示4.0(CC BY 4.0)

 參、範例三：選用CC授權條款 姓名標示-相同方式分享4.0(CC BY-SA 4.0)

 肆、範例四：選用公眾領域貢獻宣告(CC0-1.0)

一、視覺設計

網站服務的視覺設計，除了提高網站服務的親和性與可閱讀性之外，建議參考以下各項設計參考：

1.定義視覺設計確認的程序。

2.版面上的元素應盡可能對齊，例如運用CSS Grid布局技術。

3.以不同的瀏覽器檢視，包括常見瀏覽器(例如Chrome、Firefox、Edge及Safari等)，搭配各作業系統內建的輔助使用功能（例如文字縮放、明暗主題、高對比或強制配色模式、動態效果多寡設定等），確保網站服務使用者能夠順利瀏覽內容。

4.評估網站瀏覽是否順暢，例如等待網頁下載時間不超過3至5秒，且網頁內容區塊不會隨著資料逐漸載入而大幅改變布局位置。

5.評估頁面長度是否適當，例如不超過螢幕的5倍，或適當編排段落標題及定位書籤，避免使用者瀏覽網站服務時需頻繁捲動頁面。

6.評估網頁列印輸出是否合理正確，例如當網頁無法正確被列印時，建議開發可適配列印的響應式網頁設計。

7.確保沒有圖像的狀況下，亦可正常閱讀網站內容，例如避免僅用圖片表達所有內容，建議以圖文並存的方式呈現網頁。

8.按鈕圖示(Icon)應加註文字，因圖示易讓使用者誤解其功能。除了慣用圖示外，建議按鈕圖示都應加註文字，且與應用程式介面暴露的無障礙名稱相符。

9.全自動區分電腦和人類的圖靈測試(Completely Automated Public Turing test to tell Computers and Humans Apart，簡稱CAPTCHA)之視覺類驗證碼，建議採用具備隱私保護的CAPTCHA替代解決方案，例如 Turnstile 人機驗證。

二、文字樣式設計

文字樣式與連結顯示應採用可讀性高的字型與連結文字，並使全網站具有一貫的文字風格。

1.全站的文字格式使用一致的字型、顏色與尺寸

文字格式係指文字的字型、大小、顏色、段落、縮排、行距等。統一的文字格式可協助使用者快速瀏覽內容。

2.文字應採用足夠的顏色對比，且避免文字重疊在圖形背景上

文字通常以深色(如深灰黑)顯示於淺色(如米白色)背景上，或前景與背景明度對比須明顯，避免影響文字可閱讀性。亦應避免於顯示文字之處配置背景圖片，以避免干擾閱讀，影響親和性與可閱讀性。

3.中文字建議使用系統預設字型或網頁字型(Web Font)[6]

使用系統預設的中文字型可確保文字能在使用者的設備上正常顯示，若需要在網頁上指定的字型，建議使用網頁字型(Web Font)，兼顧網頁上的文字樣式的豐富性及版面呈現的正確性。

4.英文字避免使用中文字型

英文字建議使用系統預設的英文字型或網頁字型，確保文字能正常顯示。若需指定字型格式，建議使用網頁字型為佳。

5.文字大小使用相對尺寸而非固定尺寸

若文字大小使用相對尺寸，使用者就能依個人需求使用，運用瀏覽器的檢視功能，選擇字型大小。預設大小亦應妥善選擇，依不同瀏覽器與裝置呈現來考量。

6.可點擊操作的文字應標示底線，另可搭配不同顏色或游標懸浮效果，以增加辨識。連結項目清楚標示，讓使用者一目瞭然，可提高頁面的可用性。

三、圖片、多媒體設計

圖片與多媒體的設計，應以使用者的角度考量檔案格式、大小、介面及傳輸速度，確保快速下載，清楚顯示。

1.網頁圖片兼顧清晰品質與下載時間

網頁的圖片須注意適當的下載時間，避免佔用過長的等待時間；建議選用JPEG或PNG格式，並避免單一圖檔容量過大（例如調整圖檔壓縮參數或色盤索引以降低檔案容量大小）；利用響應式設計，優先提供使用者瀏覽器可支援的最佳圖片格式，並依照網頁標準設定延遲載入圖片屬性及預先指定圖片長、寬尺寸。

2.多媒體影音內容應預設關閉音效、不自動讀取，且可切換靜音

避免多媒體動畫的音效或網頁背景音樂干擾輔助科技操作，需確保網頁中的預設關閉音效，而由使用者自行決定播放時機。

3.確保多媒體介面可使用鍵盤操作

多媒體介面應提供鍵盤操作，便於身心障礙者感受多媒體介面的方便與互動，提高介面的可用性與可及性。

4.為影像、聲音與多媒體介面提供文字說明為多媒體加上替代文字，以利使用輔具者瞭解資訊內容。

四、表單設計

表單設計需整合前端申辦窗口與後端審核、報表等機制，其資料應確保正確，在表單設計上應考量可用性與可及性，以切實發揮效益。

1.在輸入框旁邊加註填寫限制、格式或提供填寫範例

應於使用者看到輸入欄位之前，提供適當的解說以確保使用者填寫正確有效的資料。同時應確保這些說明應讓使用者在填寫過程可持續看到，且透過應用程式介面使輔助科技能夠連結各輸入欄位的填寫說明。

2.確保表單的可及性

在設計表單介面時，應考慮到表單的可及性。

3.確保輸入框有足夠的填寫空間

表單輸入框有足夠的填寫空間，或可由使用者自行調整填寫空間，可方便使用者編輯或修改輸入的內容。

4.格式錯誤或未填寫的欄位，應告知使用者正確的處理方式

表單程式應告知使用者正確的處理方式，避免偵錯功能誤導或阻卻使用者填寫意願；表單設計應盡可能減少資料蒐集，及避免要求使用者填寫政府機關已知或可由政府機關資料交換取得的資料。

5.在表單旁提供諮詢服務聯絡資訊

壹、簡介

一、目的

二、測試目標

三、範圍

四、限制

貳、測試項目與特性

參、測試方法與策略

一、測試方式

二、測試前端系統

三、期望回應時間

四、測試資料驗證

五、測試限制條件

肆、測試通過條件

伍、測試暫停條件與恢復條件

陸、測試交付項目

柒、測試所需資源

一、軟硬體環境

二、環境架構

捌、人員與時程