55688 App 建立即時動態與動態島，強化乘客行車通知體驗
專案時程
2025/05 ~ 2025/07
職責範圍
使用者研究、wireframe & mock-up 、設計交付與 UI 驗收測試
合作對象
1 位專案經理、1 位產品設計師 、2 位前端/後端工程師
專案背景
經過乘客訪談與數據追蹤，我們發現線上叫車的乘客取消訂單中，有許多並不是司機不願意接單，而是乘客沒有上車卻取消，乘客也反映到「收不到乘車通知」、「車到了沒提醒我」、「發現車到了來不及準備」等等讓乘客與司機擦身而過的情況，這都將影響 APP 與使用者間的信任關係，也代表我們正在流失即將完成的訂單。
商業目標
強化乘客的等待上車體驗，減少行程取消率
我們期望透過加強乘客端的車輛提醒資訊，協助乘客更容易得知車輛的即時狀況，避免叫到車的乘客們因為流程關係而取消。專案上線 3 個月後順利提高叫車後行程成功的轉換率，並減少叫車成功後又被取消的比率。除了乘客的體驗，同時也降低了司機的等待與空轉時間，進而提高司機們的實際收入與接單效率。
叫車成功轉換率
成長百分比
叫車後取消率
減少百分比
每月平均觸及乘客數
成長觸及數
使用體驗洞察
我們也思考過如何調整司機尋找乘客的流程，但需要配合司機內部運行已久的載客標準流程，會是更長期的迭代方案。於是我們思考更快速的解決方案，從 App 通知乘客的體驗出發，強化手機裝置提醒乘客上車的功能性。
乘客實際在收到上車通知的過程，不如預想順利
等待上車的過程會有來自其他 App 的大量訊息，也會同時操作其他 App，這也都導致訊息被淹沒在列表之中，直接影響乘客時常反映「沒有注意車輛已抵達」、「沒有看到叫車通知」、「看到通知再下樓卻錯過」等情況發生。
叫到車卻上車失敗的乘客中，每年有 70% 的使用者都使用 ios 裝置叫車。這也與 55688 app 的使用者分布數接近，甚至更多。
太多的推播訊息易造成用戶反感，忽略上車通知
我們發現容易漏看訊息的原因其一是「過多的行銷推播」，讓用戶更傾向關閉手機的通知設定，不只直接導致與用戶接觸的管道減少，用戶也更容易忽略重要訊息。因此解決方法便是讓用戶能有所選擇，只看到重要的訊息，又不受其他通知干擾。
競品分析
觀察乘車體驗，分析關鍵資訊與設計要點
在進入動態島的設計之前，我先研究了市場上常見的競品，理解相關功能的用戶心智模型，也遵循 Jakob's Law —— 利用使用者已建立的習慣，降低學習新功能的門檻。分析流程中使用體驗較好與壞的節點，之後便開始定義適合 55688 App 使用者的「行為邏輯與資訊層級」。
我同時也熟讀 iOS Human Interface Guidelines 與 ios 開發者文件，確保與工程師的交付文件符合 iOS 的元件規範，也盤點出控制動態島的元件「即時動態」包含的四種元件狀態。
雙平台一致性與 Android 使用者的考量
由於過去存在雙平台不同步的問題，在此專案中我們也調整了雙平台的通知元件、文案、觸發點設計，確保收到的「搭車訊息」是一致且同樣準確的。雖然目前只開發 ios 的動態島，但經過我們與 Android 工程師的研究下，也確保該平台的實作可能性，在驗證專案成效後，未來也將會進入開發排程中。
＊附圖為 Uber android 的元件畫面
App 設計成果
瞄準叫車流程中的斷點，優先改善最嚴重的問題
儘管時間和資源有限，因此我們需要安排合理的需求優先次序，我們定義了 MVP 範圍，且鎖定「叫車後 -> 上車前」這段乘客最容易因為沒收到通知產生焦慮的過程，優先選擇在此處新增動態島通知功能，期望優化使用者的等待體驗。
動態島 Dynamic island
只要乘客拿起手機
任何時刻都能確認叫車狀況
調整前
調整後
動態島 Dynamic island
設計在每個狀態下對乘客而言最重要的資訊
動態島只會在 app 以外的地方顯示，且使用者的觀看體驗只會有短短幾秒的時間，因此我盤點了搭車過程中所需的乘車資訊，並依重要程度來排序資訊層級，以此來設計卡片樣式。
Priority 0： 抵達時間 → 還有多久會來？
Priority 1：車牌號碼/司機/車型/車牌 → 來的是哪一台車？要如何找車？安全性考量
Priority 2： 上車地點 → 在哪裡與司機會合？
在送出叫車後，乘客在等待司機前來的過程中，分別有「司機多久後抵達」，「司機已經抵達」、「行程準備開始」、「行程被取消」幾種情境。我依照每個狀態下乘客最急迫需要知道的車輛資訊來設計每個狀態下的動態島卡片。
Lock screen + Dynamic Island
兼容舊機型的「即時動態」功能設計
針對沒有動態島功能的舊機型使用者，我也同步設計了「即時動態」在鎖定螢幕狀態的顯示元件，即使顯示樣式有些許差異，但能達到同樣的通知效果，也能讓大多數的 iphone 使用者在手機的鎖屏畫面上看到完全相同的資訊。此功能最低支援到 iphone 8 / iphone se 機型，等同於近 10 年間出的手機裝置都能通用此新功能。
動態島 Dynamic island
強調我們為乘客保留的彈性上車時間
因應台灣的交通，司機的停車位置時常不會是精準的在地圖上的定位可，當碰到巷口、單行道、不可迴轉道時，司機只能停在馬路對向，或是計程車專用的臨停區。因此 App 也提供乘客 3 分鐘的彈性時間，讓司機抵達後能稍微等一下，讓乘客有時間走到司機位置、尋找車輛。而動態島也清楚的支援此功能，明確呈現等候時間讓乘客抓準時間上車。
Design for System Limits
在設計等候時間的狀態時，我希望能夠即時更新「進度條」與「等候時間 」，但在經過實際上路測試後，發現高頻更新會導致動態島偶發性的停止運作。我最後選擇強化「等候時間」的視覺重點，即使進度條非即時更新，但仍能看見清楚的倒數計時，為前往上車的乘客提供更好的視覺線索。
動態島 Dynamic island
即便錯過司機，動態島能讓乘客更容易重新叫車
路況變數多，若乘客仍不小心錯過上車時間，或遲遲等不到司機前來時，在等候時間結束後系統會出現重新叫車按鈕，讓乘客能再以同樣的設定重新叫車，且不必再重新經歷叫車流程。
動態島 Dynamic island
設計符合原生系統規範的 Dark mode、Light mode
在目前的 55688 App 中尚未存在 Dark mode 的設計， 但為了更貼合使用者平時使用 ios 手機的習慣，我在動態島與即時動態上特別新增相應的 UI 樣式，並且確保符合 Apple HIG 規範的對比度標準（ Contrast ratio between 4.5:1 and 7:1 ），讓乘客的瀏覽體驗是清楚且舒適的。
手機推播
App 推播通知體驗優化
一致化通知元件，加強瀏覽性
由於動態島只會在 app 以外的地方顯示，而舊版的「通知元件」仍有待處理的設計債，包含凌亂使用 dialog、toast、pop-up 等元件規格不一致，導致難以閱讀、觸發條件不同等問題。於是我們也一同更新了 App 通知行為，透過文字層級，加強可瀏覽性，讓乘客在 55688 App 的任一處都能獲得與同樣的通知體驗。
讓行銷資訊與乘車通知分流，降低干擾
為了讓推播通知更可控、可預期，我也新增設計了通知設定功能，讓使用者可以分別設定活動訊息、即時位置、上車提示音的開關，讓乘客進一步管理自己想收到的推播通知，提高開啟通知權限的意願。
設計成效
成功提高叫車轉換率
讓 6,200+ 位乘客順利找到他們的司機
專案上線 3 個月後，我們順利提高行程成功的轉換率 +8.3%，多讓 6,200+ 位乘客順利找到他們的司機。並減少叫車成功後又被取消的比率。除了乘客的體驗，由於上車更快速、更準時，一方面也降低了司機的等待與空轉時間，也對提高司機們的實際收入與接單效率有所貢獻。
未來計劃
下一步，涵蓋完整行程的搭乘體驗
經過此專案的正向回饋後，下一階段則是目標將動態島功能涵蓋到從「開始叫車到抵達目的地」的完整乘車體驗，針對台灣特有的計程車司機特性與特殊路況，透過動態島得以更及時的傳遞訊息給乘客，例如：提示司機的位置，得以協助乘客在關鍵時刻能順利找到車。
設計交付 Design hand off
設計交付與工程師的溝通
在動態島的設計交付中，由於不同於一般的 ios 裝置開發流程，大部分的元件參數都仍由原生系統限制，因此設計彈性較低之外，需要花較多的溝通成本來嘗試達到設計稿呈現的目標。於是我分別在交付設計的之前與之後都設立多個 Check point ，定期與工程師溝通，甚至作為 UI 切版畫面的測試人員，以此確保畫面在系統上的可行性，以及是否滿足工程面需要的規格。
因應不同資料結構
設計符合多種情境的 UI
整理乘客等待司機過程的每一個狀態樣式，也包含動態島元件本身的屬性變體，如：compact, expaned, minimal。同時也清楚定義 55688 在與不同 App 相碰時的顯示情形。
建立 QA 資料庫，協助專案後期對 UI 開發結果的驗測流程
原先的開發驗收流程分工較為模糊，因此我們分別在 Figma 與 notion 上建立了專屬於 UI Design QA 流程的標注工具以及模板，協助提升設計師在初步驗收結果時的工作效率。
