線上叫車 App 搜尋地址體驗優化,提高乘客叫車效率

線上叫車 App 搜尋地址體驗優化,提高乘客叫車效率

優化設定地點流程,解決乘客找不到點、找不到車的痛點

專案時程

2024/11 ~ 2025/10(持續中)

職責範圍

使用者研究、wireframe & mock-up 、設計交付與 UI 驗收測試

合作對象

2 位專案經理、1 位產品設計師 、6 位前端/後端工程師

專案背景

App 叫車的使用體驗,是計程車服務的延伸

55688 app 是專門為台灣大車隊設計的計程車叫車平台,讓乘客除了能電話叫車外,多一個能貼近乘客習慣的叫車服務。乘客能自訂不同的搭車需求去媒合司機。自 2024 年新版本上線至今,每個月完成的行程約有 349 萬趟,每月的活躍用戶數將近 13.9 萬人。

隨著叫車服務越來越豐富,流程與條件也越來越複雜,我們為了提供更直覺順暢的線上叫車體驗,我們於是開啟了一系列的優化專案,以貼近乘客實際的搭乘體驗,並 首次在開發中加入使用者研究,希望更深刻瞭解搭車情境

商業目標

提高乘客的「叫車效率」
推動 APP 的搭車數量與營業額提升

提高乘客的「叫車效率」,推動 APP 的搭車轉換率與營業額提升

我們希望透過強化乘客「送出叫車」的使用體驗,提升線上叫車的接單數量。經過與 PM 共同討論主要的產品指標為「線上叫車成功數」與「線上叫車營業額」。同時滿足乘客端與司機端需求,也成功推高 55688 營收。和 2024 年相比,2025 年的成長數據如下:

線上叫車完成數

成長百分比

+
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
.
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
%

線上叫車總營業額

線上叫車營業額

成長百分比

+
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
.
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
%

使用者研究

從問卷調查獲取真實乘客的體驗洞察

為了調查乘客在叫車過程中的潛在問題。我們選擇用「問卷調查」來了解現況。先快速的從不同輪廓的會員中搜集洞察,了解使用者的體驗斷點在何處。為了確保問卷能收集到的回饋有一定的代表性,我們在設計問卷時也制定了原則:

聚焦問題

強調使用 app 送出叫車的過程中碰到的問題,而非「車輛的乘坐體驗」

瞄準活躍用戶

透過 App 直接發送給近期叫過車的乘客,以會員電話來確保問卷的真實性

利於填寫

確保在「乘車中快速填寫」,經過內部填寫測試後,將填寫時間定在 3 分鐘內

問卷發放結果

在發放問券的對象,我們尋找在「半年內曾有使用 55688 app 完成叫車」的會員們,目的是針對新版本 App 的使用回饋,也希望從高頻使用者的角度洞察體驗。問卷上線後的一個月,透過 App 推播、App 廣告、發送簡訊,我們成功送出了 1000+ 份問卷。

共發出 1000+ 份問卷

400+ 份有效問卷回覆

400+ 份有效問卷回覆

78.4% 為高頻使用者

成功觸及每月叫車 3+ 次的乘客

成功觸及每月叫車 3+ 次的乘客

將問卷回饋分類,把主要痛點整理到使用者旅程中

我們分類並框選出有機會透過「調整地址搜尋設計」來改善的問題。發現乘客的體驗斷點大多集中在第一步的「搜尋地點」,也是流失率最高的環節,因為攸關乘客是否能順利上車、順利與司機碰面等。

為獲取更多質化建議,我們與客服人員合作,請乘客主動留下 App 使用回饋。每月我也固定彙整 App store 評論與系統客訴信件,將其整理成月報給開發團隊參考,分類列出嚴重程度,讓設計師與 PM 得以更即時追蹤使用者的體驗狀況。

體驗洞察

與乘客意見對照

痛點集中在「搜尋地址」和「調整上/下車點」

