Y
U
N
N
Unleash Your Uniqueness and Shine.
Unleash Your Uniqueness and Shine.
2019 年底至今，疫情席捲全球近三年時間，打包行李的技能顯得生疏，準備閉關的技能卻非常熟練，練就一身防疫小尖兵的絕活，還是難免在槍林彈雨中被散彈掃到。
在台灣就醫一直很方便，確診時不能一樣方便地外出看醫生時怎麼辦？
這次實際走訪「看診→領藥」的線上看診服務流程，也使用政府力推的「健康益友」APP，這款 Google Play 台灣區評分 2.7、在 App Store 更只有 1.5 極低分數的產品，究竟在使用上會面臨什麼問題？從產品設計角度我們可以如何改善線上看診的體驗？
【 聲明：以下資訊僅供本次 case study 使用，以發文時間前的實際體驗和觀察作為依據，政策和產品版本會隨時間演進，實際資訊以官方公告為主 】
疫情之前，線上看診在台灣並未普及，假設花同樣費用，相信到鄰近醫療院所和醫生當面問診會是更多人的選擇。直到今年 5 月疫情嚴峻，因應醫療量能不足和外出就醫的風險，「居家快篩陽性即確診」政策開放後，遠距醫療才真正進入大眾就醫的選項當中。
不過對病患而言，目前的版本比較像是「不得不」的選項，而不是「更便利」的選擇。
這樣的心理歸因於視訊診療的服務體驗流程難以感受到有站在「使用者角度」進行設計，反而更像在堆疊「眾多官方文件的 online presence」，好處是有人問起時可以給他網址。
對使用者便利與否的評估標準可以觀察未來在不強制的狀況下，「即使沒有疫情，我還是會使用」的用戶比率，也要看這場剛啟動的醫療數位轉型是否會與時俱進。
一個產品在變現之前，要先能回答「這是不是用戶想要的東西？」、「用戶是否會願意為此付費？」，也就是產品對用戶來說具有價值。
在天時地利人和之外的條件是要能滿足「使用者需求」和提供「愉快的使用體驗」。
好的體驗 → 產品更容易被喜歡 → 更多推薦 → 更多人使用 → 更多生意
iPhone 能在 2007 年推出後迅速改變世界，除了挖掘出消費者自己都不知道的需求，賦予電話在通話以外的更多想像，獨樹一幟的操作體驗更是讓許多果粉們甘願買單的關鍵因素。
打造「對的產品」或是「好用的產品」不是選擇題，而是要加在一起後才能夠最大化發揮產品影響力，讓更多人願意使用的同時也才能享有因為產品而解決生活上難題的好處。
「線上看診」的確是一個值得且急需被解決的問題（對的服務)，但卻還不是一個「好用的服務」。
延伸閱讀
身為疫情下緊急催生的產物，就像多數趕著上線的數位產品一樣，核心功能具備，但背後的程式架構和基礎建設來不及完全跟上，操作起來連帶會感受到效能不彰，或是使用者流程存在缺陷。
前者我們在這次線上看診會使用到的「健保快易通」、「健康益友」兩款 APP 下載頁面查看，不難發現許多無法註冊、登入異常或是頁面閃退的評論，但幫特定軟體除錯不是今天的主要任務，而是從後者去思考整趟線上看診流程在設計層面優化的可能性。
健康益友 APP
由衛福部指定所屬醫院提供緊急醫療諮詢服務，以居家照護 COVID-19 確診個案和遠距醫療送藥為主，目標是「成為您健康的好朋友」。
健保快易通 APP
由健保署提供，不限確診病患，也提供一般視訊診療。
這次我以首度接觸視訊診療服務的全新使用者視角走完流程，同時嘗試協助對新科技掌握度較低的家中長輩完成同樣任務，結合身旁親友確診後的常見疑問與觀察，從資訊搜集、看診到取得藥物，整理出使用者旅程地圖如下：
進一步分析對用戶來說相對挑戰的服務接觸點 (touchpoints) ：
基於以上問題綜合來看旅程中可以改善的機會：
萬事問 Google，一開始的資料搜集也不例外！這時很單純是想知道陽性門診有哪些選擇？要準備什麼？線上看診如何掛號？中西醫可以都看還是只能選一個，流程是？
依照關鍵字不同，搜尋結果排序會有所差異，不過前幾筆主要會由「衛福部疾病管制署」、「衛福部中央健康保險署」、「地方政府官網」的特定頁面組成，部分關鍵字則會只有報章媒體的文章。
這時用戶高機率會點進扣除掉廣告的前 3–5 篇文章，但隨即遇到的問題有：
1. 我是誰我在哪裡？頁面跳出過於頻繁，無論進到哪個單位的官網，馬上都會被引導離開
點擊搜尋結果前兩篇文章，在完成進去後的任務前（找到醫院名單）至少會開啟 5 個新視窗，包含檔案讀取工具轉換、三個不同單位官網。在平台內多點幾下後，頁籤迅速成長，若想回頭查看第一個頁面，就得在平常累積的茫茫 tab 海中把它找出來。
2. 不同單位官網間存在看似雷同卻又些微不同的檔案；即使在同一官網下，也難以從檔名直接辦認內容差異
除非把檔案都下載下來一一檢視（這樣就太瘋狂了），所以「不同單位配合的診療服務方式會有差嗎？」之類的問題浮現，但想看「問答集」也要再下載一份！
3. COVID-19 防疫專區不夠明顯
接著想要繼續瞭解其他資訊，應該有專區可以看吧？然而當我從導覽列回溯上一層「嚴重特殊傳染性肺炎」，發現眼前的畫面比較像是資訊提供者的個人檔案總管，每點一個項目就會重新展開一座不知道盡頭在哪的階梯，想到要再打開許多新視窗、下載檔案等種種不確定性，就先放棄離開了，重新 Google 應該會有更快速的民間懶人包。
不確定性讓人不舒服，人類討厭而且會下意識地遠離。使用者體驗設計的目的要能幫助使用者在抵達目的地前，知道身處何處並且對每個步驟感到安心。
這種感覺有點像是去書局，你知道在找的答案一定藏在某個大類別的幾座書架上的幾本書中，你借了一個有滾輪的梯子，左右滑動、爬上爬下，偶爾快速翻閱一下「嗯～字好多，應該不是這本」，然後開始越來越焦躁。
在這次整理資料過程中才發現衛福部有建立一個更像專區的Covid-19 防疫流程整合友善化網頁，但從上述的特定文章頁無法直接前往，需要透過導覽路徑中的「首頁」，再從首頁的第二張 banner「快篩陽性怎麼辦？」進去，一般來說 banner 更多是用在宣導而非專區的長駐入口。
在這個階段總結幾大問題：頁面跳來跳去讓人無所適從、尋找解答的互動成本高（interaction cost）、疫情官方專區不夠明顯，以下是幾點建議：
官方資訊來源分散，每個單位都運營各自的網站。既然無論進到哪個單位官網都還是會互相跳轉，可以明定官方專區後擔負起入口網站的角色，整合各方資訊和比較選項差異，在不同單位轉換過程中也要可以很便利地重新回到專區。
強化搜尋時官方專區會連帶被推薦出來的機會
避免讓用戶一直有被跳轉出去的感受
與其強迫使用者一直努力工作，倒不如幫他們蓋好一座可以輕鬆從 A 到 B 的橋。 — nngroup
目前官網資訊以文字為主，但是設計者不會期待用戶在找到答案前先讀完一本書或是一整個資料庫，就像你不會在別人請教你一個簡單的問題時，把所有相關文件都放到附加檔案請他自己閱讀一樣。
比讓用戶知道「他們有多少選擇」還更重要的是讓他們知道「現在要做 (選擇) 什麼」。
將資訊依照重要性分類後差異化呈現。比如說依照發問頻率區分必問題與一般題；又或是依照瀏覽視角（確診者、媒體、入境者等；確診者可能又會細分為幼童家長、獨居者、高風險族群等）。
在不同視角下凸顯對該族群來說最合適的選項，並且隱藏不必要（對特定族群來說沒有意義）的資訊。
如果真的有很重要的文件，可以放到頁面底部當作延伸閱讀。
給一般民眾瀏覽的網站內容要注意專家用語和口語文案的使用比重，比如說目前的檔案名稱就過於冗長複雜。當用戶認知負荷過高的時候，除了直接離開，也會讓實體客服承擔網站角色未扮演好的責任，提高人力溝通成本。
善用視覺輔助，縮短完成任務的時間。在設計上可以明顯區分視覺層級，比如透過字體大小、顏色、區塊、圖像等強調差異性，保持頁面易讀性。常用手法可參考 Gestalt Principles。
當使用者可以很簡單地在一個地方找到所需資訊，就會提高在官網的停留時間和拜訪頻率。使用者體驗的目的也包含觀察、預測、滿足使用者需求。
前兩點提到官網角色和資訊閱讀不易等問題，造成用戶轉往外部平台如報章媒體、社群、部落格等處尋求懶人包。但過度仰賴其他資訊來源做更清楚地說明，用戶就越可能迷失在茫茫資訊中分不清真假，尤其越久遠的文章往往點擊率累計越高，稍不注意就可能看到過時的政策。
另外目前官網外部文件過多，也會導致資訊管理/查找不易，就更容易出現資訊不一致的狀況。
能夠抄捷徑找到解答或是繞遠路，端看你下關鍵字的功力，還有進對文章的運氣。
整趟旅程中，我遇到過：
幾個優化方向：
成立網站的目的是為了傳遞重點，不然就開一個雲端硬碟把檔案都上傳上去依照資料夾分類就好了。建議擷取文件、表格、EDM 中的重點資訊，做好內容設計規劃進平台功能中，減少超連結直接指向外部文件的佔比。
外部文件的便利性是站在提供者角度來看，但對用戶來說卻是缺點居多：
1. 平台搜尋範圍無法觸及外部檔案，難以提供精準搜尋服務
2. 外部檔案許多說明並未設定超連結
若是純圖檔形式更是無法設定，用戶會需要另外去把提及的檔案找出來。但讓用戶自己出去尋找，就有可能會找到不同份檔案。
3. 外部檔案維護不易
大家應該都有那種經驗是做一份小組報告，可以存 10 份不同日期、數份名為 final 的檔案，最後已經不知道最新的是哪一份了！更不用說內容修正與版本差異很難回溯，很難直接從源頭統一控管所有相關檔案的同步更新。
在線上看診旅程中，接觸點包含「衛福部官網、新聞媒體、院所官網、外部檔案、健康益友 APP、健保快易通 APP、數位病毒健康證明網站、行動支付平台」等，接觸點太多又不連貫，存在多處讓使用者就此揮手離開的痛點。
過去就醫，流程包含前往醫院、櫃台掛號、候診、醫師問診、到批價領藥等，但這些接觸點都是在醫院內完成，頂多可能會到隔壁藥局領藥。試想若把他們分散到不同地點，我們還會覺得便利嗎？
Bottom-up 盤點接觸點，Top-down 進行整體性的服務設計
一個產品是還是各自為政，還是有強而有力的統籌，在產品上可以從一些痕跡判斷：重複的功能模組、只擺放與自己有關的資訊、資訊不集中等。
只有當知道現在有多少東西，才能好好重新整理現況，轉化為清晰的服務架構與產品規劃。對用戶來說，「線上看診」不只是使用單一產品，而是一套完整的服務體驗，在服務設計上需要確保各接觸點之間的順暢性，用戶應該要能夠在不需要過多外力協助下，無縫接軌地從 A 到 B，再到 C, D…G。
「用戶應該沒那麼笨吧，反正不會再讓他們問客服就好。」
這是在過程中另一個會讓人很需要聯繫客服，或是上網啃使用指南的問題：缺少足夠的指示、反饋與錯誤提示。
細看 APP 評論，許多滿分的肯定是給客服人員的，我自己在使用時也很感謝有醫療人員在操作指引上的提醒：
先一起感謝醫護人員辛勞、客服人員盡力協助排除使用障礙 👏
But!
幫產品除錯不是使用者的責任，客服有其必要性，但不是用來解決如果有做足產品測試就可以提前預防的狀況。
線上看診是一個全新的體驗，產品本身不能認為用戶會知道所有操作。因為這次整理資料時看了整份使用指南，才發現「健康益友」APP 有提供幫家庭成員註冊掛號的重要服務！但卻隱藏在會員中心裡面。
這對家中有兒童或是不熟悉科技產品的長輩來說，是很重要的服務選項，建議在 onboarding 時可以針對核心功能加入提示，或是把它移到更醒目的區塊，比如說服務中心。
透過健康益友 APP 看診前，會需要到健保快易通 APP 取得「健康存摺」，或是前往「數位新冠病毒健康證明網站」取得所需資訊。
但實際進到網站後，不管如何點擊都是一片空白，沒有任何資訊可以取得，非同住長輩也在這個接觸點後就決定離開接下來的流程，不願意再繼續嘗試安裝多一個產品、面臨有可能再次失敗的時間耗費。
健康益友看診
身為由政府直接推出的視訊看診服務，掛號後會有預計看診時段，時間到了可以進入診間，此時畫面上方會有 10 分鐘的倒數計時，但直到快接近 0 秒時都沒有出現任何提示狀態。
「所以時間到了醫生沒有進來我需要重新預約嗎？」
「時間到了視窗會消失嗎？」
最後我就趕快聯繫客服，擔心若真的要重新預約會因為額滿而延至隔天看診，而答案是「會繼續倒數，繼續留在當前視窗即可」。建議在這個階段可以加入像是「若倒數結束醫師還沒進入診間，請稍候片刻並留在當前畫面」等提示。
非透過健康益友 APP 預約
許多醫療院所已經都開始提供線上看診進度查詢，剛興起的線上看診或許來不及跟進，畢竟醫生們也是很辛苦的在實體門診外穿插時間進行線上診斷。
但未來若結合一般門診叫號狀態，區分線上和診間顯示，可以有效降低病患對於掛號成功與否的不確定性，減少聯繫客服的頻率。
最後一點！
視訊診療還沒有官方主流工具出現，即使有健康益友 APP，都還是會因為合作院所與支援縣市過少，而需要使用尚未建立起視訊機制的其他醫療系統，間接仰賴外部工具支援。
但頻頻收到的詐騙簡訊不得不讓人覺得有必要正視資安的問題。
在使用外部工具時，會被要求提供敏感個資，部分情境為：
使用外部工具無論是不是短期的 workaround，重要的是現階段就可以思考並加入聲明，讓用戶知道這些線下提供的個資，在看診結束後會如何被處理？
長期來看除了持續讓現行官方工具更好用外，或許也可以獨立視訊模組，開放醫院使用？或是在未來平台整合過程中，讓資料在做好安全防護的前提下可以跨平台讀取，也才能夠降低使用者在平台 A 下載、到平台 B 上傳的情境，還有醫護人員繁冗的確認流程。
政府推出的工具，往往因為市場上沒有其他競爭者、又是高需求產品而容易在設計過程中忽略了使用者體驗。有人或許會想說網路上找得到使用手冊啊～但使用 Instagram 前你會先看官方文件嗎？這部分如果未來有分享設計聖經《The Design of Everyday Things》時可以再多做說明。
倘若一個立意良善且以全民為 end user 的產品在設計時沒有最大化考量不同族群的使用情境和需求（如：弱勢者的數位落差），在公平性（Equity）上會導致享受服務變成少數人的福利，對多數人來說這個花錢打造的產品卻只是一次性工具，甚至可能連在這僅有的一次中，都無法幫助使用者完成任務，或是帶著情緒離開。
“Design creates culture. Culture shapes values. Values determine the future.” — Robert L. Peters
「設計創造文化，文化形塑價值觀，價值觀決定了未來。」
想到日本，我們會想到很棒的設計，整齊劃一的招牌。
正是全民都會需要使用的產品，在設計多投注的心力都會反映到國民美學上，慢慢形塑出屬於我們的文化和一套完整的設計系統。
也因爲線上看診在台灣的發展還很前期，還是很期待在逐步優化後，「遠距醫療服務」會真正成為大家「健康的好朋友」，讓醫療資源分配不均的地方也可以享有友善又便利的診療服務。
.svg)