Sean Design

Overview

GoStation 又稱為「電池交換站」或「換電站」，主要提供 Gogoro 車主來使用能源交換服務，除了台灣之外，目前也陸續擴展到其他國家，而換電站介面上的功能與操作是由我做後續的維護及優化。

設計範疇包含資訊結構與操作動線的規劃，也會搭配易用性測試來做基本驗證。介面上的視覺呈現以延續產品一致性的概念來延伸，若有新的 3D 素材需求會再請專業團隊配合輸出。

在這個產品中我負責的項目有：

資訊模板模組化設計
歡迎頁面資訊呈現優化
電池異常問題回報流程設計

Role
Product Designer
Team
1 PM, 1 Designer, 2 Developer

Project 1

Modular

上方右邊藍色區塊是 GoStation 常用的資訊顯示模板，以往 GoStation 的介面設計注重在各語系的視覺平衡，所以即使看起來相似的版型，間距與字體大小都會有些許差異，並沒有模組化的設計，我們透過下圖來看會更清楚差異。

Challenge

由上圖可以發現單純語系跟區塊的差異就有這麼多間距的變化，雖然依各自情境判斷都可以理解為什麼會需要「微調」，但若以此為基礎去衍生多語系介面後續維護成本將會非常龐大。

除了間距，不同語言的字型與字體大小、行距等等的整合也需要審慎考量，畢竟這些頁面已經是既有用戶熟悉的樣式。

Integration

從已經設計出的畫面中歸納出三個最常使用的版型，分別是固定間距、按鈕置底與按鈕靠中。往後可以依據內容的多寡去決定資訊的呈現方式。除了中、英語系之外，也考量其他語系的閱讀順序與排版。

字型上除了 Gogoro 品牌字型之外，其他語系使用 Noto Sans 系列搭配模組版型去延伸出所有需要的畫面。

Project 2

Welcome Revamp

進行換電時，Hello Charlie 是對用戶體驗非常好的歡迎頁面，但此頁面不難看出右方「Charlie」的空間十分有限，若用戶的名稱較長就會使得畫面擁擠且失衡。再加上日後要往多語系發展的情況下，目前的版型就更需要往彈性的方向調整。

我們的換電動畫根據電動車的電池數量不同，會有些微差異，接下來看一下 1 顆跟 2 顆電池的差別。

Challenge

由於換電過程皆是由動畫影片串起，Hello Charlie 也是在過程的一環，並且單顆電池、雙顆電池的動畫情境都要一起考量，要在不更動動畫的框架下去找到名稱合適的呈現方式。

Revamp Concept

在單顆、雙顆的動畫中可以發現電池落到中間顯示 Hello Charlie 後，都會「向左位移」再接後續的用量計算，所以就可以利用左移後右方騰出來的空間去規劃名稱顯示的彈性。

Project 3

Online Issue Report

GoStation 在過往並沒有妥善的問題回報機制，導致用戶遇到電池異常狀況時就只能打給客服，例如：電池把手斷裂，異常情境時的使用者體驗十分不友善。因應此情境我們開始規劃專屬的電池回報機制與換電站環境回報機制。

Challenge

雖然問題回報機制的優點是可以降低客服的進線率，把資源留給更急迫的用戶，也降低客服的成本。但一旦缺少人為的驗證，「誤報」的問題就會浮現，所以如何在提供友善的回報體驗下，又能減少失誤或是蓄意的回報是一大考驗。

Identification

減少誤報的方式有很多，內部討論後決議是以「身份認證」為首要考量，也就是說，不管是電池異常回報還是換電站環境回報，都必須取得用戶身份才能進行。

考慮到用戶將電池放入換電站後就能取得身份資訊，所以我們將「回報機制」的觸發點規劃在換電的流程中。

Assumption

為了不影響正常換電的使用者，我們將觸發的回報機制的時間點設計在換電結束後的 15 秒內，並大膽假設用戶換電後「收到異常電池時會將該電池再次壓回換電站。」

除了電池異常，我們還需要規劃換電站環境的回報流程，而同樣為了身份認證的考量，內部討論後最終還是規劃在同一個觸發時機。

Suspicion

