服務原型測試前要規劃的3件事
「視障者公車搭乘計畫」是一項協助視障者在台北市獨立搭乘公車通勤的服務設計專案，目前已經執行到第 11 個月，可以點此回顧我們在前期研究階段的文章。以時間軸來看，這是團隊的第二次服務概念測試，首次 3 項設計皆以原型測試服務概念之可行性。
在數個月富奸（從《獵人》來的，義同拖稿，大家勿忘這部鉅著啊 XD）的期間，除了每天戰戰兢兢地收看疫情公告，這項計畫也已經走過議題研究、設計發展到測試驗證的階段，今天就要跟各位分享我們規劃服務原型測試的經驗。
專案性質簡述
為了讓視障者有個安全、受保障的旅程，團隊規劃了到達公車站候車區 → 使用手機 App 預約公車 → 公車司機從車機接收預約通知 → 公車司機進站在候車區接乘視障者的服務流程。
這個服務概念有幾項特色：跨場景（公車亭、公車上）、多模態（視覺、聽覺或免持操作）、特殊族群使用（視障者）；而組織編制的關係，我們更有分別運作的 App、車載系統、候車區 3 個設計組別，也就是分屬服務系統的三個渠道。
欸所以，這一套服務流程到底能不能用啊？
這就是我們這一整篇要解答的問題啦～
本文描述的測試時間是，三個渠道設計已經完成，但是還沒有測試概念是否需要可行、尚未實際落地前的測試。接下來的文章，將分為三個段落，逐步帶各位一覽我們在正式讓測試落地前走過的漫漫長路：
- 整合各組測試目標
- 決定原型製作方法
- 全局角度預演落地所遇障礙
整合各組測試目標，規劃一魚多吃的服務系統測試
所有測試計畫中要寫的第一行就是測試目標，我們首先面對上段提到「3組設計」的問題，包含App、車載系統、候車區 。就像公司中各個部門即便合作，各自仍有不同的KPI，團隊中有多組設計的狀況亦然。
因此我們各組在週會中到齊，一同把各組當時的目標攤開並排定順序：
為了驗證服務概念在真實場域是否可行，我們需要為視障者與司機安排一場服務體驗；驗證 App 功能架構，需要請視障者學習 App 並回饋；驗證車載系統會否造成司機負擔，需要請司機服務完視障者後，趁還有印象訪談；驗證候車區設置位置適不適合等候與進站接乘，得另請定向老師依照多年指導視障者搭公車的經驗，給予候車區建議。
從上述考量，可見 App 與車載系統的受測者都會參與服務體驗，有機會融入同一場測試完成。
當然，這樣多目標、多場景的測試，訪談時長、移動路徑需要在事前就為受測者想好，這樣高負擔的活動，受測者大概1個半小時就累得差不多囉。
盤點測試條件與資產，決定原型製作方法
原型，作為一個產品的未完成版本，要低保真、高保真都可以，端看相關的資源。所以我們就開始盤點測試條件，及相關資產，如金錢、人力、時間（就是肝啦）等。
測試條件
測試條件是應測試目標與受測者背景而生。我們曾經設想過是否可以用室內的訪談，完成服務設計概念檢測，或是借個教室搭建場景模擬，但是會產生兩個問題：
一、視障者沒有臨場感，被引導著走完整個教室恐怕什麼都沒體驗到，無法給出真實意見，也無法測試服務體驗的優劣。
二、測試場域偏離真實，無法藉由測試發現公車車機、app、候車亭與使用者相互配合的困難，等於沒有驗證到「整體設計是否可行」的測試目標，也不知道最後進入真實場域所需要的修正。
因此，我們最終決定借用綠野仙蹤（Wizard of Oz）的概念，模擬出一場真實在公車站預約公車的劇本，讓受測者在現實場域中經歷跨場景、多模態的使用旅程，測試我們的服務設計概念。
資產
資產（Assets）在會計定義上是由企業擁有或控制的、預期會給企業帶來經濟利益的資源。筆者挪用在這裡，作為可運用的資源。
盤點資產相當程度決定原型的作法。團隊是由設計師、工程師組成的7人團隊，代表我們具備多樣能力與充沛人數，雖然不能灑大錢搞一場大型演場會，也有足夠的人力跟技術去搭建一個小舞台。
能夠為了製作視障者方便以 VoiceOver 聽讀的 App 原型（限制詳見這篇文章），我們用 Xcode 刻出該次測試所需的客戶端功能；而因為我們願意參與的人多（XD），所以運用人力補足預約公車過程中「尚未被科技串接起來的部分」。
以全局角度預演，測試落地將遇到的外部衝擊
原型測試本身也可以視為一項設計落地，除了花了上半篇幅把原型本身做得好棒棒以外，更要預先著想整個測試在真實場域會遭受的外部衝擊，我們分為人與環境兩方面構思（當然，這還是 by case，像我們會一邊想像著公車亭場景，一邊想像會遭遇什麼困難。）
1. 當視障者可能不願參與測試
前期訪談時，多是我們配合視障者日常乘車路線隨行觀察；但如今已有配合測試的公車路線，勢必得請視障者經歷一場大冒險，來到陌生的站點搭搭看這路公車。
考量視障者最大的焦慮在於前往陌生地點的安全問題，我們跟受測者約在固定有引導服務的捷運站口接送、在每場測試安排伴隨的引導人員、或開放親友以不干擾前提列席測試。
眾多的小細節除了能更尊重受測者以外，在實測也有助於提升視障者參加測試的意願。（招募則是另一門小學問，有機會再寫成文章分享 XD）
2. 定義真實場域中的「真實」
所謂真實是，真的在台北市公車站前，讓視障者使用設計的預約公車的app，照著文章上半部看到的故事板流程，真的讓使用者認為自己預約了一輛公車，並成功搭上。在這一段，我們分別說明每個擬真橋段是如何營造，：
合理的出行任務
為營造視障者從 A 前往 B 點的急迫與必要性，促使其遵循過往乘車習慣臨場應變，團隊在完成受測者的 App 使用教學後，給予受測者「為了拜訪親友須前往 B 點」的任務。
完整的服務歷程體驗
為讓視障者完整體驗預約上車、在車上持續接收提示的體驗，同時顧及上一點「在捷運接送」，我們對於搭乘南京幹線公車的出行任務設定了起迄公車站皆位於捷運站旁、且搭乘公車站數達 5 站以上的嚴苛條件。
擬真的 App 公車動態
為交由視障者獨立操作 App 預約一台公車，公車動態勢必是真實資訊。但當時 App 原型尚未串接公車動態系統API，就由研究員土法煉鋼，手掌並排放 2 台 iPhone 6s，一台開別的公車 App 看動態，一台開 Xcode 後台手動更新站數倒數，讓視障者以為 App 原型是真實運作。（4.7 吋 iPhone 大小真的是剛剛好呀～）
擬真的 App 預約公車
正如上一段所述，開發階段的原型沒有串接公車動態，更不可能串接車載系統，也就是按下預約公車鈕後，沒有公車司機會收到預約。那又該怎麼模擬即時預約呢？我們最美麗的風景（X）最大的資產（Ｏ） — — 人力，就是派上用場的時候！
當視障者送出預約需求，在旁的研究員馬上在 LINE 群組裡通知早已埋伏在公車上的研究員，由車上研究員操作車載系統原型 iPad 發出預約提示，讓司機即時接收訊息。（後面有附圖）
擬真的接乘服務
從上一段看起來，視障者預約某一班公車、車上研究員協助提示該班公車，似乎是很順的流程，但是研究員也太−剛−剛−好−在那台車上了吧？
南京幹線公車作為幹線，尖峰為 4~5 分鐘一班，同一時間線上行駛車數最多達 25 班，班距多近可想而知。手邊能用作車載系統原型、是先安裝在公車上的 iPad 只有 2 台，更不可能每輛車都安排隨行研究員，所以我們做了 2 項盤點：
我們能固定視障者預約的時刻嗎？可以，App 教學時間已經標準化，讓視障者自主預約公車的時刻是可控的。
我們能知道某個時間點會有哪一台南京幹線經過嗎？可以，感謝客運業者調度員的長年經驗，給他一個時刻，他就能告訴我們預計是哪幾班車行經視障者所在的公車站。
就在這樣的前提下，我們達成讓視障者預約可控班次的目標。同時為避免錯失預約時機，讓 2 位研究員分別待在前後班次的公車上，1 人負責測試真的有視障者上車的情境，另 1 人則順便蒐集司機進站接乘卻無視障者上車的情境回饋。
3. 定義真實場域中的「理想」
很多人會想像，在真實場域測試就是要擁抱各式各樣的意外啊！可以接受公車動態與網路上的動態不符、視障者誤搭到鄰近班次的公車、或是根本搭錯公車，以此作為往後服務概念需要補足的斷點。
然而，有些跟測試目標無關的變因仍需要被控制，比如不能被熱心民眾牽著視障者去找車，雖然結果是成功搭車，卻並非是透過我們的服務達成，也無法獲的測試結果。
總結來說，測試現場固然重要，但先前充分的沙盤推演才是本文最重要的部分。以上看似錯綜複雜的測試考量，其實就是每週在各組齊聚的例行週會中，以服務規劃測試為會議主軸，從各自的設計角度提出執行上的困難與要求，共同取捨出共識。
說了那麼多，快速看一下測試現場吧！
測試流程依測試目的而異，在此不做贅述，用幾張照片看圖說故事，簡單描述我們在服務原型測試中各自在忙什麼吧！
簡述一下測試流程：視障者透過場控引導至候車區原型站定，操作 App 原型送出預約訊息後，由 App 研究員即時通知隨車研究員，由隨車研究員遙控車載系統原型發出預約提示。該公車司機於預約站點停靠至候車區原型，並完成接乘之服務。
在等車現場，各位讀者可以從下方圖示看到研究員們各司其職，演出一場不被受訪者發現的預約流程。
在真實場域中，每一場測試都是臨機應變，研究員們隨時拿捏著是否出手干預。比如設置「友善候車區」原型後，年長民眾順理成章、一個箭步就踏在上面等車（下左圖）；或是測試現場，人潮來往得靠研究員幫忙疏導（下中圖）；還有受訪者預約等了太久的車，乾脆跳出 App 開始滑 FB，順道讓我們測試了 App 的 push notification 功能。（下右圖）
在視障者等車的鏡頭之外，車上也早已安排研究員，等著司機完成接乘視障者後，研究員隨車回到公車調度站，趁著司機記憶猶新進行簡短訪談。
另一方面，為了為了不阻礙其他用路人，只要受測者一上車，特地留守一位研究員協助把候車區清除。（不然下一個被投訴的就是我們，怕）
每個測試規則背後，都有一個好的團隊合作
讀完了上面的測試規劃，喘口氣，我們從局外一點的角度再看一次故事。
這場服務測試規劃從綠野仙蹤的原型製作方法出發，經歷了方才所述的各項重點（整合各組測試目標／決定原型製作方法／全局角度預演落地所遇障礙）完成一份公共出行的測試企劃。如果往上抽一層，幾個團隊合作的準則仍是奠基於每份企劃上最基礎的要件：
團隊資訊無落差
藉由每週的固定開會與 stand-up meeting，快速聚焦各組的開發進度跟測試目標，一同研擬出最省力、最能滿足各方的測試方法。
進度時程不勉強
實際來看，服務測試驗證的進度其實大多與原先規劃的時程有些差異。測試時機端看各組當時累積了多少懸而未決的問題，希望透過使用者回饋解決；測試方法則真的要靠團隊的能力與限制，如果為了硬趕時程，只能做出很低保真、視障者沒有臨場感的原型，不如把去現場測試的人力省起來，趕緊開發比較重要。
不過我們會在每一個大階段開始之前，事先規劃大約3–4個月的目標，粗估當中各組應達成哪些測試，大致與 OKR 的工作方式相符。
開放迭代的心
即便測試開始，在不影響測試成效的前提下，測試本身也永遠是場服務設計。總是在每場測試後的 brief 時間，再次討論：
研究員人力能不能再少一些？少點人力就能減輕團隊負荷。
各組的測試資料的蒐集是否符合效率？要用最少的時間滿足最多的目標。
今天有哪些設計從未想過的意外流程？要在下一次測試列入觀察事項或是排除。
比如用 Xcode 寫出的 App 原型，研究員後來為每一場測試前的重置寫下 SOP，以避免任何技術意外，也確實紀錄測試期間的操作畫面。
在 2019 年 12 月疫情尚未延燒至巔峰的時機，我們也開會決議做出防疫措施，要求雙方於測試期間配戴口罩、每場測試前以酒精消毒手機。
總結來說，團隊在做的題目是服務設計，執行的過程也是服務設計。
抱持著「真實場域、以人為本、盡心落地」的心情投入，做好每一個設計、做好每一次測試、做好每一次迭代，然後就能從每一句使用者測試完的回饋中，看到我們的設計正在改變這個環境，改變週遭的人。
許多原先堅信科技解決一切、不相信設計可以改變環境的人，在計畫一次一次的迭代落地當中改變了。越來越多的政府單位願意聽我們的設計發表，越來越多的視障者組織主動協助我們，越來越多的廠商願意合作，這就是設計思考的實踐，這就是服務設計的思維。
系列文章目錄
EyeBus專案依據三鑽石服務設計流程完成，以下為各階段的心得分享，由團隊成員接力編輯：
需求研究篇
- 用戶族群定義：你所不知的視障者
- 服務接收者痛點梳理：視障者的奇幻乘車旅程
- 服務提供者痛點梳理：無障礙服務，公車司機們的知易行難
- 研究心法：隨行觀察法
- App 設計心法：4大設計視障者app報讀原則
設計迭代篇
- App 原型製作： 如何製作可報讀 Prototype
- 持續更新中…
場域驗證篇
- 測試流程：服務原型測試前要規劃的3件事
- 測試規劃：跨場景、跨通路的服務設計驗證實務
如果覺得我們的心得有幫助到您，也請您不吝嗇地給予我們 50 個拍手唷！
