案例研究 · 約 12 分鐘
擔任團隊中唯一設計師的 19 個月。五個介面、三種文字、四個月上線的 MVP——已上架。這是完整版的故事。
01 · 為何是 CaCa
CaCa 在當地方言裡就是「計程車」。專案原名 MyanGO,因為與已註冊的公司撞名而改名——目標是做出這座城市還沒有的東西:完整的叫車生態系。難就難在——全球的套路在這裡行不通。付款以現金為主、網路會斷、手機多是低階 Android,介面還得同時容納三種毫無共通點的文字系統。
02 · 我的角色
五個介面上的每一個畫面都經過我的手——產品設計、UX 架構、UI、品牌支援、網站。工程師負責開發、營運團隊管車隊;而整個系統怎麼呈現、怎麼流動、怎麼把自己講清楚,由我負責。這份工作不是畫畫面,而是把商業需求變成人真的能照著走的流程。
03 · 挑戰
乘客訂車、司機接單、營運處理爭議——不同的使用者、不同的介面、同一套系統。三個問題貫穿一切:讓分散的需求像同一個產品、為真實環境而非理想流程設計、在 MVP 的速度下不毀掉未來需要的結構。
04 · 生態系地圖
乘客叫車 → 司機接單 → 行程追蹤 → 付款 → 後台管理。在畫任何畫面之前,我先把平台畫成一條迴圈——它標出每個角色從哪裡進入系統,資訊又要在哪裡跨越 App 與內部工具。
05a · 乘客端
註冊、訂車、選點、追蹤、付款、行程狀態——每個叫車 App 都有的流程,為可能拿著人生第一支智慧型手機、訊號又不穩的使用者重新打造。每個訂車狀態都看得見、有名字,App 永遠不會讓你猜車到底來不來。
05b · 司機端
司機端預設深色,每個畫面只回答一個問題:接下來呢?接單通知 → 接受 → 接客 → 行程 → 收款。每個狀態都得撐過烈日、顛簸,和三秒鐘的決策窗口。
05c · 外送
當平台擴張到外送——包括一支腳踏車隊——我先在流程圖上重構,才動畫面。載客邏輯撐得住的地方就重用;包裹不是乘客的地方(交接、收件人、憑證),流程就分岔。圖先行,讓重構誠實。
05d · 營運後台
訂單、使用者、設定、監控,以及平台營運的其餘一切——18 個管理模組、中英雙語,讓營運團隊不必為每個例外人工協調,就能管好整個車隊。
05e · 行銷網站
對外的門面:服務、信任與識別,跨裝置響應式。從設計到開發上線,都由我親手完成。
06 · 設計系統
Token、元件、陰影階層,以及能讓英文 · 中文 · မြန်မာ 同屏共存的字型系統——三種文字沒有共同的節奏、基線或行高。正是這套系統,讓一位設計師能在路線圖不斷變動時,維持五個介面的一致。
07 · 不順利的路徑
網路不穩、附近沒車、付款失敗、GPS 漂移——在仰光,這些不是邊緣案例,是日常。每條關鍵流程都有明確的失敗狀態,因為出錯的瞬間,正是 App 贏得或失去信任的瞬間。
08 · 在地脈絡
現金優先,而無現金支付則建立在 KBZPay 合作上——CaCa 是緬甸第一個整合這款國民錢包的叫車平台,而非走信用卡路線。三文字介面,而非只有英文。預設網路會斷的狀態設計。這些都不是妥協——而是題目本身。真正要抵抗的,是那本全球通用的教科書。
09 · 成果
四個月的 MVP 長成完整平台:乘客與司機 App 上架、外送流程、18 模組後台、市場首例的 KBZPay 合作、對外網站——一個至今仍在服務仰光的產品基礎。
10 · 反思
CaCa 教會我設計生態系,而不是畫面:先理解使用者、營運、商業目標與技術限制如何相連,再把這份複雜變成人真的能用的流程。先看真實的工作流程,再認角色,再畫系統地圖——介面,是最後才來的東西。