《 實習心得 》 曲終人散 ~ 最終我們留下了什麼？公共數位創新空間 PDIS x Ray 5.0 見習計畫（下）
嗨 ～ 我是國立臺灣大學經濟學系大四的邱威辰！在 上一篇，簡介了 PDIS 與 ray 5.0 計畫的內容、第一個月的實習內容與研究政府網站的難處。
接下來再繼續為各位分享研究過程與最終的心得吧~
這邊會挑一些自己比較有心得的過程跟大家分享，因為這篇不是作品集，不會談到很多關於研究的細節與洞見
如果想知道完整的研究與設計成果，可以關注ray的網站喔~目錄
不小心寫太長了，還是做個目錄好了XD
- 研究發現：不會有專業使用者的網站 大家都是新手猴🐵
- UX Writing：使用者會誤解 但真的能換詞嗎？📝
- 原型測試：任務設計太自由 使用者測試大失控🔧🔨
- 原型測試：紅色是警告 還是提醒你這裡有好康？⛔💯
- 曲終人散~最終我們留下了甚麼？
- 心得後記
直面使用者！修改修改再修改的８月
研究發現：不會有專業使用者的網站 大家都是新手猴🐵
多數民眾都在第一次進入網站登記後，撇除進來查看候補進度與托育規則次數，登記公托的完整流程每年至多走一次，然後 … 小孩就長大了👶
我們所負責的台北市公托登記報名與抽籤系統，除了上篇提到的流程簡單到幾乎不能以一個網頁看待外，還有一個特性…
沒有人會「常常」進來這個網站！
一般來說，網站中新手使用者與專業使用者的存在，使得網站流程設計時，會根據不同的使用者進行新手引導或老手快捷操作，讓新手使用者漸漸熟悉網站的操作，讓專業使用者用最少的時間完成目標。
❗ 但這樣的方式在公托網站顯然是不適用的
多數民眾都在第一次進入網站登記後，撇除進來查看候補進度與托育規則的次數，登記公托的完整流程每年至多走一次，然後…小孩就長大了👶
而公托服務的規定、抽籤規則、時程安排又相對複雜，總共 15 位的訪談者中，只有 1 位完全了解相關的規定與規則。
雖然大家在登記上都沒有太大的問題，但就苦了機關承辦人，要嘛一堆不合格的申請資料，要嘛一堆明明規則寫在網頁上還是搞不清楚的民眾打電話詢問。
但承辦人表示，她很高興大家打電話進來問，至少不是自己亂腦補亂填😁因此，我們必須在民眾邊顧小孩、邊工作的繁忙生活中，一進入網站就能了解必須知道的複雜規定、同時避免民眾不看規則直接登記、也要保證流程的順暢與快速，就成了一個設計上的一個大難題。
UX Writing：使用者會誤解 但真的能換詞嗎？📝
每個詞句都有值得設計的地方，一個詞就可能會影響使用者對整個操作上的理解。但許多詞句都是公文事先寫好的，特別是規定與政策相關的解釋。相同的用詞可能會出現在不同的網站與文件。因此詞句常常無法做太多的修正。
過去自己對 UX Writing 僅有稍作認識，只知道好像很重要，但沒有切身的感觸到到底有多重要。經過這次的設計，才發現 UX Writing 的設計對使用者的影響是非常大的，在設計上僅僅是一個詞也可以花許多時間討論。
舉個例子：舊網站中「登記抽籤」、「候補登記」這些詞好像沒什麼問題，但對於沒看清楚規則的民眾可能會認為…
「登記抽籤喔，就會有一個時間統一抽籤嘛，抽完會有正取備取的結果」
「有候補登記，那怎麼沒有正取？還是有特定的時間登記？」
💡 台北市公托服務小教室
一般來說，整個年度都可以選擇想要的公托機構進行登記，因為每個機構一定是滿額狀態，所以一律成為該機構的候補。只有新開幕的機構會進行開園抽籤，就會有正取與候補的差異這樣大家都了解了嗎！公托小教室我們下次見～
（應該是沒有爸媽會看這篇文章啦 哈哈
如此就導致使用者的混亂，而承辦人又會多接到好幾通的電話…
因此在使用者測試時，也要十分注意使用者對各個詞語的解讀，為甚麼會點它？為甚麼沒有點它？都要了解清楚背後的原因。每個詞句都有值得設計的地方，一個詞就可能會影響使用者對整個操作上的理解。
❓ 那我們能隨心所欲地改嗎
畢竟這是政府部門的網站，許多詞句都是公文事先寫好的，特別是規定與政策相關的解釋。公托相關的網站當然不只這個登記系統，相同的用詞可能會出現在不同的網站與文件。因此在詞句的調整上常常無法做太多的修正。
例如：我們原先想將「候補登記」改成「排隊XX」，對民眾來說比較好理解。但「候補登記」這個詞在公文與其他網站中出現的頻率太高，且「排隊」這個詞也過於白話，所以最後只能作罷。
原型測試：任務設計太自由 使用者測試大失控🔧🔨
測試任務設計上我們希望用連貫的情境式任務，並盡量讓使用者自由操作頁面，但使用者在測試時非常難以控制…
❓ 我們怎麼產出設計稿的因為我們４位成員都有或多或少的設計能力，因此我們共同設計較務實的 wireframe A 與較瘋狂的 wireframe B ，經過與機關承辦人的討論後取捨出綜合版的 wireframe C。
最後由２位成員製作粗稿與精稿，再由大家共同提出修改的意見，並進行使用者測試。
這次設計中最主要要解決的問題是「如何讓民眾第一次來網站就能快速了解所有細項」，也因為網頁的操作流程十分單一，因此在測試任務設計上我們希望用連貫的情境式任務，並盡量讓使用者自由操作頁面，以此觀察使用者們在瀏覽上的體驗是否真的得到改善。
雖然自由的任務設計從結果來看，的確讓我們了解到非常多使用者的使用習慣，但還是出現兩個問題…
- 我們為了畫出可自由操作的 Prototype 都瘋了
- 使用者測試時非常難控制
第一點就看圖片中的龍鬚糖就知道了 XD
關於第二點，情境式任務是希望使用者可以更好地帶入我們所設定的角色情境，以此來測試我們所設定好的目標。但使用者們本身就是家長，因此常常對我們所設定的情境或角色資料不視也不見，直接帶入自己的狀況。使得任務途中必須不斷地打斷並提醒使用者回到正軌，但也降低了測試的品質。
後來的改善中，我們先明確地帶領使用者閱讀完任務資料，每個任務中下達明確的斷點（好，那第一個任務就到這邊結束）與清楚的指令（請先保持在這個頁面）讓使用者專注在我們想要他專注的事情上。經過這樣的設計，往後的測試就順利的許多
其實基本原則就是：
一次讓使用者只做一件事或只看一個東西！
經過這次的經驗發現，線上測試的難處就在於難以控制測試的環境與使用者的狀態，他想亂看亂弄都很難及時阻止他，因此讓使用者專注在一件事情上在環境控制時變得非常重要。
原型測試：紅色是警告、還是提醒你這裡有好康？⛔💯
許多我們原先視作理所當然的設計，經過使用者的巧手後一切都會變得那麼的不合理。
在使用者測試之前，我們都有著自己的假設，與自認為對使用者好的設計。原先希望用紅色的標籤警告使用者，這間公托機構的候補人數很多，可以考慮別間。我們都覺得這樣的設計很棒，讓狀態可以一目瞭然。
但在後來的測試中，這項功能卻是評分最低的一個，多數的使用者覺得這個很沒用，對紅色到底是「警告」還是「注意這邊」的解讀也因人而異，最後我們只好把這項特色撤除了。
紅色的問題在整個網站設計中不是唯一出乎我們預料的地方。許多我們原先視作理所當然的設計，經過使用者的巧手後一切都會變得那麼的不合理。因此階段性的使用者測試，在網站設計中的任何時候都能有效地協助修正。
曲終人散 ~ 最後我們留下了甚麼？
Ray 計畫秉持著開放政府與青年參與的宗旨，希望在機關部門與學生們合作的機會中，認識到 UX 研究與 UCD 概念的重要性。試著推動這樣的概念到各個政府部門，讓往後的政府服務在設計時能夠實質上的「親民」。
最終的成果分享會也很明顯地感受到這樣的成果，除了各機關承辦人與長官都十分喜歡我們的作品外。許多機關人員也提到，過去其實都沒有機會注意到民眾存在著這麼多疑惑與抱怨。機關部會礙於時間、資金與部門間的分工，在系統的架設上無法做詳細的討論，或對廠商幾天就生出的提案照單全收。當他們藉由我們聽到民眾親口抱怨這些服務與系統時，也覺得很驚訝。這大概是我們最有成就感的事情之一。
雖然我們的成果要落地或許有一些難度，但對成果的驚嘆和以使用者為中心的概念，隨著雙方的合作也很成功地在機關人員的心中落地發芽。只要往後的設計上，有人開始真正的民眾著想，其實就已經是很成功的一步了！
心得後記
其實最終的網站版本還有大量的問題需要被解決，離落地前的版本還有一大段距離，但礙於時間因素只能先到此為止了。機關承辦人也對我們的東西很喜歡，或許未來有機會時，就可以將這些成果慢慢實現了。
Ray 計畫，就是一個更真實的專案，不再是自己手捏的人物誌、假想且單純的限制、舒適圈中的瘋狂點子。一切都被現實所壟罩，頭腦風暴的同時也要注意處於風暴中的人事。
這次的經驗讓我更深刻的感受到使用者的與眾不同，以前所看到的或許只是一個個需要解決的「問題」。但我們真正要面對的不是這些「問題」，而是一個個活生生的「人」。製作那麼多 HMW、 Job Story、 UJM、 Persona，沒有清楚的同理到一個人真實的習慣、個性、使用情境，再多的圖表工具都是沒有用的。最終可能解決了問題，但不見得幫助到了人。
總而言之，這次見習計畫大大改觀了我對政府部門的想法。只要有心，歷史悠久的癥結也是可以被撼動的。非常推薦擁有 UI/UX、 服務設計、資訊專長，同時也對公部門網站有非常多不滿的人（或是你很喜歡唐鳳😁），一起參加 ray 計畫～
別再只會說政府網站「醜」了，好好地親自改造它吧！
感謝你的閱讀，你的掌聲將是我繼續前進的動力，有任何指教歡迎跟我說
喜歡就大聲拍手吧 👏🏻👏🏻👏🏻