header-guild-uxt.jpg

您目前位於 三鑽石流程的第三階段:場域驗證 UXT

在此可了解到場域驗證的必要性、體驗EyeBus服務、測試計畫

試行成效

將服務置於真實,測試多重環境變因下的韌性。

成果與價值

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

EyeBus 歷經一年的設計、測試與開發,服務系統串接完成。2020 年 6–7 月實地於台北市公車南京幹線完成 30 人次試乘,以 94% 服務成功率成功驗證該項公共服務的可行性。

真實場域驗證的必要性是什麼?

單純設計原型測試不足夠嗎?我們一定要到實際服務場域中嗎?

場域驗證是為及早確認概念之可行性。

在系統正常運作的前提下,擁抱真實場域的突發狀況

服務概念發展至開發完成之期間,若未能儘早於真實場域驗證概念之可行性,容易疏於盤點真實環境因子,建置過於理想的服務系統,以致投入大量資源、完工問世後,才從大眾的回饋中發現斷點重重。服務場域驗證則是依循專案當前之設計開發進度,相互串接成一最小可運行產品(Minimum Viable Product, MVP)。

PTX 異常

候車區遇違停車輛

車機受站播排程阻礙

視障者走上錯誤公車

司機未回報接收提示

路人出手協助視障者

司機過站不停

客運突然調派新車輛

TWCC 維修暫時停止服務

預約車輛與同路線車輛過近

司機未停靠於候車區

視障者提前搭上同路線公車

我們如何步入真實

用戶體驗檢測相當常見,研究的應用範圍卻通常僅限於單一關係人、固定場域,且為純線上或線下的產品。EyeBus 作為多關係人、跨場景、跨通路的公共服務,在驗收成效前,更須定義完整的測試節點、維護測試場景、並在測試中盤點非理想使用狀況。

貼近真實場域的事前籌備

UXT_driver.jpg

事先完成司機教育訓練,行駛中隨機接收預約

研究員統一於2020年6月完成南京幹線全線司機之教育訓練,發予紙本及影音教材供其複習。視障者試乘體驗皆隨機預約公車,研究員同時觀察司機配合服務之狀況。

UXT_driver-2.jpg

突破以往受測者內定,公開招募視障者參與測試

團隊建立方便報讀之 google 問卷,藉視障協會、定向老師之力散播於視障相關社團中,順利回收 63 份報名,有效報名(符受測條件)者 36 位。

跟著研究員與視障朋友,一起體驗 EyeBus 服務!

跟著研究員與視障朋友,一起體驗 EyeBus 服務!

試乘體驗背後的研究資料採集

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

研究資料採集背後的詳盡測試計畫

從路線安排、執行人員工作分配到運作流程說明,只為完整紀錄服務成效

回收測試結果,產出服務洞見

UXT_conclusion-1.jpg

候車區為關鍵接觸點

為服務必要元素,提供司機及視障者易辨識的接乘定位點。

UXT_conclusion-2.jpg

司機配合度主導服務成效

人員配合度為主導因素,能直接導致線下之成功接乘。

UXT_conclusion-3.jpg

系統穩定性尚待加強

前後台穩定性目前較低,系統須以100%穩定性為目標。

將設計丟入真實檢測,才能迎擊所有場域中的意外

盤點真實場域中服務運行不順暢的原因,面對真實的複雜性

驗證目標不在於報告表面的服務成功率,在於盤點真實場域中服務運行不順暢的原因。

一一將其克服,才會在下一次上線時,提前做好應對措施,成為更適應真實場域的設計。