.png)
專案期間
擔任角色
6 個月
UI / UX 設計師
使用者研究、客戶需求收斂、設計介面 App
最貼近司機的 App，提供司機安心接任務的平台
職責
專案概覽
01 | 團隊目標
為客戶從 0 到 1 設計接送寵物的司機端 App ，收斂客戶需求、調查司機痛點，優化司機接派遣任務的體驗，讓司機有更好的服務品質。
02 | 角色與產出
與 PM、工程師團隊溝通與合作，維護專案規格書文件及與客戶開會討論產品功能地圖，並設計出產品介面 Mockup。
04 | 目前專案成果
03 | 專案挑戰
由於本專案合作模式較特別，我方負責司機端而第三方負責飼主端，因此除了面對客戶外，還需跟第三方相互配合。
針對客戶及終端使用者的回饋，產出及優化主要頁面的 flow 以及介面。同時從使用者身上收到了正面反饋。
專案背景
Pexi 是專門提供寵物計程車服務的 App。服務內容主要為寵物接送至指定商家或是指定地點，服務對象目前為中小型狗及貓咪。飼主會在 User 端填寫好寵物的基本資料（品種、體重、個性、年紀等）、寵物乘車備註以及上下車地點等。
Pexi Driver App 主要目的讓司機順利接送寵物以及查看薪資、行程紀錄等，若有緊急事件需要回報也可以利用客服回報狀況，當完成寵物接送任務時，能夠即時給予乘客評價。Driver App 雖與一般的司機App 性質相似，但因載送的目標為寵物，思考出發點最大相異的地方在於寵物無法與人溝通，所以 App 一定須提供司機足夠的寵物資訊以及寵物相關應急措施，確保司機能夠順利接送對的寵物及方便與商家、主人核對資料。同時寵物若在半路有緊急狀況，也能藉由 App 緊急聯絡主人確認後續處理方式，提供司機與主人安心溝通的橋樑。
合作方式與流程
.png)
本專案的合作模式較為特別，由我方公司負責設計實作司機端 App，由第三方公司負責設計實作飼主端 App，因此我方除了面對客戶需求外，還需與第三方相互配合，同時不能忘記以使用者的意見為中心，符合客戶需求同時也需挖掘使用者的痛點加以優化。
01.
了解客戶需求及產品定位
02.
進行使用者研究、
了解使用者痛點
03.
規劃產品流程
三方會議密集討論
已知產品定位為專載寵物計程車，初期引導客戶思考：例如可載寵物種類、派遣車型、車資計算費率為何等，也助於日後設計介面。
因為產品依舊以使用者為本，因此了解客戶需求後需對使用者進行使用者訪談挖掘真實痛點、使用者旅途了解流程。
構想合適的介面以及流程，
請團隊內部確認實作可行性，確定後再以 Wireframe 形式與客戶溝通設計細節。
04.
使用者給予回饋並加以優化
利用 Figma prototype 展示給客戶，進一步蒐集更多回饋及優化介面。
使用者研究
專案前期，我訪談了 6 位計程車司機，調查司機對於目前 Driver App 不滿意的痛點有哪些，以及先前載過寵物的相關經歷為何，以下是我從這次研究中所學習到的事情：
使用者研究洞察
“ 我不清楚會載到什麼樣的動物，甚至多少隻。
司機表示接任務時，因為不清楚寵物數量，無法評估是否需要用到後車廂空間，造成司機常常到了飼主家才慌忙將後車廂物品做收納，擔心飼主因此給予不好的評價。
我無法事先準備適合寵物的位子，也無法先為我的車做防護。
”
後座環境可說是司機很在乎的點，寵物太緊張會尿在後座，司機必須花時間善後，延遲接任務的時間。
1.
2.
3.
整體來說，司機因對寵物的資訊不明確，造成司機無法提供良好服務品質。
司機表示無法預期動物是大型或小型，怕大型動物的司機會不敢接關於寵物的任務。
訪談對象人物誌 Persona
我將訪談對象歸納成兩個人物誌， 它可以幫助了解我們到底要為誰設計，以及在優化體驗時需要注意的細節與設計方向。
人物介紹
Tim ｜計程車司機兼義消
Tim 兼差司機快滿 1 年，工作其餘時間擔任義消，對動物不排斥，很愛護車內環境，定期保養愛車。
Nancy ｜全職計程車司機
Nancy 擔任司機已５年，傾向接熟悉路線的任務。有飼養寵物的經驗，但對於中大型犬仍會害怕。
人物需求
1. 想迅速知道乘客上下車地點
2. 想知道乘客是否有後車廂需求
3. 想知道寵物是否會裝籠
1. 想迅速知道乘客上下車地點
2.想迅速知道任務是否成功承接
3.想知道寵物類型為小型還是中大型
使用者旅程地圖
我透過使用者旅程圖 User Journey Map，找出司機在接任務過程中的痛點及情緒，比對司機情緒的高低處，可以進一步瞭解從哪個環節優化能更切合司機們的需求，修正司機認為不佳的體驗。
操作邏輯流程
透過操作邏輯流程 Flow Chart，我將司機接寵物任務每個階段會遇到的抉擇以及情境歸納出來，除了方便與開發人員確認功能外，設計師也能從中歸納司機痛點分別屬於哪個階段以利收斂痛點，以下我列舉了幾個司機反應的痛點以及需要特別留意的流程。
原先的派遣邏輯為：1. 司機點擊決定是否接受任務 2. 系統統計有意願司機 3.系統指派最近的司機前往載客。然而因為等待系統公布的時間很長，會讓司機陷入不確定的狀態。司機反應遇過一個情況是路人招手攔車，司機選擇載路人後，系統才表示任務成功分發，司機只好取消線上任務。
01. 決定是否承接任務
司機反應即時任務頁面資訊缺少「下車地址」這項資訊，使司機無法確定路線是否為自己熟悉的。因有些消費者會要求司機行駛最短距離以求收費低，而司機不夠熟悉的狀態下很常會有繞路的情況，進而造成雙方車資爭議及溝通成本。
此流程需考量到司機是否無法成功前往上車地點的情況，因半路上有機率遇到突發狀況像拋錨、車禍等，因此需設計一個解決流程，提供司機一個入口能跟消費者取消任務，並讓消費者理解必須再另外叫車。
司機反應因無法得知寵物體積及數量等詳細寵物資訊，無法先準備好適當的空間給予寵物。有些司機車種為中大型休旅車，會另外提供空間給大型寵物使用，此時若後車廂有司機私人物品，就必須要花時間將私人物品移至後座空間，會拉長消費者現場的等待時間，司機也無法做好萬全準備。
司機反應偶爾會遇到消費者因為私人原因放鳥司機的情況，但基於系統設定必須在原地等待乘客 15 分鐘後才能接下一個任務，等待時間太長，讓司機覺得浪費了可以接其他任務的時間。
此流程需考量到司機是否無法成功將寵物載往下車地點的情況，因半路上有機率遇到突發狀況，因此需設計一個窗口能跟消費者取得聯繫，並讓消費者前往指定地點將寵物接回。
02. 司機等待任務分發結果
03. 司機前往上車地點
04.司機等待乘客上車
05.司機與乘客確認資訊
06.司機載乘客前往下車地點
07.結束任務後續
此流程需考量到消費者遺失私人物品司機該如何聯絡請對方取回以及寵物若對司機的車內環境進行破壞、撒尿等情況，有無客服管道可以向公司反應等後續處理流程。
設立目標
1. 在介面上呈現明確完整的資訊 -> 讓司機能提前準備、提供優良服務品質。
2. 提供司機突發狀況的緊急措施 -> 突發事件發生時，司機能安心遵循 SOP 處理。
3. 提供明瞭的客服反應管道 -> 若涉及後續賠償能保障司機權益。
設計系統
設計系統可以幫助優化使用者體驗以及統一風格，同時可以檢視自己的專案有沒有矛盾，最快速的方法就是開始整理自己所有的素材庫，包含元件、色票、以及字體風格，一字排開時可以很快的知道有無地方不合邏輯。透過設計系統，也可以幫助我跟工程師更有效率的溝通。
.png)
設計產出
完整透明的任務資訊
接任務介面對司機來說非常重要，資訊若不夠清楚透明對司機會造成許多不便，以下我列舉幾個即時任務頁面的點來說明：
Driver App 首頁
即時任務 pop up
1. 顯示任務類型
任務種類有分三種：
1. Pet Owner to Merchant （指定地點至店家）
2. Merchant to Pet Owner （店家至指定地點）
3. Transport （指定地點 A 至指定地點 B）
接送寵物跟接送一般客人最大差別為：司機需轉交寵物給寵物店家或主人，才算是完成任務。因此需列出任務類別讓司機知道要將寵物明確交給誰。
2. 顯示完整上下車地點
司機最常看的資訊，評估任務上下車地點是否為自己熟悉。
3. 距離與預估時間
司機最常看的資訊，以此了解任務距離以及路線順暢程度。
4. 乘客評價星等
司機可以依據乘客星等篩選任務，篩選具爭議性的客人。
5. 顯示完整寵物資訊
a. 寵物數量
b. 寵物品種
c. 寵物特別備註
有部份司機對於中大型動物有所畏懼，因此動物資訊是司機重要的判斷標準。
完整的突發狀況流程規劃
設計介面同時必須考量司機任務未順利進行之情境，統整歸納各種突發狀況，與團隊討論出統一的流程讓司機可以遵循並處理安置好寵物。
派遣頁面
強制結束任務頁面
.png)
-司機遇突發狀況流程：
點擊 End Trip 按鈕
選擇結束原因
系統依原因調整司機上下線狀態，同時通知飼主端
-突發狀況依照情境可以分為以下五類：
1. 個人原因
2. 交通事故
3. 車子拋錨
4. 寵物問題
5. 系統問題
五種情況都會被系統留下記錄，而前面四種情況都屬於緊急情況，飼主須將寵物接回。系統問題則是司機已到目的地，但是系統判定尚未抵達時使用。
提供即時的客服反映管道
寵物若對司機車內環境進行嚴重破壞，司機給予低評價後會請司機選擇其原因，客服人員將會針對司機反應的事件進行調查，保障司機人車安全的權益，同時也確保飼主不會無緣無故被給予低評價。
確認車資頁面：
本頁主要讓司機再次確認價格是否正確，以及讓司機明瞭乘客付款方式。若價格異動會有紀錄。
評價乘客頁面：
此頁面除了讓司機確認款項是否成功收到，還能透過給予評價反應此趟任務有無不合理之處。
.png)
低評價原因頁面：
若司機評價低於兩顆星，司機必須勾選給予此評價的原因為何，能讓司機意見傳達給客服人員。
另外，同時也蒐集到司機對於流程上的建議，前面有提到司機因為不確定任務是否分發給自己，浪費司機等候時間同時，司機也不好安排路線，因此跟團隊溝通後，我們對派遣邏輯進行了優化：乘客發出接送需求後，任務會依照距離由近到遠依序通知司機，也就是說，司機一但按下『接受任務』後，任務便會確定為司機所承接。
反思與學習
1. 在有限的時間下與客戶溝通
由於當初客戶給予我方公司的設計時間沒有很充裕，設計介面以及流程時有很大的時間壓力，同時客戶對於流程上有很多問題沒有想清楚，因此需盡可能抓緊時間問問題，統整了一系列的「問題集」讓客戶線上回覆，客戶的回覆若沒有切中要點，也可以透過每週一次的線上會議當面詢問。
2. 有限的預算下進行使用者研究
由於此專案的時間與預算都非常有限，因此前期未給予充裕的使用者研究的時間。雖然公司之前有做過相關派遣的專案，但由於我還是希望產品能以使用者出發，忠於使用者的痛點及想法，因此我自己額外花時間找可訪談且有經驗的司機，主管見我對使用者研究很有心做好，便透過人脈介紹了其他司機名單。
3. 客戶意見與使用者意見的衡量
因為公司主要以客戶為主，畢竟資金來源為客戶。但客戶的選擇對使用者不一定是直覺的，因此開會溝通時盡量以「選擇題」為主，提供多個方案讓客戶選擇，也能幫助客戶梳理邏輯以及流程。
4. 情境百百種，如何制訂出一套通用的流程
使用者使用的情境百百種，進行流程規劃時常常會需要思考各種情境下使用者需有哪些 action，但若情境太多太分散時可能會導致 user flow 混亂，此時必須將情境做分類，給使用者一套通用的解決方式，才不會讓使用者暈頭轉向。
5. 考量司機端同時也須留意飼主端資料
因為多公司合作的關係，司機端 App是我負責設計的，飼主端 App 是其他公司設計師負責，合作溝通上會較不容易，在處理司機端 App 同時也須思考飼主端的資料須有哪些與我方串接，才能確保司機端 App 能夠順利拿到資料並且提供呈現介面給司機。
.png)