與乘客意見對照,痛點集中在「搜尋地址」和「調整上/下車點」

與乘客回饋交叉比對後,我分別列出了「搜尋地址」與「調整上/下車點」中,前三個影響乘客最嚴重的痛點。許多乘客的反應包含:「叫的車都沒有停在我的位置」、「找不到要去的目的地」,甚至需複製 google 地址,才能在 App 的上成功設定位置。

搜尋地址

輸入關鍵字後,搜尋不到想去的地點

輸入關鍵字後,搜尋不到想去的地點

系統只會顯示詳細的行政地址

系統只會顯示詳細的行政地址

同名不同地的地址容易被誤選

同名不同地的地址容易被誤選

調整上/下車點

乘客不知道何處有計程車管制

乘客不知道何處有計程車管制

實際上下車的位置與 App 設定的有落差

實際上下車的位置與 App 設定的有落差

上/下車點時常設定相反,需來回編輯

上/下車點時常設定相反,需來回編輯

開發順序

根據商業目標和體驗價值

安排需求優先次序

儘管觀察到各式各樣的痛點需求,但開發資源有限,為了讓迭代改版的效益最大化,我們安排合理的開發優先順序。考量是否影響乘客的核心叫車體驗,希望在每次迭代中提高易用性程度,以及視覺友善性,例如:針對字體放大用戶的瀏覽體驗。

設計成果

地址搜尋 4 項優化

以下將詳細介紹由我負責的專案。由於地址的搜尋體驗涵括了前端操作顯示、圖資系統、後端 api 邏輯、司機載客規範等,設計時需要思考多方的限制,確保兼顧 C 端與 B 端的使用體驗順暢。因此我會在設計專案中盡可能爭取使用研究的機會,穿插在專案中讓我驗證自己的設計決策。

體驗優化方案 1

重新設計地址搜尋頁面,讓目的地更好搜尋,降低錯誤率

在過去的問卷調查中,乘客反應最多的問題之一就是「誤選到錯誤的地點」,包含上/下車點設定相反、同名不同地的地址、地點搜尋困難等。由於更新地圖資料需要更多的時間與成本,因此我決定先針對影響使用者操作的「地址搜尋頁面」進行設計優化:

1

改善地址推薦排序:調整搜尋結果排序邏輯,優先顯示距離較近的熱門、常用、最愛地點

2

增加常用地點瀏覽空間:乘客使用歷史地點的次數遠高於最愛地點,在設計考量時決定增加歷史紀錄的瀏覽空間

簡化搭車流程

設定地址更直覺

簡化搭車流程,設定地址更直覺

透過觀察數據 Behavior Flow 發現使用者時常在上下車點兩個頁面來回切換,因此為了明確的指引使用者操作,我進行了流程的調整。

舊版本流程

需先設定下車點後才能設定上車點,想在遠處上車的乘客,常將上/下車點順序搞混。

需要編輯上車點時需點擊返回,前往額外的頁面才能操作,常導致使用者迷路。

調整後

合併頁面,讓乘客能在同一個畫面中瀏覽與編輯上車點下車點,強調兩者的順序關係。

藍色路線:當上/下車點都輸入完成,將直接前往最後的「選擇車種頁面」,節省操作流程。

當乘客需要使用地圖,能自由點擊鍵盤上方的按鈕開啟。

新增地點的距離數

方便判斷地址正確性,提前預估遠近與價格

新增地點的距離數方便判斷地址正確性,提前預估遠近與價格

過去的搜尋推薦結果,只依照關鍵字排序,乘客無法判斷各地點的相對距離。因此我在列表中新增了相對距離數,從幾公尺到數公里之間,讓使用者在搜尋地點時能快速判斷這趟行程的所需距離與車資。另外,由於「同名不同地」情況好發於不同縣市之間,因此透過依照距離遠近排序,也能很大程度地避免誤選的情況發生。

