[{"data":1,"prerenderedAt":554},["ShallowReactive",2],{"tiger-master":3,"work-nav-all":505},{"id":4,"title":5,"body":8,"cover":456,"description":426,"details":457,"extension":480,"headline":481,"meta":484,"navigation":485,"order":486,"path":487,"role":488,"seo":489,"seoTitle":491,"slug":494,"status":495,"stem":494,"summary":496,"tags":499,"year":503,"__hash__":504},"works\u002Ftiger-master.md",{"zh":6,"en":7},"師虎來了(修繕媒合平台)","TigerMaster Repair Matching Platform",{"type":9,"value":10,"toc":425},"minimark",[11,238],[12,13,14,18,22,25,33,37,60,64,67,96,100,103,106,112,115,119,122,126,139,145,151,155,158,161,172,178,183,187,190,193,204,210,215,217,221,224,235],"zh",{},[15,16,17],"h2",{"id":17},"修繕媒合平台的服務怎麼運作",[19,20,21],"p",{},"「師虎來了」是一個修繕媒合平台，讓客戶透過 App 提出修繕需求，並配對合適的師傅。",[19,23,24],{},"平台的核心機制是第三方流程管理，透過審查報價單內容是否清楚完整、追蹤施工進度，以及客服協助雙方溝通協調，以改善傳統修繕資訊不透明的問題，減少爭議發生。",[26,27],"full-image",{"alt":28,"caption-en":29,"caption-zh":30,"src":31,":lightbox":32},"師虎來了修繕媒合平台服務流程，連結客戶、師傅與客服三方","A third-party flow connecting requests, quote review, construction tracking, and communication.","平台透作為第三方協調者，串起需求提交、報價審查、施工追蹤與溝通紀錄。","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fservice-flow.webp","false",[15,34,36],{"id":35},"開發資源缺乏的現實為什麼優化總是排不到","開發資源缺乏的現實：為什麼優化總是排不到",[38,39,42,51],"grid",{"align":40,"cols":41},"center",2,[43,44,45,48],"cell",{},[19,46,47],{},"團隊工程師人力非常精簡，且主要投入自建商城系統，專案規模龐大、開發週期長，長期排擠 App 優化資源。多數優化即便設計完成，也難以排進開發，只有發生重大 bug 影響營運時才會被優先處理。",[19,49,50],{},"這也促使我調整策略，改從低風險、可快速執行的改動開始推進。",[43,52,53],{},[19,54,55],{},[56,57],"img",{"alt":58,"src":59},"工程人力精簡，App 優化資源受商城系統開發排擠","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fresource-constraints.webp",[15,61,63],{"id":62},"如何用設計推進優化高頻痛點-低風險改動","如何用設計推進優化：高頻痛點 × 低風險改動",[19,65,66],{},"工程端全力投入商城系統開發，App 改版的空間極小。我的策略是聚焦在「客服詢問頻率最高的問題」，並優先考慮純介面調整（資訊呈現、提示文字），避免動到資料庫與後端邏輯，以降低風險。",[68,69,71,80,88],"info-cards",{"cols":70},3,[72,73,77],"info-card",{"icon":74,"title-en":75,"title-zh":76},"material-symbols:support-agent","High-Frequency Pain Points First","高頻痛點優先",[19,78,79],{},"以客服詢問頻率為依據，先解決最多用戶碰到的問題。",[72,81,85],{"icon":82,"title-en":83,"title-zh":84},"material-symbols:tune","Low-Risk Changes","低風險改動",[19,86,87],{},"優先選擇純前端調整，避免動到資料庫或業務流程，降低實作風險。",[72,89,93],{"icon":90,"title-en":91,"title-zh":92},"material-symbols:expand-circle-right","Gradual Expansion","漸進擴展",[19,94,95],{},"從單一頁面的改動出發，逐步擴展至跨頁面的體驗優化。",[15,97,99],{"id":98},"打不過就加入他們設計與開發的協作","打不過就加入他們，設計與開發的協作",[19,101,102],{},"為了更進一步把優化推到使用者手上，我開始以協作的方式參與 Flutter 實作，並用 Claude Code 加速理解程式碼與測試改動。",[19,104,105],{},"這讓設計端更清楚 App 架構限制，也更知道哪些優化是小改就能上、哪些其實需要較大工程。後續設計與開發在討論上更容易對齊，優化也能持續地推進。",[26,107],{"alt":108,"caption-en":109,"caption-zh":110,"src":111,":lightbox":32},"藉由 Claude Code 參與 Flutter 實作，加速設計與開發的協作流程","Using Claude Code in Flutter implementation helped design align with real constraints and costs.","藉由 Claude Code 參與 Flutter 實作後，設計討論能更快對齊實際架構限制與改動成本。","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fdesign-development-collaboration.webp",[113,114],"hr",{},[15,116,118],{"id":117},"案例一客服聊天室更好找但不打擾主流程","案例一：客服聊天室更好找，但不打擾主流程",[19,120,121],{},"每張修繕訂單都有客服、客戶、師傅三方彼此的聊天室，負責修繕過程的溝通與紀錄。早期平台客服量能有限，聊天室入口刻意設計得隱蔽；但用戶數量增加後，這個設計反而推高了客服解說成本，甚至需要電話逐步說明入口位置與使用方式。",[123,124,125],"h3",{"id":125},"做法",[127,128,129,133,136],"ul",{},[130,131,132],"li",{},"和客服團隊一起盤點訂單流程節點，找出最需要介入的時機。",[130,134,135],{},"需要主動支援的頁面提高辨識度，其餘頁面維持可找到但低干擾。",[130,137,138],{},"考量客群偏年長，不熟悉現代 icon，介面加上更直白的文字輔助。",[26,140],{"alt":141,"caption-en":142,"caption-zh":143,"src":144},"提升修繕訂單頁面的客服聊天室入口辨識度","A clearer chat entry helped users reach support faster.","提高聊天室入口辨識度，讓使用者在需要協助時更快找到客服。","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fcase1-chat-entry.webp",[146,147,148],"blockquote",{},[19,149,150],{},"找不到聊天室的問題明顯減少，使用者需要幫助時能更快聯繫到客服。",[15,152,154],{"id":153},"案例二報價單位重整提升效率與透明度","案例二：報價單位重整，提升效率與透明度",[19,156,157],{},"師傅報價需填寫工項、數量、單位與單價，但原本的單位選擇器是 CupertinoPicker 單欄滑動，24 種選項找起來費力。而且排在最前面的「式」過於籠統，容易讓報價內容變得不透明，影響師傅效率也降低報價品質。",[123,159,125],{"id":160},"做法-1",[127,162,163,166,169],{},[130,164,165],{},"把單位選擇改成一次可瀏覽全部選項，不用再慢慢滑。",[130,167,168],{},"適當分類單位 (長度、面積等)，提高選擇效率。",[130,170,171],{},"當師傅選「式」時，用介面提示鼓勵改用更具體單位。",[26,173],{"alt":174,"caption-en":175,"caption-zh":176,"src":177},"報價單位選擇器從滾輪式改為分類清單","A categorized list made quote units easier and more precise.","將滾輪式單位選擇改為分類清單，降低尋找成本並鼓勵更精確的報價單位。","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fcase2-unit-selector.webp",[146,179,180],{},[19,181,182],{},"師傅選單位更快、更準確；「式」的選用比例明顯減少，報價內容更為清晰。",[15,184,186],{"id":185},"案例三電子發票功能完善","案例三：電子發票功能完善",[19,188,189],{},"一張訂單可能涉及派遣費、訂金、尾款等多次付款，每次都要開一張發票，客戶也可能希望不同階段用不同的開立方式。但原本的 App 只支援手機載具和公司發票兩種選項，且下單後無法修改，發票開錯的情況頻繁，客服常需介入協助處理。",[123,191,125],{"id":192},"做法-2",[127,194,195,198,201],{},[130,196,197],{},"與工程師一起釐清 ezPay 發票開立的串接規格。",[130,199,200],{},"擴充開立方式(會員載具、手機條碼載具、自然人憑證載具、公司發票、發票捐贈)，並支援儲存常用發票資料。",[130,202,203],{},"讓使用者在不同付款階段都能更新發票設定並確認，減少開錯情形發生。",[26,205],{"alt":206,"caption-en":207,"caption-zh":208,"src":209},"電子發票設定擴充多種開立方式，支援各付款階段確認","More invoice options, editable at each payment stage.","擴充發票開立方式，並讓使用者能在不同付款階段確認或更新設定。","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fcase3-invoice-options.webp",[146,211,212],{},[19,213,214],{},"客戶可在各付款階段自行確認發票設定，客服介入協助的情形明顯減少。",[113,216],{},[15,218,220],{"id":219},"結語及反思限制沒有消失但我找到推進的方法","結語及反思：限制沒有消失，但我找到推進的方法",[19,222,223],{},"在這個專案裡，我遇到的不是單一功能的問題，而是「如何在資源受限下推進體驗」的問題。我的做法是建立一套可持續推進的方法：",[127,225,226,229,232],{},[130,227,228],{},"以高頻痛點做優先排序",[130,230,231],{},"以低風險改動提高實現機率",[130,233,234],{},"參與實作並用 AI 加速理解限制與成本",[19,236,237],{},"我最大的反思是設計方法的轉變，在限制下，設計的價值不只在提出能解決痛點的方案，更包含務實地取捨，讓方案能夠真正地被實現。",[239,240,241,245,248,251,254,258,275,279,282,299,303,306,309,312,314,318,321,325,336,339,344,348,351,354,365,368,373,377,380,383,394,397,402,404,408,411,422],"en",{},[15,242,244],{"id":243},"how-tigermaster-works","How TigerMaster Works",[19,246,247],{},"TigerMaster is a home repair matching platform where customers submit repair requests through the app and get matched with suitable contractors.",[19,249,250],{},"The platform's core mechanism is third-party process management: reviewing whether quotes are clear and complete, tracking construction progress, and providing customer service to help both sides communicate and coordinate. This reduces the information opacity common in traditional repair services and lowers the chance of disputes.",[26,252],{"alt":253,"caption-en":29,"caption-zh":30,"src":31,":lightbox":32},"TigerMaster repair matching platform service flow between customer, contractor, and customer service",[15,255,257],{"id":256},"the-reality-of-resource-constraints","The Reality of Resource Constraints",[38,259,260,268],{"align":40,"cols":41},[43,261,262,265],{},[19,263,264],{},"The engineering team was lean and almost entirely committed to building an in-house commerce system, a large project with a long development cycle that consistently pushed app updates aside. Most improvements, even when design was finished, couldn't get scheduled unless a critical bug was threatening operations.",[19,266,267],{},"This pushed me to shift strategy and focus on changes that were low-risk and fast to execute.",[43,269,270],{},[19,271,272],{},[56,273],{"alt":274,"src":59},"Lean engineering resources and app improvements constrained by a large commerce system project",[15,276,278],{"id":277},"design-strategy-high-frequency-pain-points-low-risk-changes","Design Strategy: High-Frequency Pain Points, Low-Risk Changes",[19,280,281],{},"With the engineering team fully committed to the commerce platform, the window for app work was minimal. My strategy was to focus on the issues customers asked about most and prioritize pure interface adjustments (information display, helper text) that avoided database or backend changes, keeping implementation risk low.",[68,283,284,289,294],{"cols":70},[72,285,286],{"icon":74,"title-en":75,"title-zh":76},[19,287,288],{},"Prioritized issues by customer service inquiry frequency, solving the problems most users encountered first.",[72,290,291],{"icon":82,"title-en":83,"title-zh":84},[19,292,293],{},"Focused on frontend-only adjustments, avoiding database or workflow changes to keep implementation risk low.",[72,295,296],{"icon":90,"title-en":91,"title-zh":92},[19,297,298],{},"Started from single-page fixes and expanded gradually to cross-page experience improvements.",[15,300,302],{"id":301},"joining-the-engineering-side","Joining the Engineering Side",[19,304,305],{},"To get improvements into users' hands, I began participating in Flutter implementation as a collaborator and used Claude Code to speed up code comprehension and test changes.",[19,307,308],{},"This gave the design side a clearer picture of the app's architectural constraints and a better sense of which improvements could ship with a small tweak versus which required significant engineering work. Design and development conversations became easier to align, and improvements could keep moving forward.",[26,310],{"alt":311,"caption-en":109,"caption-zh":110,"src":111,":lightbox":32},"Design and Flutter development collaboration workflow using Claude Code to understand and test app changes",[113,313],{},[15,315,317],{"id":316},"case-1-making-customer-service-chat-easier-to-find","Case 1: Making Customer Service Chat Easier to Find",[19,319,320],{},"Each repair order has a three-way chat room between the customer service agent, customer, and contractor, used for communication and documentation throughout the repair process. In the platform's early days, when support capacity was limited, the entry point was intentionally kept hidden. But as the user base grew, this became a liability, with support staff needing to walk users through its location and usage by phone.",[123,322,324],{"id":323},"approach","Approach",[127,326,327,330,333],{},[130,328,329],{},"Worked with the customer service team to map the order flow and identify the moments where support was most needed.",[130,331,332],{},"Increased the entry point's visibility on pages that required proactive support, keeping it accessible but unobtrusive elsewhere.",[130,334,335],{},"Given the platform's older user base, added plain-language text labels alongside icons to improve clarity.",[26,337],{"alt":338,"caption-en":142,"caption-zh":143,"src":144},"Customer service chat entry point made easier to find on repair order pages",[146,340,341],{},[19,342,343],{},"Fewer users got lost looking for the chat room, and support became easier to reach.",[15,345,347],{"id":346},"case-2-redesigning-the-quote-unit-selector","Case 2: Redesigning the Quote Unit Selector",[19,349,350],{},"Contractors fill in work items, quantity, unit, and unit price when submitting a quote. The original unit picker used a CupertinoPicker scroll drum with 24 options, making selection tedious. The first option, \"式\" (a catch-all unspecified unit), was too vague and frequently resulted in opaque quotes that reflected poorly on the platform's transparency.",[123,352,324],{"id":353},"approach-1",[127,355,356,359,362],{},[130,357,358],{},"Replaced the scroll picker with a full-view list so all options are visible at once.",[130,360,361],{},"Organized units into categories (length, area, etc.) to speed up selection.",[130,363,364],{},"Added an interface prompt encouraging contractors to choose a more specific unit when \"式\" is selected.",[26,366],{"alt":367,"caption-en":175,"caption-zh":176,"src":177},"Quote unit selector redesigned from scroll picker to categorized full-view list",[146,369,370],{},[19,371,372],{},"Unit selection became faster and clearer, with less reliance on the vague \"式\" unit.",[15,374,376],{"id":375},"case-3-expanding-electronic-invoice-options","Case 3: Expanding Electronic Invoice Options",[19,378,379],{},"A single order can involve multiple payments (dispatch fee, deposit, final payment), each requiring a separate invoice. Customers may also want different issuance methods at different stages. Because the original flow only supported two methods and didn't allow mid-order changes, invoice errors were common and the support team regularly had to step in.",[123,381,324],{"id":382},"approach-2",[127,384,385,388,391],{},[130,386,387],{},"Worked with engineers to clarify the ezPay invoice API integration spec.",[130,389,390],{},"Expanded issuance options to five methods (member carrier, mobile barcode, national ID certificate, corporate invoice, and donation), with support for saving preferred invoice settings.",[130,392,393],{},"Enabled invoice settings to be updated and confirmed at each payment stage, reducing errors.",[26,395],{"alt":396,"caption-en":207,"caption-zh":208,"src":209},"Electronic invoice settings expanded with multiple issuance methods and per-payment confirmation",[146,398,399],{},[19,400,401],{},"Customers could update invoice settings themselves, reducing support intervention.",[113,403],{},[15,405,407],{"id":406},"reflection-constraints-dont-disappear-but-theres-always-a-way-forward","Reflection: Constraints Don't Disappear, but There's Always a Way Forward",[19,409,410],{},"This project wasn't about solving a single feature problem. It was about figuring out how to move experience improvements forward under resource constraints. My approach came down to three things:",[127,412,413,416,419],{},[130,414,415],{},"Prioritizing by pain point frequency",[130,417,418],{},"Increasing the odds of implementation by choosing low-risk changes",[130,420,421],{},"Joining the implementation work and using AI to understand constraints and costs faster",[19,423,424],{},"The biggest shift for me was in how I think about design value. Under constraints, design isn't just about finding the right solution to a problem. It's also about making pragmatic tradeoffs so the solution can actually get built.",{"title":426,"searchDepth":41,"depth":41,"links":427},"",[428,429,430,431,432,435,438,441,442,443,444,445,446,449,452,455],{"id":17,"depth":41,"text":17},{"id":35,"depth":41,"text":36},{"id":62,"depth":41,"text":63},{"id":98,"depth":41,"text":99},{"id":117,"depth":41,"text":118,"children":433},[434],{"id":125,"depth":70,"text":125},{"id":153,"depth":41,"text":154,"children":436},[437],{"id":160,"depth":70,"text":125},{"id":185,"depth":41,"text":186,"children":439},[440],{"id":192,"depth":70,"text":125},{"id":219,"depth":41,"text":220},{"id":243,"depth":41,"text":244},{"id":256,"depth":41,"text":257},{"id":277,"depth":41,"text":278},{"id":301,"depth":41,"text":302},{"id":316,"depth":41,"text":317,"children":447},[448],{"id":323,"depth":70,"text":324},{"id":346,"depth":41,"text":347,"children":450},[451],{"id":353,"depth":70,"text":324},{"id":375,"depth":41,"text":376,"children":453},[454],{"id":382,"depth":70,"text":324},{"id":406,"depth":41,"text":407},"\u002Fimages\u002Fworks\u002Ftiger-master\u002Fcover.webp",[458,465,472],{"label":459,"value":462},{"zh":460,"en":461},"角色","Role",{"zh":463,"en":464},"UI\u002FUX 設計師 + 前端開發協作","UI\u002FUX Designer + Frontend Development Collaboration",{"label":466,"value":469},{"zh":467,"en":468},"團隊","Team",{"zh":470,"en":471},"1位設計師、3位工程師、客服團隊","1 designer, 3 engineers, customer service team",{"label":473,"value":476,"href":479},{"zh":474,"en":475},"產品","Product",{"zh":477,"en":478},"Tiger Master 師虎來了","Tiger Master","https:\u002F\u002Fwww.fdtigermaster.com\u002F","md",{"zh":482,"en":483},"在開發資源缺乏的現實下，透過設計持續推進修繕媒合 App 的體驗","Improving a repair matching app through design despite limited development resources",{},true,4,"\u002Ftiger-master",{"zh":463,"en":464},{"title":490,"description":426},{"zh":6,"en":7},{"zh":492,"en":493},"師虎來了 - 資源受限下的 App 體驗優化","TigerMaster: UX improvements under dev constraints","tiger-master","published",{"zh":497,"en":498},"在開發資源長期被大型專案佔用的情況下，我改用「高頻痛點 × 低風險改動」的方式推進 App 優化，並透過參與實作與 AI 輔助，讓優化能實現、設計與開發更容易對齊。","With development resources long occupied by larger projects, I shifted to a high-frequency pain points, low-risk changes approach to move app improvements forward. By joining implementation work and using AI support, optimizations became more feasible and design-development alignment became easier.",[500,501,502],"B2C","Mobile","Dev",2025,"YUPPCED0pp_koQc2PgdwqFiy-ReocTcvdxiB-jltNWE",[506,516,524,533,536,544],{"slug":507,"title":508,"cover":510,"tags":511,"order":515},"morph-inspect",{"zh":509,"en":509},"Morph Inspect","\u002Fimages\u002Fworks\u002Fmorph-inspect\u002Fcover.webp",[512,513,501,514],"AI","B2B","Web",1,{"slug":517,"title":518,"cover":520,"tags":521,"order":41},"spin-the-wheel",{"zh":519,"en":519},"Spin The Wheel","\u002Fimages\u002Fworks\u002Fspin-the-wheel\u002Fcover.webp",[522,523,502],"Wearable","Connect IQ",{"slug":525,"title":526,"cover":529,"tags":530,"order":70},"sim-monitor-dashboard",{"zh":527,"en":528},"散熱模擬監控儀表板","Thermal Simulation Monitoring Dashboard","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fcover.webp",[531,532,502],"Design Challenge","IA",{"slug":494,"title":534,"cover":456,"tags":535,"order":486},{"zh":6,"en":7},[500,501,502],{"slug":537,"title":538,"cover":540,"tags":541,"order":543},"yodewang-rebuild",{"zh":539,"en":539},"yodewang.com","\u002Fimages\u002Fworks\u002Fyodewang-rebuild\u002Fcover.webp",[542,512,502],"Portfolio",5,{"slug":545,"title":546,"cover":549,"tags":550,"order":553},"ai-design-system-assistant",{"zh":547,"en":548},"建立一套讓 AI 看懂設計脈絡的知識庫","Building a Knowledge Base That Teaches AI Design Context","\u002Fimages\u002Fworks\u002Fai-design-system-assistant\u002Fcover.webp",[551,552,512],"[WIP]","Design System",6,1784180138008]