我們如何在台北,
創造改變視障者搭乘體驗的服務設計?【 EyeBus系列文章 】

此系列文章紀錄與科技部合作之視障者搭公車計畫案,將依照下方架構持續更新,本篇為系列文章之導讀,介紹服務觸點及歷程,未來會陸續釋出有關需求研究、設計迭代與場域驗證的文章。
不管您是公部門、關心視障議題、或任何希望投入社會設計者,都歡迎跟著我們,一起走過公共服務設計的實作歷程!

EyeBus,讓視障者安心搭乘公車的服務。

EyeBus 團隊為協助台北市視障者能獨力搭乘公車通勤,設計以利害關係人為中心、跨線上下渠道的公車預約服務,目前已完成 PoC (Proof of Concept) 、POS (Proof of Service) ,並將研發成果轉交予地方政府擴大實施。以下為前後端系統完成後, 2020 年 6 月的視障者試乘影片:

為什麼視障者搭公車的問題應被改善?

視障者的搭乘現況:手舉牌攔車,離呼嘯而過的靠站公車不到 1 公尺

也許你也會好奇,這麼多種大眾交通工具,為什麼視障者一定得搭公車?以全國約 1/4 視障者居住的雙北市而言,即便捷運準時又服務好,站點卻離家很遠;計程車或復康巴士可以直達目的地,花費卻高。公車的路線密佈又便宜,是許多視障者尋求教育、工作和社會連結時,不得不的交通工具。

然而,就如我們共同的公車搭乘經驗,公車到站時間不定、停靠地點也不一。視障者常因候車時未能及時攔車,增加了不少的恐懼和焦慮;未能及時找到停靠車門位置,也常在追車的過程中受傷。這樣的困境導致視障者難以獨立搭乘公車,每一次出門都得做足心理準備。

視障者的乘車困難聚焦於候車、乘車期間:

  • 站對點:視障者即便能依定向訓練經驗抵達公車站,卻未能確定自己所站定點能不被路樹、站牌阻擋。
  • 攔對車:視障者未能辨識即將進站的公車車號,直接導致未能及時攔車。
  • 上對車:即使所欲搭乘的公車順利停靠,卻未能像捷運、鐵路定點對齊,視障者須在短時間內找到車門。

視障者因無法所見即所得,人與環境一來一回的互動顯得阻礙重重,也造成了乘車期間極大的壓力。

根據實際走訪所歸納的用戶旅程地圖 (CJM),可以看到視障者的旅程有很多需要幫助的地方。

複雜的社會困境,由跨渠道的服務設計解套。

我們發現視障者搭乘公車的流程,橫跨了人員、機器與環境的交互關係,並非單一科技、接觸點能輕易解決,此時需要跨渠道的設計來互相輔助。

透過線上下、人機環的交互串接,
形成細緻而順暢的用戶體驗 。

圖源 : Highway #1, Los Angeles, California, USA by 艾華·布爾汀斯基,2003
UX小貼士:
「渠道」可以想像成連接於使用者與服務提供方之間的道路,用戶的體驗具體的反應在道路上的車流。車流的順暢與否,決定了服務提供方能否給予使用者一趟流連忘返的渠道體驗。

坊間常見的服務個案,多著重於單一渠道體驗 (single channel UX) 或是多渠道體驗 (multi-channel UX) 的設計。渠道之間的關係多半是單一往來,或是彼此並無交互關係,比如去菜市場買菜,彼此議價的管道都圍繞於菜攤上那塊綠色的塑膠布上。

隨著科技技術的發達,跨渠道體驗 (cross channel UX) 與全渠道體驗 (omni-channel UX) 顯得更加重要,體驗應包覆人的多方體驗,而非僅著眼於實體或線上。

「全渠道用戶體驗」更在乎的是整個客戶旅程:包含用戶跨渠道的過渡以及他們隨著時間的推移順利完成各個旅程階段的能力。
- Nielsen Norman Group

