跨場景、跨通路的服務設計驗證實務

Published in

ditl / Design Innovation & Thinking Lab

Nov 4, 2020

「EyeBus 視障者公車預約服務」歷經一年的設計、開發與概念測試 (Proof of Concept, POC)，服務系統串接完成。今年 6–7 月實地於台北市公車南京幹線完成 30 人次服務測試 (Proof of Service, PoS)，以 94% 服務成功率成功驗證該項公共服務的可行性。

文章主旨：以EyeBus經驗為例，描述跨場景、跨通路的服務測試之困難與應對。
系列文章定位：後期場域驗證（專案第11-12月）

服務驗證的必要性，在於儘早驗證該服務於真實場域的易用性、穩定性等目標，避免公共服務疏於盤點真實環境因子，建置過於理想的服務系統，以致投入大量資源、完工問世後，才從大眾的回饋中發現斷點重重。

在講述服務驗證的困難前，先從 EyeBus 的專案性質介紹起。

EyeBus 的服務共由 3 項核心設計項目串接（App、車載系統、候車區），服務使用者包含視障者（服務接收者），也包含司機（服務提供者）。服務場景則是不斷變動，從視障者到達 A 公車站作為起點，一路預約到上車，直到於 B 公車站下車。通路部分不必多說，3 項設計線上下串接地非常緊密。

EyeBus專案性質
多關係人：視障者、南京幹線司機
跨場景：A公車站－公車上－B公車站
跨通路：App（線上）、候車區（線下）、車載系統（線上）

在設計圈內，用戶體驗檢測相當常見，研究的應用範圍卻通常僅限於單一關係人、固定場域，且為純線上或線下的產品。EyeBus 在多關係人、跨場景、跨通路的服務驗證中，團隊除更審慎訂定檢測目標、研究方法外，透過多次測試的經驗，也總結出 3 項這類服務驗證的挑戰：

定義完整的測試節點
維護測試場景
盤點非理想使用狀況

首先快速帶大家走過我們服務驗證的過程，看看今年夏天一群過於熱血（？）的設計者是如何在 36°C 的台北盆地做測試⋯⋯

2020.6.24 服務驗證實錄（已獲受測者孫小姐授權）

在這些測試裡面，我們達成數項成就：

紀錄整體服務成效，提出具說服力測試成果。
突破過往相似專案內定受測者，直接於網路招募視障受測者。
所有視障受測者皆為初次參與測試，在半小時內學會獨力使用服務。

（視障者受感官限制，學習搭公車前須經定向老師多次教學，熟悉公車站環境及車體。其學習門檻之高，導致視障者多半只搭乘固定通勤路線。）

所有南京幹線司機都是在執勤間隨機接收預約訊息，無指定測試班次。

教學 → 體驗 → 訪談，流程看起來不就這樣？

如果先看了上面的影片，各位會發現團隊所規劃的服務驗證流程與多數測試相同，會經過事前教學，再讓視障者自主體驗，使用服務系統預約並搭乘公車成功，最後訪談，每場費時約 2 小時。

測試流程一樣，卻又極不一樣。看似簡單直觀的測試流程，一旦置入真實場域，須耗費極大心力推演可能狀況、還有幕後人員東奔西跑採集數據，才能為受測者營造不耗體力（對視障者更須增加安全感）的測試流程、一個包容其自由行動的測試環境。

一起進入正文，看看跨場景、跨通路的服務驗證有哪些挑戰、我們如何應變及後續成效。

一、定義完整的測試節點

挑戰：

產品的成功，使用者經驗只是測試指標之一，還得經過壓力測試等多種評估才能更接近上線，公共服務亦然。為在擴大實施前驗證服務系統的可行性，我們必須以 E2E （End-to-end）的角度出發，逐段檢視每個接觸點串接的成效。

作法：

團隊首先定義服務成功率：

視障者初次預約公車，
即可搭上該路線公車並於指定站牌下車。

接著以 MECE (Mutually exclusive collectively exhaustive) 的思維深入服務系統劃分指標，製作出近似電商常用的轉換漏斗 (Conversion funnel)，釐清達成成功服務指標的茫茫路途上，會經過多少可能的流失斷點（交集）又有哪些流程能達成備援效果（聯集）。

在列出下圖的檢測指標後，再將具體依據列出，接下來就可以討論獲得依據的方法：視障者易用性方面，通常能在研究員跟隨在旁時紀錄；後台傳輸狀況，則須依賴工程師在後台撈取紀錄；司機有否於行駛間成功辨識車機，則是以司機主觀回答為準。

在 EyeBus 案中，車載系統是由既有廠商擴充車機功能而來，因此後台的傳輸成敗更能用來驗收廠商之施工品質。

成果：

在蒐集 30 場的測試數據後，服務成功率高達 94%，可向政府證明服務落實於真實場域之穩定性。

使用者易用性達 94%，代表絕大多數視障者可於初次教學後正確使用系統；後台傳輸穩定性、前台提示成功率各為 84%，凸顯預約自 App 傳輸至車機發出提示之成功率目前受制於廠商技術及提示載體，應以 100% 穩定為改善方向；值得注意的是，服務人員配合度達85%，在司機順利停靠至候車區之前提下，無論預約有否順利傳遞至司機，皆致最後成功接乘視障乘客。

同時，我們也在訪談時供受測者、司機填寫問卷，以利前後測比較。結果證明 EyeBus App 相較其他同類型 App 之易用性提升、車載系統之預約提示未增加司機負擔、候車區相較於設置前有效幫助視障者辨識候車位置、司機辨識視障者位置。

全盤的測試成效評估，雖然導致每一場測試都得出到 5 人才能流暢運作，但能獲得服務成效的鐵證，還是相對超划算！

二、維護測試場景

挑戰：

EyeBus 作為嵌入現有公車系統的無障礙服務，必須面對場域中大多數人不是服務使用者、線上下的串接必有誤差⋯⋯等等多種情形，它不是控制好一切變因的設計，必然得面對不理想的使用流程。

為了最終設計出足以包容各種狀況的流程，我們得讓視障受測者在情境下依自由意志與真實環境互動，以便將狀況盤點萬全。

在真實場域測試，就是單純不介入嗎？

在測試中，我們給予受測者「使用 EyeBus 服務乘車抵達某站」的任務，接下來就任其自由行動。然而在真實情境中，我們必須記得受測者本來就能搭上車，比如：直接問隨便一台公車司機，有行經 XX 公車站的就上車；等車時被熱心路人帶離候車區去招車等等。

無論主動或被動地達成任務目的，在未使用 EyeBus 服務的狀況下，無法滿足我們的測試目的，因此偶爾仍是必須喊卡、介入維護測試場景。

作法：

我們將脫離測試場景定義為：受測者無法繼續使用 EyeBus 服務。

同上段舉例，我們透過過去將近一年間的原型測試、訪談經驗，研擬出一系列可能脫離測試場景的狀況。測試現場的研究員都握有一份測試計畫的 pdf 檔，鉅細靡遺地寫好狀況與應對方法（簡直在當大地遊戲的關主）。

另外，雖然系統已可自動運行，但因串接多方廠商、系統，是為廣大交通系統下的一小塊設計，仍容易因為環境變動而時時阻礙系統的順暢運作。比如：南京幹線作為高需求的幹線公車，業者常臨時從鄰線調度增加公車數量，卻也因此混入車載系統未被團隊更新的公車，即受測者預約該輛公車，司機永遠不會收到預約提示。團隊為此特地設置已更新車機的公車白名單，在測試期間避免預約調度車輛，以維持核心服務的順暢運作。