成功提升線上叫車轉換率

成功提升線上叫車轉換率

專案在 2025 年 10 月成功上線後的 3 個月內,我們追蹤到乘客在使用 App 叫車的數據指標有所成長,搜尋地址叫車的乘客與過去相比,叫車效率有確實提升,成功減少線上叫車的阻力。其中「設定下車點完成率」也成功提高,此指摽有助於直接增加司機的接單意願,進而提高承接率。

設定地址完成率

完成率百分比提高至

0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
%

送出叫車轉換時間

用戶操作時間(趟/每秒)

0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
.
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
%
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
.
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
%

線上叫車完成數

增加 100,000+ 趟

+
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
.
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
%

體驗優化方案 2

保持上/下車點的資訊顯示一致

獲得確定性、避免出錯

保持上/下車點的資訊顯示一致,獲得確定性、避免出錯

在問卷結果中,許多乘客提到系統顯示的「詳細地址」過於複雜,反而對正確性有疑慮。原因是雖然司機傾向看到詳細地址,但使用者其實不熟悉每個地點的門牌地址,過於精準反而徒增認知負擔與混淆。因此我在設計時選擇保留使用者當下的選擇結果(地名或地址),並做了以下調整:

1

乘客在搜尋時點選的結果(地名或地址)會維持顯示在叫車流程中,並區別上/下車的 UI 樣式與用色,幫助快速辨認

2

能夠直接輸入地標或地名來搜尋、設定上/下車點,也不影響司機看到的結果

使用者易用性測試,驗證設計並迭代

設計完成後,我們也透過測試來了解設計是否符合心智模型,於是邀請了 3 位頻繁使用叫車 App 的使用者來進行訪談與實測,觀察到乘客在搜尋、瀏覽的行為的確更偏向「記憶地標名稱」為主,且對於系統主動提供的詳細門牌地址感到陌生。

Iteration

讓設計自適應螢幕縮放

優化字體放大後的瀏覽體驗

在測試中,我也觀察到習慣使用「螢幕放大模式」的使用者,會直接放大包含手機系統的所有介面,除了老年人、近視等原因,也有受環境光線低、開車環境影響的使用者。因此在設計中,我主動增加 UI 的顯示彈性,透過 Figma auto layout 與工程師溝通元件響應式效果,滿足每一位乘客的使用體驗。

*針對 Android / ios 使用放大字體、縮放螢幕功能的用戶

因應不同資料結構

設計符合多種情境的 UI

因應不同資料結構設計符合多種情境的 UI

考量到地址資訊「有沒有店面、有沒有地標名稱、有沒有乘客的最愛地點、有沒有乘客歷史紀錄、有沒有計算距離」等情境,要把所有的狀態都盤點出來,才知道 UI 具不具備足夠的彈性。

體驗優化方案 3

新增「建議下車點」功能

引導乘客避開不可搭車的交管區域

新增「建議下車點」功能,引導乘客避開不可搭車的交管區域

台灣的交通有許多停車限制,例如:專用搭乘區、不可臨停區,其中包含信義商場、台北車站、醫院等,通常是計程車需求量高的大型地點(Point Of Interest)。為了避免乘客在 App 上選擇的地點與司機實際停靠位置不同的困境,我先優化了設定下車點的流程:當乘客點擊大型地點時,系統會開啟地圖與 tooltip 提示,並引導乘客選擇該地點的指定上/下車位置。

選擇地址後

在地圖確認交管區域與建議地點

選擇地址後,在地圖確認交管區域與建議地點

1

當乘客在點擊到大型地點時(Point Of Interest),地圖頁面會呈現該地址的「交管範圍」與「建議的上/下車位置」

2

我也設計了對應不同路況的 tookltip 來提醒使用者再次確認新的位置,讓司機與乘客能有所共識

體驗優化方案 4

迭代最愛地點功能,更容易被新增與使用