以使用者體驗的角度，很難理解為了減少誤報，而把身份認證拉到最高標準的原因是什麼。但以公司的角度，回報異常電池後系統除了會鎖定該電池，也會通知相關單位前往查證與回收，也就是電池的供應數量下降、公司派遣成本提高。

雖然當初設計初衷是減少客服的進線量，但功能尚未推出之前，沒有人敢保證誤報所產生的成本會不會小於客服的資源成本。

但目前的問題回報流程其實有諸多疑慮，例如：

用戶一開始要怎麼知道有回報機制？
用戶只能回報退出來的電池？其他電池不能回報嗎？
回報異常電池的觸發點會不會太隱晦？會不會被「回報站點問題」的按鈕給影響？
為什麼回報站點問題，要先進行換電才能觸發？

Usability Testing

與 PM 討論後，一致認為這些疑慮可能會影響問題回報的效益，所以我們安排易用性測試來進行驗證，主要測試的目標如下：

是否能直覺地意識到如何觸發問題回報流程？
是否能順利完成問題回報流程？

Persona

我們在選擇內部測試人員時，唯一的考量只有必須是 Gogoro 車主，這樣才能模擬實際的換電情境。

而為了考量真實性，我們依照是否閱讀過「官方宣告內容」來區分兩組測試者，畢竟實際上用戶可能會先接收到新功能的消息才去嘗試，再加上電池異常回報觸發點較隱晦的情境下，是否有閱讀官方宣導可能會影響實際的操作體驗。

Scenarios

測試情境主要是讓使用者模擬日常的換電流程，搭配我們設定好的異常狀況(如下)，而換電站髒亂比較難模擬自然情境，畢竟每個人對髒亂的定義不同，所以這個情境我們是用口頭引導的方式來處理。

異常一：換電後遇到把手斷裂的電池
異常二：覺得換電站十分髒亂，必須回報

Testing

我們預計選擇 12 位 Gogoro 內部測試人員，再區分為兩組，實際測試時有 1 位因故缺席。

依據異常情境規劃細部任務，任務比分的計算以在預期時間內完成算是得分，如果有繞路或負面情緒會斟酌給分。

Result

電池異常回報
有 5 位發現退出異常電池後，會直覺性壓回換電站，另外 5 位繞路之後走到別的流程，有 1 位直接放棄回報想打客服。即使進入了回報流程，大多都選擇「再換一次」來快速拿到電池，但不管如何只要能意識到壓回去換電站，最終有 10 位皆能拿到新電池。

換電站點髒亂回報
有 5 人可以在換電流程中發現「回報站點問題」，其他 4 人需要明確引導先進行換電流程，其他兩人則是放棄回報。

Insights

測試後除了驗證當初的部分疑慮之外，也額外發現我們設計流程時忽略掉很重要的用戶行為模式，以下是測試後觀察到的重點：

即使有閱讀官方宣告，對於實際操作時還是沒有幫助，因為沒有臨場感，不會特別去記。
當初大膽假設「遇到異常電池會直覺得把電池壓回去」是合理的，受測者都有這樣的操作傾向。
即使部分用戶想壓回異常電池，但看到「回報站點問題」的按鈕會不自覺被吸引而點擊，導致誤報產生。
即使受測者遇到異常電池，大多人傾向先確保自己換到正常電池後，才會考慮回報問題。

Summary

以一開始的測試目標來說，在測試中得知有超過 7 成的受測者傾向壓回異常電池，這樣就能進入異常電池的回報流程，也就一定能拿到新電池，這對於原本只能打客服乾等的情況來說，已經是顯著的改善。

雖然我們觀察到用戶大多在乎的是確保自己拿到正常的電池，也許不會想協助回報異常電池，不過這樣也是我們樂見的結果，至少不會讓用戶產生負面情緒。 異常回報確實能有效改善客服負擔，雖然人性上不一定會協助回報，不過是可接受的結果。

But...

我們一開始最擔心的站點回報問題誤導問題確實發生了，而且機率不低，也的確影響到電池異常回報的進入點，而「回報站點問題」的誤導所衍生的是資訊架構與流程規劃的問題，內部得知測試結果後，也不再堅持回報站點必須通過身份認證，轉而將此流程規劃在支援服務的架構下。

Gogoro GoStation - 換電站流程優化

Learnings

Next Work