Grab 東南亞交通運輸的產品設計挑戰與實踐 — 以重新設計 Grab app 為例
你是否好奇我們如何透過設計來優化東南亞的交通運輸體驗? 設計師們如何透過場域研究更更貼近東南亞當地的使用者? Grab 作為一個快速發展、顛覆傳統行業的互聯網公司，設計師所面臨的挑戰是什麼，我們如何思考且重新設計在地化的交通運輸服務並影響整個東南亞的使用者?
2016年夏天，我加入東南亞最大的獨角獸新創公司 Grab，Grab 提供超本地化的各種服務，成立於2012年，作為東南亞領先的出行平台，解決了當地重要的交通挑戰，使 6.2 億人的交通自由成為現實。 Grab 的核心產品包括對平台司機和乘客提供便利，安全和可靠的日常交通運輸解決方案，食物外送 GrabFood，包裹快遞以及專有的移動支付平台 GrabPay。在今年初宣布收購東南亞 Uber 後，Grab 正式進入下一個成長階段，打造東南亞領先的線上到線下(O2O)移動平台。我是第20個加入的設計師，當時設計團隊只有10幾個人，現在設計團隊已經成長到近百人了，員工編號也從加入時的1600到現在2萬，根本是指數型發展的大新創公司。在我加入 Grab 之前，我曾經在泰國看過 Grab 的廣告，我當時內心跩跩的覺得：「這設計真的好差，隨便找個設計師都可以做的好一百倍。」在我加入之後，我發現擁有遠大的理想跟你實際去體會那困難與現實狀況完全是兩回事，因為重新設計一個在東南亞每六個人中有一個人在使用的產品並不如想像中這麼簡單。😅 今天這篇文章主要想和大家分享過去兩年半在 Grab 工作中最具挑戰的專案。（本篇不包含整體視覺的定義與 Grab 設計語言的思考過程）
設計挑戰
我們必須滿足八個國家，兩百多個城市的需求，這包含了不同國家的在地化功能（需思考各國政策的法令問題、實地上的交通狀況）、多元語言問題（東南亞每個國家使用不同的語系，所以並沒有通用的語言）、不同人種行為與文化差異（科技產品的熟悉程度、服務的應用場景、宗教的多元性、不同的日常作息）、針對所有 Grab 服務思考它的可擴展性以及在有限的時間內探索更多的可能性。從 2012 年到現在，隨著公司業務的快速擴展，Grab 在同一個 App 裡面持續增加不同的功能，也就是說，這個應用程式已經變成一個巨獸，存在著非常多的技術債跟限制。
此外，對於現有應用程式的歷史遺留問題，這些無法預測的事件並不是這麼容易去解決。同時之間，我們還需要在商業目標，技術可行性和用戶需求之間找到一個完美的平衡點，重新設計整個使用經驗、思考適配所有需求的架構並分析使用者行為進而適應他們的心智模型並創造更好的交通運輸體驗。同時，在整個設計任務中，我們必須思考如何滿足所有利害關係人的需求，並取得共識，讓團隊可以朝一個共同的目標前進。
為什麼我們要做重新設計？
基於以下幾點原因，我們開始了這個專案。
- 從商業發展層面來看：我們想要針對首頁去降低跳出率以及增加各個 Grab 服務類別的可發現性，讓使用者更容易的找到我們的服務。（例如：交通運輸，食物外送 GrabFood，包裹快遞以及支付平台 GrabPay）
- 從現有產品的技術限制來看：由於技術債務的積累，之前的應用程序設計和架構很難擴展，Grab 作為一個全方位發展的服務平台，短時間內擴展了許多新服務，我們必須了解與聆聽各個團隊的需求並找到完美的平衡點，基於這種限制下，導致各種理想的設計方案更加難以實現。
- 從使用者痛點（這邊先列出叫車前的痛點）角度思考： 目前許多東南亞的使用者仍然使用低端的手機，而之前 Grab 並沒有特別針對小螢幕手機的使用體驗做優化，導致很多持有低端手機的使用者會有操作上的困難。例如，多數小螢幕手機的使用者只會看到非常少量的地圖，很難去確認整個搭車的訊息；很多介面組件互相重疊在一起；過多的資訊負載量等等。並且，大多數訂車組件與使用者選取的車種並無關係，訂車組件的擴展性非常的差，並沒有針對不同情境顯示正確的組件。大多數時候，我們的興趣點POI（Point of interest）預測是不精準的，使用者必須花費更多的點擊數去編輯起始點跟終點位置。至於地圖組件方面，對於色盲與弱勢團體的無障礙體驗非常差，多數時候使用者根本無法理解完整的旅程訊息。
我們是怎麼開始這個專案的？ 😁
相較於外商公司的產品設計文化，在高速發展的新創公司中，產品設計的流程並不如你想像中這麼簡單。我們並沒有一套制式化的產品開發流程，很多時候需要倚靠產品設計師去釐清各種利益關係者的需求，例如：了解商業目標、為誰做設計、解決的核心問題、需要跟哪些服務團隊作合作、責任分配、在哪個國家先上線這個服務、線上線下怎麼去整合、司機端的教育計畫、成功指標(measures of success)等等。設計師在打開設計檔案開始設計前一定要梳理好以上需求，但也勢必會經歷探索、發散發想、不間斷的假設驗證、實際產出等等的過程，否則很難有明確的方向跟時程資源規劃。
為了讓 redesign 這專案可以更順利的進行，Grab 的設計團隊通常會先開始一連串的設計工作坊，幫助團隊找到共識，並邀請所有相關的利益關係人參與，包括工程師、產品經理、研究員、設計師加入。在執行工作坊的過程中，我們希望可以確認我們的業務目標、了解使用者的痛點、定義本專案的設計原則、規劃使用者旅程，整合不同的想法，了解競爭對手的優勢並定義我們的成功指標。此外，我們的研究人員也會在過程中分享了我們的使用者洞察跟現有的數據資料。我們希望所有的核心成員可以從使用者的角度出發，建立同理心，同時也從不同角度（使用者/業務/工程可行性）腦力激量更多的想法。
三個核心的設計原則
一連串的工作坊結束後，我們達成共識並重新建構我們的挑戰。我們替這個專案定義了3個核心的設計原則。這些原則是整個團隊的基礎，當我們設計發想新東西或面臨抉擇時，這些原則時時提醒我們最重要的事情。
1. 產品可發現性(Design for discoverability)：在複雜應用場景下的的入口點（entry points）與訊息，應該盡可能的直白且明確，並易於發掘與探索。並給使用者對的資訊、對的推薦、對的功能在對的時間上。
2. 通用且簡單(Simple and accessible)： 過去 Grab App 焦點太多，現在專注在滿足 80% 使用者的需求並符合它們訂車的心理行為模式外，也不可忽略Grab 核心的功能。
3. 設計可擴展性(Design for scalability)： 提供可擴展性、模組化（LEGOlization）的設計，滿足不同國家、不同核心服務（支付、食物運送、交通運輸、快遞）的使用者需求，並在商業需求與使用者通點之間找到平衡點。設計一個可以快速調整、更改和發布到市場，並無需重新設計且極具彈性、有系統的設計元件。
快速且不間斷的假設與驗證，是我們整個專案的重點
在了解我們需要解決的問題、釐清使用者整個旅程（user journeys）的痛點跟思考如何平衡商業模式和技術的可行性並定義我們的 MVP(Minimum Viable Product)後。我們開始從不同層面定義假設，我們根據技術可行性，商業策略，現有產品限制和用戶痛點去思考最適當的解決方案。以 prototype 在不同國家測試使用者並與市場做互動，在得到正/負面使用者回饋後，不斷修改與發想 ideas，再繼續下一輪的驗證。我們通常是產品開發初期就開始透過使用者研究和測試去驗證我們初期假設，提早發現問題並提早治療⛑，快速失敗並快速發現問題，避免那種花了很多時間，設計了全部體驗後再去驗證但發現問題很多的窘境。
- 關於產品可擴展性層面：根據剛剛的使用者痛點那塊可以知道，one tap booking 已經無法再繼續延用下去了，過多的訊息乘載跟複雜且非情境化的叫車模組設計完全無法滿足各方的需求。我們認為把叫車頁面分成兩個頁面可能一來可以解決未來服務擴展性的問題；二來可以優化小螢幕裝置的體驗；三來從運營角度思考的話，面對未來各種車種服務擴展的需求，我們也有彈性空間去應對。
- 關於產品可發現性：Grab 服務的導航具有主功能多且分支非常深的特點，因此通過在導航列中顯示 Grab 核心服務入口點，並以穩定的結構（參考架構段落的描述）提供使用者統一且熟悉的體驗，我們認為這樣可以提高 Grab 服務的轉換率，增加它的可發現性和能見度，並鼓勵使用者探索更多 Grab 的服務。
- 我們根據以往的資料分析了使用者在叫車的心智模型：可以看一下上圖關於 2016 Grab app 首頁的行為分析，我們利用量化與質化的交叉比對，分析它們在點擊叫車按鈕前通常會做什麼，他們的常態點擊模式會是怎麼樣。進而發現舊的 Grab app 完全不符合使用者的行為模式，且發現使用者會有跳耀式的操作行為。也就是說大多數使用者會先查看起始點跟終點位置，如果有需要的話會去切換不同的車種模式（但根據資料顯示，即便 Grab 每個國家有超過十個以上的車種服務，譬如：順風車，計程車，共享車，私家車等等，使用者大多使用少於三種車種服務）再來根據不同的車種，使用者的視覺焦點會移往畫面中央去做不同車種的偏好設定。為了建立更直覺的訂車體驗（從哪裡來➡️去哪裡➡️什麼車種服務➡️什麼特殊需求➡️叫車），我們在新設計的架構原則（下圖）是絕對不能偏離剛剛的分析，盡量遵循使用者訂車的心智模型，進而減少使用上的操作難度跟彈出率。
- 我們的舊 Grab 數據指標顯示，在第一步中預先選擇車輛類型可能不是最重要的：所以基於新的產品架構層面（主頁面提供核心 Grab 服務，次頁面提供各個分支的次級架構）的考量，我們認為把車輛類型菜單放在第二頁，並秉持著提供一致性的結構跟傳達清楚的訊息層級為原則，我們認為可以分開價格跟車輛類型菜單，讓元件模組化之外，也給予不同屬性有各自的空間去發展。
- 之前的體驗是給大部分的使用者呈現出一堆不相關的介面元件：在東南亞每個國家我們都有發展非常多不同種類的車種，也代表著每個車種都有不同的偏好設定需求，之前我們用固定的 Grid view 去展示不同車種的需求，但對於大部分使用者而言，多數時候的設置是不相關且不需要的。同時，對於未來較為複雜的設定以及新型態車種的配置設計較為難以實現。根據數據指標，使用者有特別偏愛的設置模組，我們認為強調最常使用的偏好配置組件（譬如說：支付跟 reward）並提供更情境化以及更有彈性的偏好配置組件可以減少此區塊的複雜度。
關於假設可以有很多不同的類型，從架構層面思考、從互動層面思考、從視覺焦點、從易用性角度、從商業策略、從通用性角度等等。目前就先大略列出以上幾點。
快速的原型迭代搭配持續性的使用者研究
讓產品團隊更有同理心的思考不同區域的體驗並在不同地區展開研究對於此專案至關重要。因為我們考慮到東南亞的多樣性（舉例來說，新加坡和印尼就是兩個非常極端的案例，不同的語言、宗教、生活模式、交通狀況、法規、Grab服務。像我從雅加達市中心到機場需要提早四小時，從新加坡家裡到機場只要提早兩個小時出發，光是交通狀況就差了一倍的時間。）在東南亞，無論你去哪個國家，都有一些相似之處，但也有一些巨大的差別。這就是為什麼我們有這麼多場的使用者研究來幫助我們驗證我們所有的假設，同時也解決不同區域使用者的痛點。
在第一場的研究中，我們在新加坡對 8 名參與者測試現有 Grab app 的體驗，一些是新使用者，一些是現有 Grab 的使用者，一些是偏愛 Grab Taxi 的使用者，一些是偏愛 GrabCar 的使用者，一些是男生，一些是女生，當然也包含不同的年齡區段。我們的目標是了解乘客目前的體驗，使用 Grab 預訂車子時的行為，以及他們的心智模型/對這種體驗的看法。另一個目標是看使用者是否能夠成功的叫車並驗證我們的概念和設計。
在雅加達，我們有 4~5 場不同的使用者研究場次，採用相同的研究方法，但不同的設計方案，當然也會測試不同的車種類型（GrabBike 二輪、GrabCar 四輪）。我們增加了相當多受訪者的數量，以確保我們對每個細分受眾群的使用者進行了測試。我們測試和驗證了不同的假設，並觀察他們在現實世界和實驗室中的叫車行為。第一輪和第二輪是測試乘客端整個 redesign 的流程，分別測試了 onboarding messagne 跟 return user 的體驗。根據前兩輪的回饋，會把之前的研究結果 synthesize，去分析場景跟使用者的互動進而理解使用者的反應跟行為，在分析與討論後，多次修改，並將其納入設計裡面。因此，第3場測試目的在於 revisit 我們整體的體驗。其實我們還有第四場，目的在於測試內部 beta 版本的體驗，因為 beta 版本跟 prototype 還是有差別的，beta 版本涵蓋了各種不同的 edge cases 以及不同情境的 POI 邏輯，這些都是之前 prototype 沒有加入的場景互動。
在我們推出 redesign 後的一週，根據 data 的成效，我們提出了十種以上的 variations，並定義我們的成功指標進而分析各種版本的數據與使用者回饋。同時，研究團隊又再一次把 production version 拿去雅加達去做測試，調查 NBF(new booking flow) 的易用性問題，畢竟每個印尼使用者的標準各不相同。
在這專案中，prototype 扮演著非常重要的角色，我使用 Framer 跟 Flinto 去製作各種不同保真程度(lo-fi / hi-fi)的設計方案跟假設。舉例來說：我們如何銜接 POI 頁面跟首頁的互動（首頁到確認頁面、POI 到確認頁面、確認頁面到 POI、多點下站的互動…等等）。使用者如何去編輯 POI(point of interest)？使用者如何選擇不同的車種服務？我們如何介紹新的體驗？使用者二次造訪時，如何傳達訊息？如何去改變偏好配置設定？如何在複雜的地圖上清楚的顯示旅程並與之互動？在把所有可能的互動建立之後，我將所有原型碎片組合成一個完整的 prototype，這個 prototype 展示了整個 redesign 的完整概念，帶著幾個不同版本與假設的 prototype 去跟 researchers 討論，並跟 content strategists 合作把在地化的版本設計好，最後在雅加達和新加坡進行測試。
2017年10月是一個困難的月份，我和核心團隊開始向相關團隊和高層管理人員報告整個 redesign 體驗、UX流程和MVP版本，希望得到他們的一些對於 redesign 的初步看法。這是一個非常具有挑戰的過程，因為我們從不同的角度收到了許多的關注。這其中包括品牌顏色分歧，叫車體驗的通用性問題，所有 Grab 產品的整體設計語言，提升核心 Grab 服務的可發見性或未來潛在車型的可擴展性。在處理這些回饋、改進設計跟驗證假設的同時，我們必須跟不同團隊的人溝通與協調，利用頻繁的 workshop 跟會議來建立大家的共識。
老實說，我的日常生活有 80% 在溝通，只有 20% 跟設計本身相關。😂
在 50+ 多個原型、無數的 UX flow 和設計迭代之後，我們定義出 MVP 版本。我們重新設計了整個乘客端的訂車體驗，並發布了一套新的地圖元素以提高可讀性和通用性，還為 Grab app 創建了一個全新的設計語言。
在這邊，我來歸結一下根據我們質化跟量化的分析，使用者在叫車時候的行為模式跟一些使用者洞察。
框架跟組件的思考
關於框架的設計準則，我們列出下面重要的三點：
- 穩定且可擴展的框架與組件。
- 模組化作為一個關鍵的準則下，必須不斷思考如何靈活在潛在場景運用組件，並滿足不同 Grab 服務的運營需求。
- 連貫的架構與訊息展現，清楚的訊息層級進而貫穿整個訂車體驗的一至感受。
我們分析了整個旅程的行為並深入探討從訂車到旅程結束的詳細動作。為了在所有接觸點提供更一致的體驗，我們嘗試提供不同應用功能但系統化的組件，並期望這些組件可以給 Grab 不同團隊重複使用。
互動設計準則與定義
Grab 設計語言是一個很大的主題，所以我覺得用另一個獨立的篇章來描述它會更好。在我們開始 Grab 設計語言之前，我們曾經造訪新加坡一個名為“亞洲文明博物館”的地方，主要是為了獲取靈感並了解500多年的東南亞藝術、文化、建築、布料、蠟染和傳統…等。這是一個非常有趣的過程，因為我們從來不知道在東南亞八個國家的差異會如此之大。
關於互動設計探索，在早期階段探索階段，我製作了大量且不同的微互動概念，以展示我們的想法和整體設計，這樣不僅能夠幫助我們說服利益相關者還可以傳達出我們整個 redesign 的具體方向。
整個互動的靈感來自東南亞。它包含了直觀且明智的互動，可以幫助使用者更好的理解產品的邏輯，並增加使用者愉悅感、減少等待的焦慮等等。相反的，不好以及沒有清楚定義準則的 motion/interaction 也會造成反效果，影響效能、增加焦慮感或是使整個操作體驗非常差視覺焦點非常混亂。因此，我們希望微互動的角色不僅可以建立順暢的互動體驗還可以有節奏的展示訊息層級並保證使用者在操作時可以理解整個畫面的邏輯，最好的是給予使用者功能以外更愉悅的體驗。
在定義整體互動設計的時候，我還整合了所有 UI 組件並定義完整的互動指南，包括動畫曲線、動畫準則與運動原理、互動文件的規範模板以及大量的Grab 互動範例搭配展示已經製作出來的 Prototype。基本上，它不僅僅是建立一個文件，更多時候，我們希望鼓勵設計師、工程師和產品經理之間可以說著同樣的語言與術語；有一個基本的互動標準去遵循；減少開發的溝通的困難；同時在建立模組化的互動元件時，也可以讓其他團隊的人重複使用類似的元件，不需要重新刻新的互動。（我會寫另一篇文章來闡述我如何定義整個微互動文件，我的思考模式以及 redesign 這個專案更多的細節。）
下一步，未來？👀
產品設計永遠沒有結束的一天，對於我們來說，推動並實現它只是 redesign 專案的一小步。我們在這專案有更多的事情需要去完成，我們需要改進很多的體驗、修復很多的 bugs、順應未來 Grab 的商業策略做適度的調整（而這也已經發生，New Home Page 專案就是在我們開發進行到一半時從公司商業角度發展出的一個大需求。我會寫另一篇文章去講我們在大型新創公司如何有彈性的處理任何改變，並以 New Home Page 為例子）、追蹤我們的數據並更深入的分析與了解使用者的回饋。我們的重點勢必要建立更全面的設計語言並提供不同的方向以確認較好的設計方案。
Thanks to all the designers for making this happen and being so supportive for this project. ( Danis — Design lead, Guan, Kuang Chih, Fengyi, Therese, Ingrid, Karlton, Gwen, Hillary, Voislav, Nina…etc )