單一渠道、多渠道、跨渠道與全渠道的異同 (圖源Omnichannel Is Not Rocket Science

回歸到視障者搭公車所遇到的種種設計考量,跨渠道的服務設計思維能有效幫助我們梳理複雜的關係人與歷程。

兩點成線、三線成面,打造EyeBus公車預約服務系統。

根據跨渠道的思維,我們盤點手邊的資源,以三項接觸點提出服務構想:

1. 愛公車 App
使用者:視障者
設計定位:視障者發送公車預約需求
主要功能為預約公車、查詢公車資訊(路線)、候車與下車提醒

2. 車載系統
使用者:公車司機
設計定位:司機接受預約需求
為公車標配,裝載在公車 A 柱,新增接收預約需求的功能、提醒司機接送

3. 前門優先上車區
使用者:視障者、公車司機
設計定位:作為線上系統的現下串接,讓視障者及司機定點接乘
運用警示磚、標線與字樣,標定上車地點,讓公車前門能精準停在視障者面前

由左至右:App操作示意 、車機、等候區

簡單直覺的使用流程,由複雜緊密的系統支撐

專案內容常被質疑「不就是叫車來,這麼簡單的科技何來困難?」其實,為了增加讓服務落地的可能,必須善用既有線上下接觸點,此舉將增加好幾間合作廠商;服務串接公共系統,則必須從頭認識起好多個局處單位。一年下來,平均每天都是一趟信件來回。

UX小貼士:
早期利害關係人的完整佈局、既有資源的串接,是落地的關鍵。以目前台灣的人文環境,公車網路相較其他國家較為密集,在推廣上還是希望以低成本與接受度高為佳,高科技與高造價的產品未必是最能改善現狀的設計。

跟我們一起上車,走一趟 EyeBus 服務!

說了許多,再走一趟服務旅程,細看痛點如何轉為設計。

第一步:事前規劃

# EyeBus App

旅程的第一步,當然是知道要去哪與要怎麼去咯!

App 提供坊間常見的查詢公車、附近站牌功能,與適合視障者的「規劃路線」功能——考量到大部分視障者的搭乘習慣,App 只會列出需要轉乘一次內的所有捷運或公車方法,方便儲存與預約。

受測者正在使用第一版的 App 原型

第二步:抵達站牌

# 前門優先上車區

確定了目的地,接下來該如何到達合適的候車定點呢?

前門優先上車區統一設置於停車格前端,方便視障者辨識、司機定點停靠。

上圖為測試原型(mock-up),仿造磚式警示磚
UX小貼士 1:
視障者在第一次挑選站點時,都會請親朋好友或是定向師幫忙帶領,制定明顯的追跡物與開發新的心理地圖。因此,「如何知道這就是適合的候車定點」的問題就成了最關鍵的問題。
UX小貼士 2:
公車後門是開放給一般輪椅及行動不易者的,而視障者卻因為需要從前門聽取報站與跟司機確認車次,傾向從前門上車。

第三步:等候上車

# EyeBus App
# 車機

當視障者站在了前門優先上車區,就可以開始預約公車咯!

視障者對所欲搭乘的公車按下「預約公車」,預約信號立即傳至車上裝置;預約完成,App 會進入進站倒數頁面,主動以震動、音效發出公車動態。不管螢幕是否開啟,都能有效告知視障者!

受測者站在優先等候區上預約公車

第四步:上車

# 車機
# 前門優先上車區

公車距上車站前一站時,公車再次透過車機收到提醒。進站時,司機將公車前門停靠於前門優先上車區,供視障者直行上車。

司機收到通知後將前門停靠在標線前,受測者可快速探聽詢問
UX小貼士:
根據視障者的習慣,即將上車前視障者將會把手機收入口袋中,慣用手舉起白手杖,左手盡量不持物品,為即將的上車動作做好準備。

第五步:搭乘公車

# EyeBus App

視障者上車後可設定「下車提醒」,一路接收提示,相當於個人的報站系統。

受測者正在使用倒數報站功能
UX小貼士:
根據實際跟訪結果,視障者具有獨立找到車上站位或座位的能力,這方面會依據視障者自身習慣或是各家公車對司機做得教育訓練而有不同的應對方法。

第六步:準備下車

# EyeBus App

視障者可依據下車提醒,走到前門或後門等待下車。

受測者起身,準備將手機收入口袋

第七步:下車

# EyeBus App

下車後,App 會主動詢問是否已到達目的地,並鼓勵給予司機回饋或是簡單地「按讚」。

這裡值得一提的是,大多數的視障者在測試時都會按下 “ 幫司機按讚 ” 這個按鈕,希望能表示自己對於司機的一點感激之情。

受測者下車後,對司機按讚回饋

隨著視障者下車,EyeBus系列文章的導讀也至末尾,想了解專案的前、中、後期執行歷程,都歡迎再往下閱讀其他的設計、研究、心法分享,希望能帶給你一些動力與幫助!

跨渠道用戶體驗的五項原則

我們歸納了一些視障者搭公車專案在協調設計時的準則,並以 Nielsen Norman Group 所頒布的五個全渠道設計應具備之要素:

  • 一致 (consistent) :在所有渠道上提供一致、凝聚感和熟悉的體驗,ex: 不管在搭乘的前中後段,App 都能成為視障者最貼身的助手。
  • 最佳化 (Optimized) :創建最適合特定設備、渠道限制和使用環境的體驗,ex: 優先等候區的設置規則必須適合北市大部分的路邊環境。
  • 無縫 (Seamless) :使渠道轉換盡可能無負擔,ex: 站在視障優先等候區上使用 App 並不會有所斷點。
  • 精心策劃的 (Orchestrated) 在正確的時間,通過正確的個性化互動和消息,主動引導客戶完成其個人旅程,ex: 在公車即將到站,或是即將抵達目的地的渠道切換階段,App 都主動推播、震動與鈴聲提醒,減少負擔。
  • 可合力改善的 (Collaborative)允許客戶同時利用多個渠道合力改善整體用戶體驗與豐富客戶旅程,ex: 視障者能透過 App 的按讚功能、收藏功能與司機反饋來讓整個服務有進步的空間。

遵守這些原則,將會帶領服務提供方、服務維持方與服務使用方在整個服務流程中彼此產生更高的體驗水準。這也督促著我們將更好的服務上線,期許透過服務設計繼續改變真實發生的問題。

期待,用設計讓台北變得更好!

系列文章目錄

服務設計流程三鑽石模型 by 政大別蓮蒂教授 & 台科大唐玄輝教授

EyeBus專案依據三鑽石的服務設計流程完成,以下為各階段的心得分享:

需求研究篇

設計迭代篇

場域驗證篇

如果覺得我們的設計心得有真實幫助到您,也歡迎您不吝嗇地給予我們 50 個拍手唷!

--

--