在 55688 App 中使用最愛地點叫車的比率佔整體的 25% ,雖然在進入搜尋頁面後又接著點擊最愛地點的情況較少,但仍是重要功能之一,因此在主要的優化項目進入開發後,開發時程允許的範圍內,我也主動翻新了最愛地點的介面,並做了功能調整:

1

最愛地點加入到搜尋結果中:讓乘客已經儲存的地點能更容易「被搜尋到」與「被使用到」,提高使用效率。

2

在搜尋列表加入「新增最愛」功能:過去乘客需要從設定頁或行程結束才新增最愛,為了讓乘客更方便取用,能在搜尋流程中發現該按鈕,點擊最標籤就能快速新增最愛地點。

3

最愛地點顯示方式調整:舊版本中會因為乘客的最愛地點數量導致瀏覽空間被大幅壓縮,於是我調整左右滾動瀏覽的樣式,滿足乘客能順利取用與搜尋瀏覽的需求。

在「最愛地點」設定按鈕的迭代過程中,從舊介面樣式調整開始,我嘗試用不同的瀏覽方式切入,不過仍會佔據太大的瀏覽空間。因為瀏覽最愛地點並不是這個流程中,乘客最主要的目的。因此我最後選擇使用 chips 的元件,讓按鈕是足夠好點擊的,又維持在容易檢視的位置。

成功提升最愛地點功能使用率

在專案成功上線後的 3 個月內,我追蹤到新增最愛功能的使用人數逐月增長,並且成功讓更多新使用者使用此功能協助叫車。新增最愛地點功能的使用人數平均成長 +14.2%

測試計劃

功能上線前,邀請乘客與司機進行的測試計劃與迭代

在開發完畢後,我們聯繫了幾位高頻率的核心會員,與司機們共同模擬了實際的叫車場景,也成功獲得測試人員與司機們的肯定,只需 2-3 天的工程調整後便成功上線。

成功獲得乘客的正面反饋

我們也不斷在訪談與意見反饋等質性研究中搜集乘客的滿意度使用回饋,針對我們在「找不到實際上下車點」或「搜尋地點困難」等痛點優化後,收到使用者實際的正面回饋:

團隊影響力

專案之餘,也致力提升設計團隊的協作品質

在這個長期的專案中,經歷了數個設計與開發流程,在流程之間我希望能加入更多真實用戶的聲音,並透過設計文件與團隊共享洞察成果。讓團隊即使在過了幾週後,也得以快速對齊需求並同理乘客的真實場景。

Hand-off

推動 UIUX team 設計文件化,提高設計交付效率

原先設計師需要從不同的專案文件或畫面截圖,來尋找元件、了解流程,因此我選擇主動建立 Design Guideline 並協助建立 UI Kit Library,來提升工作效率。並且在開發團隊之間推動新的交付流程,共同建立「 APP 全畫面設計文件」為設計稿進行版本控制、規格留存,協助工程師更容易看懂設計稿,提高溝通效率。

Design System

建立 UX Guideline
讓設計師好協作,工程師易維護

建立 UX Guideline,讓設計師好協作,工程師易維護

有別於 UI kit ,我在 55688 App Design System 中針對 Tooltip 新增了操作行為規範,並且加註觸發邏輯與使用情境,工程師能檢視所有樣式與對應的使用方法,設計師也能了解如何應用,提高工作效率。

User Research

主動發起使用者訪談與乘客測試計劃

我們邀請到 App 的高頻用戶,透過對乘客進行使用者訪談與易用性測試,讓我們得以快速收集實際叫車的疑問與困境,並將洞察帶回給設計團隊,也影響內部的使用者中心思考風氣,互相分享用戶洞察。其中研究結果之一,包含乘客在設定地址時,是如何搜尋、瀏覽、記憶地址或地點名稱。

Create a free website with Framer, the website builder loved by startups, designers and agencies.