政府網站營運交流平台

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

 

什麼是使用者中心設計

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

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

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

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

 

參考範例

以行政院公共數位創新服務團隊（簡稱PDIS）於106年協同財政部等相關單位，共同完成的新版報稅網站為例，於執行過程中，不以「報稅系統要達到的成效」為設計重點，而以「協助使用者快速完成申報程序」為焦點。先進行現有網站設計的易用性測試，並舉辦工作坊了解使用者在申辦各階段的需求及痛點，最後才提出改善設計方案。

 

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

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

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

檢核清單
執行步驟	關鍵任務
⬜定義使用者與利害關係人	⬜ 1-1分析任務目標、定義使用者與利害關係人
	⬜ 1-2製作顧客旅程地圖
	⬜ 1-3進行現有設計易用性測試
⬜定義問題與設計解決方案	⬜ 2-1 定義各階段需求，研擬對應設計方案
	⬜ 2-2 協調團隊，調整需求優先次序與確認方案
⬜驗證與調整	⬜ 3-1 測試新設計易用性，依結果快速迭代調整

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

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

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

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

參考範例

以報稅網站改版為例，除了身為主要使用者的報稅民眾，處理報稅、解決第一線問題的稅務服務人員，本案利害關係人也包括財政部國稅局、財政部財政資訊中心、內政部資訊中心、PDIS、廠商等。

 

1-2 製作顧客旅程地圖

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

• 訪談法（User Interview）

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

 

• 影子觀察法（Shadowing）

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

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

 顧客旅程地圖：

	服務前			服務中			服務後
階段
目標
行為
接觸點
想法
情緒
痛點

 

參考範例

以前述的報稅網站改版為例，其顧客旅程地圖如下。

 

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

• 易用性測試（Usability test）

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

 

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

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

 

易用性測試文件：

	頁面1	頁面2	頁面3	頁面4	頁面5	(以此類推)
畫面
頁面目的
使用者需要完成的任務
User1
User2
User3
(以下類推)

 

參考範例

以前述的報稅網站改版為例，其易用性測試文件如下。

 

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

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

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

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

服務階段	使用者行為	使用者需求	UX改進方向
服務前	【確認需要】 使用者確認服務內容	找到所需服務並申辦	提供評估方式與提醒
	【選擇】 使用者進行選擇	做出合適的判斷	提供決策所需的資訊
	【準備】 使用者事前準備	準備相關資料	以簡明易懂的方式呈現
	【檢查】 使用者檢查資料完備	檢查文件資料備齊	提供清單協助檢查所需資料
服務中	【執行】 使用者申辦服務	順利提交申辦資料	提供滿意的服務與流程
服務後	【進度】 使用者等待申辦結果	評估何時完成	提供處理進度查詢
	【進度】 使用者異動申請資料	完成補件或資料變更	避免重覆要求補件
	【完成】 使用者申辦完成	確認處理結果	通知完成服務申辦

 

【服務前】

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)或信函，通知使用者申辦的結果。

參考範例

不同服務有不同的顧客旅程，不是每個服務項目都需要「申辦」，但會有各自不同的「使用者」，機關可先找出使用者在使用體驗上的困境，再來思考如何透過調整使用介面(UI)改善使用體驗。以台灣就業通為例，服務的使用者為「求職者」，網站設計前畫出「求職者」的顧客旅程: 1.進入網站時，找工作太不明顯找不到 2.開始填寫履歷時，欄位複雜不好填寫 3.投遞履歷後的等待通知時的情緒，再依據不同階段UI設計相關服務: 1.入口處放大「搜尋工作」的介面，2.填寫資料時以填寫者熟悉的結構來分類，3.讓有通知時更明顯，並引導相關行為。

 

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

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

• 工作坊（Workshop）

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

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

參考範例

如何整理出各不同階段需求與改善方向？以財政部報稅網站為例，為了更進一步了解使用者在使用報稅系統前、中、後的情境與問題細節，由PDIS團隊協同各利害關係人辦理工作坊，參加成員包含民眾、使用者經驗設計師、財政部財政資訊中心、內政部資訊中心、國稅局等相關單位，針對網路報稅系統介面及使用者經驗進行討論。 1.與會者以使用者操作過程回顧報稅流程問題，完成並產出顧客旅程地圖，明確了解使用者在各階段碰到的問題，並完成初步收斂，並依急迫性調整項目的排序。 2.由PDIS團隊配合使用者經驗設計師整理工作坊紀錄，並依據使用者需求，產出解決方案的設計原型線稿，並由與會者針對不同的解決方案投票評分，選出較具可行性的解決方案。 3.與會者就線稿進行初步測試，確認解決方案有解決原有問題。

 

三、驗證與調整

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

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

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

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

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

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

參考範例

以新版報稅服務為例，使用者經驗(UX)設計專家依據第二次工作坊結論，產出相對應的紙上原型進行初步調整，並描繪出網路報稅系統介面線框稿(如下圖)。再於第三次工作坊時，以此線框稿進行討論與測試，實際檢視流程中是否順暢。後續因考慮若直接提供無法互動的線框稿進入程式開發，可能因想像空間過大而造成實際開發製作的成品與工作坊產出的設計解決方案有落差，為避免此一問題，最後使用Prototype軟體(例如：Invision)製作成可互動的原型，提供做為開發階段的參照。