修繕媒合平台的服務怎麼運作
「師虎來了」是一個修繕媒合平台，讓客戶透過 App 提出修繕需求，並配對合適的師傅。
平台的核心機制是第三方流程管理，透過審查報價單內容是否清楚完整、追蹤施工進度，以及客服協助雙方溝通協調，以改善傳統修繕資訊不透明的問題，減少爭議發生。
開發資源缺乏的現實：為什麼優化總是排不到
團隊工程師人力非常精簡，且主要投入自建商城系統，專案規模龐大、開發週期長，長期排擠 App 優化資源。多數優化即便設計完成，也難以排進開發，只有發生重大 bug 影響營運時才會被優先處理。
這也促使我調整策略，改從低風險、可快速執行的改動開始推進。
如何用設計推進優化：高頻痛點 × 低風險改動
工程端全力投入商城系統開發，App 改版的空間極小。我的策略是聚焦在「客服詢問頻率最高的問題」，並優先考慮純介面調整（資訊呈現、提示文字），避免動到資料庫與後端邏輯，以降低風險。
高頻痛點優先
以客服詢問頻率為依據，先解決最多用戶碰到的問題。
低風險改動
優先選擇純前端調整，避免動到資料庫或業務流程，降低實作風險。
漸進擴展
從單一頁面的改動出發，逐步擴展至跨頁面的體驗優化。
打不過就加入他們，設計與開發的協作
為了更進一步把優化推到使用者手上，我開始以協作的方式參與 Flutter 實作，並用 Claude Code 加速理解程式碼與測試改動。
這讓設計端更清楚 App 架構限制，也更知道哪些優化是小改就能上、哪些其實需要較大工程。後續設計與開發在討論上更容易對齊，優化也能持續地推進。
案例一：客服聊天室更好找，但不打擾主流程
每張修繕訂單都有客服、客戶、師傅三方彼此的聊天室，負責修繕過程的溝通與紀錄。早期平台客服量能有限，聊天室入口刻意設計得隱蔽；但用戶數量增加後，這個設計反而推高了客服解說成本，甚至需要電話逐步說明入口位置與使用方式。
做法
- 和客服團隊一起盤點訂單流程節點，找出最需要介入的時機。
- 需要主動支援的頁面提高辨識度，其餘頁面維持可找到但低干擾。
- 考量客群偏年長，不熟悉現代 icon，介面加上更直白的文字輔助。
找不到聊天室的問題明顯減少，使用者需要幫助時能更快聯繫到客服。
案例二：報價單位重整，提升效率與透明度
師傅報價需填寫工項、數量、單位與單價，但原本的單位選擇器是 CupertinoPicker 單欄滑動，24 種選項找起來費力。而且排在最前面的「式」過於籠統，容易讓報價內容變得不透明，影響師傅效率也降低報價品質。
做法
- 把單位選擇改成一次可瀏覽全部選項，不用再慢慢滑。
- 適當分類單位 (長度、面積等)，提高選擇效率。
- 當師傅選「式」時，用介面提示鼓勵改用更具體單位。
師傅選單位更快、更準確；「式」的選用比例明顯減少，報價內容更為清晰。
案例三：電子發票功能完善
一張訂單可能涉及派遣費、訂金、尾款等多次付款，每次都要開一張發票，客戶也可能希望不同階段用不同的開立方式。但原本的 App 只支援手機載具和公司發票兩種選項，且下單後無法修改，發票開錯的情況頻繁，客服常需介入協助處理。
做法
- 與工程師一起釐清 ezPay 發票開立的串接規格。
- 擴充開立方式(會員載具、手機條碼載具、自然人憑證載具、公司發票、發票捐贈)，並支援儲存常用發票資料。
- 讓使用者在不同付款階段都能更新發票設定並確認，減少開錯情形發生。
客戶可在各付款階段自行確認發票設定，客服介入協助的情形明顯減少。
結語及反思：限制沒有消失，但我找到推進的方法
在這個專案裡，我遇到的不是單一功能的問題，而是「如何在資源受限下推進體驗」的問題。我的做法是建立一套可持續推進的方法：
- 以高頻痛點做優先排序
- 以低風險改動提高實現機率
- 參與實作並用 AI 加速理解限制與成本
我最大的反思是設計方法的轉變，在限制下，設計的價值不只在提出能解決痛點的方案，更包含務實地取捨，讓方案能夠真正地被實現。