UX 實習札記｜親手改造難用的政府網站！我在 PDIS 擔任 RAY 見習生
嗨！我是Aurora 🙋🏻♀️ 今年幸運地錄取了 2020 RAY 4.0（第四屆）的實習計畫，一起和來自不同專長背景的3位團隊成員協作，為政府網站進行使用者研究、設計改版。
前言｜實習動機
簡要分享一下當初申請RAY實習的動機，一方面是身邊有許多位朋友擔任過往年RAY的見習生、不吝和我分享心得🙏🏻；另一方面則因為自己曾參與交大校園資訊組織的UX部門，「為公眾做設計」、「用UX設計發揮正面影響力」的想法不斷在心中擴散，外在+內在的驅動下寄出了申請資料，順利地在5月份收到斌斌（見習單位的行政小天使👼🏻）的面試信、錄取信了！✉️
札記撰寫初衷
這篇實習札記，除了記錄自己的心得，同時希望可以分享經驗、提供小建議，作為往後的申請者的一些參考。很感謝申請前和我分享的人、文章作者，期許我也能幫助一些人達到釐清RAY的工作內容、減少認知落差等目的。另外，也希望讓更多人知道PDIS這個單位，關注到每年都有一群青年學生共同為「優化政府數位服務」投入努力：Ｄ
正文將透過以下部分介紹：
1. RAY 4.0 實習計畫介紹 RAY 是什麼、在做什麼？
RAY 4.0 的特色
有mentor嗎？
專案能走多深？兩個月的 UX 衝刺會不會很累？2. 專案過程：我們做了什麼？ 專案進行方式｜執行流程
各階段過程分享3. 結語｜整體心得
收穫＆成長
完整地執行從 1 到 N 的 Redesign 很過癮
態度：要相信自己就是專家
推薦大家來 PDIS 實習嗎？4. 建議
「你說你在唐鳳辦公室實習？」
在一些機會下和人閒聊＆分享時，對方聽到這項實習後通常有幾種反應：
- 第一種反應是：「聽起來很好玩！」
- 第二種反應是：「那你會天天看到唐鳳嗎（？）😳」
通常經過兩種可能的反應後，才有接下來這個問句：「所以這個實習到底在做什麼？」
RAY 4.0 實習計畫介紹
RAY 是什麼、在做什麼？
見習機會源自教育部青年發展署，而RAY(Rescue Action by Youth)是隸屬於PDIS（行政院公共數位創新空間，Public Digital Innovation Space）的見習計畫，PDIS是唐鳳政委辦公室旗下的小組。計畫全稱為：「青年學生體檢政府網站數位服務專案」。顧名思義，此計畫招募具有設計、資訊等專長的大專院校在學生，以使用者為中心改造政府數位服務，優化使用者體驗。今年一共錄取了29位見習生，研究與設計居多，資訊專長生約7人（每組1人）。優化的服務專案以本屆為例，可大致分為兩類型：
- 入口資訊服務型：中央或各縣市政府的入口網站，或局處服務。
- 功能導向型：有特定功能定位的數位服務，例如勞保局、就業通、臺北市立聯合醫院。
這是一個非常歡迎不同背景的人來申請的實習機會，多數同學來自設計、服科、傳科、心理系、政治系，以及資訊相關系所，任何有UI/UX、HCI相關專長的朋友，可以勇敢地送出你的申請表單、作品集！
RAY 4.0 的特色
每屆的RAY見習內容都不停演化、各有特點，在報到日時，PDIS也和我們說明第4屆RAY計畫（RAY 4.0）的特色，而我們和上一屆最明顯的差異應該就屬「案數不同」了。雖然本屆只有一項專案，但也相對地較有機會進入coding實作開發階段（各小組可拿捏To be, or not to be XD）；或更有彈性地進行更頻繁的迭代、測試🛠，成果也能透過國發會（國家發展委員會）年底的成發，進入機關網站的設計建議。本次實習進程可以大致分為「7月找問題、8月試解法」，若對其他專案內容執行上的細節有興趣，等等歡迎繼續觀看「專案過程：我們做了什麼？」以下的部分。
有mentor嗎？
有，以提供建議為主，見習生們掌握案子的主導性
相信「有無mentor」是許多人找實習看重的評項之一吧！有人能提點、分享經驗或技術，成長通常會加快的。
PDIS的成員，例如資深的設計顧問、厲害的前見習生們，是大家又暖又罩的mentor。他們在定期見面會上會拋出疑問、給予對專案的見解，讓同學們持續燃起思考和討論的火花，去想有沒有更好的做法？如果是本身擔任過其他屆的見習生也會用自身的經驗、歷屆的專案收穫分享觀點。mentor們的回饋也許是：Persona的合理性、設計某個新功能真的能幫助使用者嗎？又或是技術層面的細節（當你愈想讓案子落地，技術可行性愈重要，有些工程思維能讓人感覺來到新世界，這時就想說ya～又被我學到了XD）。
專案能走多深？兩個月的 UX 衝刺會不會很累？
專案完整深入
案子精實，也能走頗深，本屆因有工程角色成員加入各組專案，有機會進到實作。兩個月暑假會 immersing 在 UX 的核心知識中，邊做邊學到更多（驗證了做中學是成長加速器，會發現自己哪裡不足，自發性主動加強；或從隊友、其他組同學身上學習他們的優點）。
算是蠻累的，但這是很主觀和個案性質的啦⋯⋯
這類專案通常就是想做到什麼程度就會付出多少努力，每個專案、團隊的情況也不一樣（但本屆成發時，大家都說蠻硬蠻辛苦的XD）。主要工作樣貌大概是：訪談、開會、設計、測試、迭代，頻繁地循環和交錯。其實只要喜歡UX這個領域，當問題愈來愈明確、解法呼之欲出且看見驗證後的成果，一定會樂在其中的！
接下來將分享一些我們這組專案的過程，若你有興趣歡迎往下閱讀！
如果以上內容對你有幫助，希望能請你幫我拍個手給予鼓勵 👏🏻
感謝你讓我更有動力持續進行 設計寫作｜學習經驗分享 ：D專案過程：我們做了什麼？
專案進行方式｜執行流程
收到錄取信後，我們要按志願序的方式填寫一份內含10個政府網站的線上表單📝，志願序的結果決定了你負責什麼專案、和誰組隊。最後，本屆成功配對（？）了7項專案與實習生，每組4人（或5人）。在報到日當天，我們也得知了各組成員在專案中的「角色分配」（這可能會依據面試時的作品集、你的經驗分享而決定），分別為：1位研究員、2位設計師、1位工程師，我在專案中擔任設計師之一。
整個實習過程併採「遠端協作」、「實體到場」兩種方式，此種模式在當今除了降低疫情威脅，也能讓更多來自各地的朋友加入RAY的行列🌏（每年也不乏在國外唸書的朋友們暑假在台參與RAY）。
- 遠端協作：實習生和實習單位(PDIS)間的溝通平台是Rocket.Chat，各團隊也可以在自己的Channel中聯繫、遠端作業（沒錯，類似Slack），不過與團隊組員間的平台非硬性規定，通訊軟體或協作工具都可以按照大家的習慣。我們這組的協作工具是Google Docs、Google Sheets等線上共編，所有資料都在小組雲端中，開會時用Google Meet。
- 實體到場：約10–14天會舉行一次見面會，各組為該階段進度、表定的關鍵產出內容進行10–15分鐘的簡報+Q&A，除了有督促進程的作用外，和其他組彼此交流是超棒的學習機會！例如我們曾請教別組的PM專案管理技巧、也觀摩到很多厲害的簡報呈現方式，最後也很重要的⋯⋯見面會的點心都很好吃😋。
🖥 我們負責的網站是「臺北市政府市民服務大平臺」（以下簡稱大平台），是整合台北市便民申辦服務高達1400多項的大～平～台，主要的功能有：搜尋及瀏覽服務資訊、24小時線上申辦、場地租借、臨櫃洽公預約等。
好了，有了專案和夥伴，所以該怎麼做呢？（快航向偉大的 UX 航道吧！٩̋( •͈ω•͈)و✧）
修但幾咧，出航前，先拿起你的地圖 🗺
簡言之，設計是「從 A 到 B 的過程」。
RAY的專案執行流程是採用Double diamond design process，雙鑽石設計流程（又稱4D Model，不嫌棄的話可參考小妹製作的上圖），也許有涉略設計思考、產品開發的人都蠻熟悉這個模型了，透過此框架，兩階段的發散(diverge)——收斂(converge)，可以幫助我們掌握開發階段，在四階段中知道「現在該做什麼」、「下一步要做什麼」的原因，並方便於每一步驟內檢視關鍵產出，扣合上一階段的成果。
🔄 4階段內容包含：挖掘使用者的痛點(Discover)、定義關鍵問題(Define)、設計不同方案的原型（解法）(Develop)、測試與迭代，產出最終設計（高擬真互動原型或互動網站）(Deliver)。🌟 但這不是唯一的路徑、第一次的Deliver也不是終點，產品開發過程是「活的」，在進行時也許會回頭重新定義問題、重新設計，每一階段都可能成為新的起點。6️⃣ 6步殺，PDIS將專案流程分為6步驟：
1.了解使用者（訪談+網站數據分析）-> 2.定義核心議題(How Might We, HMW) -> 3.Wireframe 線框稿 -> 4. Lo-fi prototype（低擬真原型） -> 5. Hi-fi prototype（高擬真原型） -> 6. 成果發表
我個人的感觸是Double diamond很好用，但其實不論是什麼框架、工具，設計都是一場行動，也就是從A（問題、原狀態）到B（解方、新狀態）的過程。
專案前情
目前的「大平台」已經是「改版後」的網站了，在我們進行專案時(7月)，現行網站上線約9個月。改版過後繼續積極參加本屆RAY的專案，完全是持續優化的代表呀！👏🏻 不過新版網站上線後在短期內還有改善的需求，也讓我們擔心問題是不是特別棘手⋯⋯，抱著矛盾的憂喜參半心情，專案要展開了⋯⋯
大平台見習小組Ｘ資訊局Ｘ設計顧問 三方協作
三方一體？擁有實際和機關方、設計顧問一起協作的機會
由行政院國發會籌辦的UCD(User-Centered Design)工作坊，提供機關方（各專案網站的隸屬單位）了解使用者中心設計方法，我們見習生參與了後面三次，也是除了定期見面會以外的實體出席日。
網站的使用者不是一般民眾嗎？為什麼要採訪機關人員？
這個問題可以這樣看：「資訊局怎麼看待這個網站呢？」這件事重要嗎？為什麼要知道？
🏢「臺北市政府資訊局」是大平台的負責機關，業務範疇涵蓋架設、維護大平台網站。
資訊局是服務提供者，利害關係人訪談往往會影響整個專案的redesign，在前期投入使用者研究前，常要考量案主、各直接＆間接利害關係人進而規劃主要目標、定義產出，減少做出過度理想化、不可行的成果（具體而言，解法可能千萬種，但也許只有1種適合現行的資源和狀況）。除此之外，我們透過本次訪談也了解局處的組織文化，現行的設計有部分來自於長官的決策，如何在使用者需求、行政資源限制間達到平衡也是 RAY 專案的一項重要課題。
7月2日，見習緊鑼密鼓地展開，我們於當天訪談資訊局人員，主要目的為：
- 了解資訊局對大平台網站的建置需求、期待
- 快速了解使用者的常見問題、現況改善的困難和原因
- 建立持續聯繫和合作的機會
「網站上有呀！就是那樣呀！」 當便民服務不便民？
訪談結果發現，即便有線上申辦，局處還是時常接到不知道如何申辦、被會員制搞得頭暈的客服電話。即使「指引民眾使用網站，卻無法有效幫助他們」，熟悉網站的機關方或客服人員在電話那頭解答民眾問題，卻難以同理使用者的痛點；也許資訊局人員的處境更像是「不知道問題是什麼，但知道有問題存在。」因此，協助減少客服業務量也成為改善成果的指標之一；幫局處找到問題、擬出解法就是我們的任務了。
親和圖分析，分群歸類找問題
部會訪談的質性資料，我們透過親和圖法(Affinity Diagram，又稱KJ法)整理，並用Miro線上軟體協作，為編碼後的user quote進行分群，此方法的好處是：一次看見大部分的資料，能將分散的具體資料一層一層找出抽象的上層概念，萃取出findings，幫助接下來制定Persona、定義問題（How Might We，我們將如何⋯⋯）轉化為設計目標。
💡 我過去蠻常使用到親和圖法，它是整理質性資料的好朋友，但也有幾項易犯的禁忌要注意：
🚫 切忌用關鍵字來分類（又譯：不要看到黑影就開槍）；被訪綱或心中預先的成見侷限而有分類偏見、不做改動；硬湊讓所有quotes都有分類（為分而分）。從此次反映的結果也可以得到初步的問題輪廓：服務分類不妥、會員申請解釋不夠清楚、線上申辦流程不全面且步驟繁瑣等，導致使用者體驗不佳、無奈致電客服而增加局處業務。
另外再特別提到，不僅在訪談當下，資訊局於整個過程真的非常用心盡力地解答我們在專案上的問題、提供資源，像是網站服務的使用數據、在專案中後期也接受我們進一步理解後台系統的操作管理、易用性測試，讓專案推進得更深、更精準，超級珍惜和感謝！
除了研究階段的協作，設計階段也有想法上的交流。
在7月中，我們與資訊局人員、設計顧問進行一連兩天的「打造Wireframe雛形」工作坊，先以目前的使用者研究資料繪製出了顧客旅程地圖（Customer Journey Map, CJM），著手討論網站改版的可能樣貌，並和設計顧問運用Figma設計軟體，即時線上協作部分的Wireframe（線框稿）初期版本。
我們有非常難得的機會和遊石設計的研究員新雅、實習生們合作，感謝遊石和我們分享執行過類似案子的經驗，也讓我們有更多元的角度思考設計的機會點！（Ok，請大家聽爆設計遊牧podcast來讓我們表達謝意XD）
Discover｜探索階段：使用者研究＆Persona
訪談大平台使用者、潛在使用者
在初期招募使用者時就遇上阻礙，原本以為身為首都的便民服務網站應該多又好找才對（好天真），卻由於招募管道有限、大平台雖屬「剛需」（特定必要的需求，例如必須線上申請某項補助），但SEO不佳、網站首頁形象定位不夠，某些訪談時的潛在使用者甚至不確定自己是否瀏覽和使用過大平台（很玄，大概介在有和沒有之間⋯⋯）。種種原因下我們募集地很辛苦。廣發招募問卷到臉書各校交流社團、大台北地區相關社團、ptt、Dcard、人脈管道等，才順利募到能達成研究條件、有足夠代表性和數目的受訪者樣本。
首頁服務分類
有千百個服務都不怕，只求合適的分類邏輯
許多政府網站的服務項目眾多，在首頁除了關鍵字搜尋外，分類項目是關鍵，符合使用者的一般經驗和邏輯，才能順利讓他們找到正確的服務。
但究竟如何妥善分類？我們先透過Google Sheets線上共編梳理大平台的1400多項服務，經過「獨立分類作業」，再經過「小組共同評估」，並比對、參考相關產品（例如各縣市政府網站等）的分類邏輯，訂出數十項類別。接下來，我們邀請潛在使用者依照封閉式卡片分類法(closed card sorting)，為我們分類整理出的類別＆服務。這項方法很便利有效地了解使用者對服務與分類的認知。在此階段，除了觀察紀錄，也會根據分類過程、結果進行訪談。
Define｜定義階段：CJM＆HMW
定義出優化的核心議題：Aha-moment 出現了！
整合性質的大平台，怎麼聚焦改善功能？我們在探索階段費盡一些苦心，在「1400多項服務」、發散的問題中，我們逐漸收斂、定義關鍵痛點：線上申辦有個資疑慮、申辦流程冗長以及線上無法全程辦理等，最終聚焦到「場地租借」這項服務，探討出這個核心的改善項目時很令人振奮。在場地租借的使用者研究中，也定義出了三個HMW：
發現問題，對應設計目標
Develop｜設計開發階段：Wireframe ▶️ Lo-fi prototype
發想、實作、測試、迭代
雙版本Wireframe
實際 X 夢幻 小孩子才做選擇，我都要！
我們簡稱「實際版（中規中矩）」為A版，「夢幻版（大膽創新）」簡稱為B版，不過到底為什麼要有兩個版本的Wireframe？
如果剛剛有注意Double Diamond模型的話，你會發現現在正是「第二次發散」。雙版本是為了讓我們在 ideation發想階段，嘗試Brainstorming更多可行的點子，這時的任務目的在於：「盡力找尋所有可能的解法」。
但最終的版本就是A or B或A+B嗎？答案是No。「我都要」其實不太正確；更準確地說是：「好的、能真正解決問題的部分，我都盡量要。」
所以，最後決定的Wireframe版本可能是個強大的綜合進化版C！
P.S. 雙版本的Wireframe也是本屆 RAY 4.0 的特色之一
「想要維持低擬真度（如Wireframe、Lo-fi prototype），但又必須有具體資訊才能明白如何操作」
如何解決這項困難？可用「註解」的方式！
由於大平台網站本身的性質，在畫面上有許多特定資訊（像是特定的服務分類、場地資訊說明等），我們只想讓受測者能「理解那是什麼」，但若真的將所有文案、細節全展示出顯得較沒必要又十分耗費成本。
持續思考如何改善這個問題的同時，我在《協同產品設計》這本書中找到相應的解法。善用註解的方式，可以維持低成本的開發工作，也能確保資訊被有效辨認而不妨礙操作。
在書店看完後就愛上，手刀購入XD（先聲明：這不是業配文QQ）
資料來源：王薌君（譯）（2020）。《協同產品設計》。臺北市：基峰資訊(Austin Govella，2019)，342–349頁。
💡 微心得：維持Lo-fi（低擬真度）的測試有其必要，在還沒進入收斂階段，都仍在嘗試可行方案，這時主要的任務目的是「快速演化各種變化版本」，因此還有非常大的改動可能性。有些設計細節建議先有點想法就行，待最終進入開發版本Hi-fi prototype時再正式制定。Deliver｜交付階段：Hi-fi prototype＆成果發表
Hi-fi prototype
我們在Figma上做出高擬真設計稿、設好互動方式，產出Prototype後，發覺很多效果還是不夠到位，例如text typing等，即便使用進階的Plug-in，還是有一些限制（例如中文字型跑掉）。
最後我們還是決定把頁面刻出來了
非常謝謝我們強大的工程師夥伴佩芸！她做出了非常符合Hi-fi原型設計的網站，我們在主要的情境任務上制定可互動的範圍，歡迎大家點連結來體驗。
👉🏻 點我看大平台高擬真網站 👈🏻
成果發表日
各組在成發時會有精彩的簡報發表，也會擺攤展示最終的Hi-fi prototype！PDIS邀請了唐鳳委員、各專案的機關局處人員到場參與，我們將三種Persona設計了不同的體驗路線，希望讓在場的使用者操作嶄新的大平台原型時能更「有感」。
結語｜整體心得
整體最大的啟發是「不要把政府網站當成政府網站」，聽起來很弔詭，但意思是對使用者而言，只要能幫助他們達成目的的產品或服務就是他們要的，因此設計上還是要謹記洞察需求、打造適合產品的原則，而非將思考落入「政府網站都該長那樣」的套版。
收穫＆成長
能和一群人一起完成一項專案很有成就感，隊友們擁有各異厲害的專長，我從大家身上學到不同的觀點、技巧，像是專案管理的拿捏、各樣設計的決策、一些功能在網頁上的串接等，種種都得到許多收穫！🌟
我也能在軟硬面向的能力中感受到自己的成長，例如電話邀訪的溝通技巧，判斷受訪者是否符合條件、有實際的相關經驗；實作上除了畫面的構想、協作以外，我也有機會研究更多不同的prototype互動方式（例如比較不同工具的地圖拖曳效果，特別感謝不吝和我分享Framer互動效果的立秦！）。在設計細節上也能落實一直很喜歡也很重視的通用性設計，例如，色彩對比度與字級等。
將理論、概念帶到實作上，是我認為重要而不易的，在這項專案中我感覺到我們都努力地將所學轉化進實際開發。
完整地執行從 1 到 N 的 Redesign 專案很過癮
多數自發性的side project可能會做從0到1（無到有）的開發模式，但實際上從1到N（有到再進化）的優化改版需求佔了更大的比例。
Redesign 是很好的UX專案練習方式，而我覺得如果能完整、親自掌握第一手資料的Redesign是對於累積UX作品經驗最棒的地方！你可能會問，Redesign不都自己挑個產品做就好了嗎？但假設我們想Redesign常見的大企業、背後組織較龐雜的產品，往往很難知道該公司的決策依據和限制是什麼，辛苦的成果容易淪於做出一個可行性較低、優化「視覺介面」的作品。因此，在校學生除了產學合作的課堂外，有能夠親手改造已上線的產品／服務的機會難能可貴。
態度：要相信自己就是專家
扛了PDIS RAY見習生的名義，其實當你和局處人員溝通、為使用者做訪談，他們看待你的角色就是「專家」，而不是在學實習生。我覺得至少在見習過程中的當下，秉持這樣的態度，會讓自己產生更強的責任感為專案做出更好的結果。
推薦大家來 PDIS 實習嗎？
推薦！But why?
✅ 實習制度完善
✅ 體驗遠端工作模式
✅ UX研究方法精實到位
✅ 可累積完整的改版專案經驗
✅ 挑戰執行公部門的體驗設計、服務設計
✅ 認識更多有相同志向、不同背景的朋友（遠端但不孤單），學習與多樣的人共事建議
- 多問自己、隊友、見習遇到的夥伴們一次「為什麼」，一定有新的啟發
- 儘早隨時同步、整理使用者資料對照庫以及User quote
- 低擬真度原型測試、迭代有其意義，不要太早引入高擬真度原型的作業
- 多數決不見得就是好決策，多加思考合理／不合理的原因
- 多與其他組交流（大家都是優秀的老師❤️）
謝謝你看完這篇實習札記 ，希望能提供一些幫助、減少疑惑或滿足好奇。對改造公眾服務有熱忱的朋友，請密切鎖定每年春暖花開之際釋出的報名資訊～！( •̀∀•́ )✧
再次謝謝你看完這篇文章，歡迎幫我拍手1~50下 👏🏻
你的鼓勵讓我更有動力持續進行 設計寫作｜學習經驗分享 ：D
