外包還是內製？初創企業選擇設計公司的決策指南與合約要點

初創團隊在要上線 MVP 或快速擴張時，經常要在找設計公司外包、建立內部設計團隊或採取混合模式之間做出取捨。本文提供一套可量化的決策框架、實務檢核表與談判合約要點，包含設計服務範疇驗證、交付與驗收、IP 條款與維運 SLA。讀完後你能立即比較供應商、設計合理付款里程碑，並把合約風險降到可控範圍。

1. 決策框架：何時選擇外包、內製或混合模式

核心觀點：用六個可量化判準把情感決定變成可操作的選擇。 你需要一套能直接映射到時間、成本與風險的尺度，而不是憑感覺挑選設計公司或招人。下面的判準是實務中最常決定成敗的因素。

• 速度 – 你必須多快上線；短期衝刺優先外包。
• 成本 – 短期一次性投入對比長期人事成本與培訓費用。
• 控制權與隱私 – 產品介面或資料是否屬於核心機密。
• 產品複雜度 – 複雜互動、系統整合或需要頻繁迭代通常偏向內製。
• 長期擴展性 – 是否需要持續維運、設計系統與跨產品一致性。
• 人才可取得性 – 當地或遠端能否快速找到合格設計師與前端開發人才。

判準	外包較合適時	內製較合適時	混合模式常見做法
速度	需在數週內交出 MVP 或活動頁面	沒有極短交期、重視長期演進	內部定義方向，外包實作短期任務
成本	短期預算有限，避免長期人事負擔	能承擔人事與招聘成本，重視累積知識	保留核心設計師，外包繁重切版或 campaign
控制權與隱私	非敏感資料或可簽嚴格 NDA	處理敏感資料或設計為核心競爭力	內部保有核心 UX，外包一般視覺與前端
產品複雜度	界面簡單、功能有限	需深度系統整合或複雜互動	內製負責複雜模組，外包完成展示頁或微服務
長期擴展性	測市場或驗證假設的短期專案	產品進入成長期並需要一致性維護	建立設計系統內部持有，外包遵循元件庫
人才可取得性	本地難招到資深人員	能吸引或培育到需要的設計與前端人才	外包補短缺技能，核心團隊長期負責產品方向

決策步驟 – 一個實用流程

實作方式： 給每個判準 1 到 5 分，對應你的商業優先順序再乘以權重。得分差超過 6 分通常會明顯傾向一方；在靠近閾值的情況下優先採用混合模式。這不是學術模型，而是快速形成可操作決策矩陣的工具。

實務判斷： 很多創辦人低估內製培養成本與時間，但也高估外包能解決產品方向不清的問題。外包能快速交付界面與視覺，但當設計需要反覆驗證使用者行為時，內製的累積效果遠勝短期外包。

Concrete example: 一家早期 B2B SaaS 要在 8 週內驗證付費轉換，決定把 UX 研究與產品策略留在內部，外包視覺設計與前端切版。結果是三周內上線可測指標的 MVP，內部人員則在使用數據後主導下一輪迭代。

典型混合分工與協作要點

• 內部保留 – 產品策略、使用者研究、設計系統核心與驗收標準。
• 外包負責 – 視覺產出、頁面切版、短期活動或多媒體素材。
• 協作規則 – 使用共享元件庫（例如 Figma 元件）、在 GitHub 管理前端碼庫、每週同步與明確的驗收里程碑。

下一步的可操作事項：把你的六項判準填成一份 1-5 打分表，設定權重並計算總分，然後以分數決定外包、內製或混合，接著把該決定的關鍵條款列入 RFP 與合約草案。

2. 成本與時程比較：實務上的代價與交付時間差異

直接說清楚：短期要速度就外包，長期要掌控就內製。 設計公司能以現成流程和多人合力換來最快的交付，但那速度背後有三種常被忽略的代價：上線後的接手成本、變更的邊際費用，以及知識留存的缺口。

成本面要拆成三個層級

• 一次性專案成本： 設計公司常用固定價或時薪包案，對於短期 MVP、促銷頁或活動落地有效率，但單次投入通常高於等量內部人力在同一週期的成本。
• 持續性人事成本： 內製需要考慮薪資、福利、招聘時間與人員流動成本。若你的設計工作量穩定且預計持續超過 9 到 12 個月，內製平均每月成本往往低於長期外包。
• 隱性成本與機會成本： 包括工具授權、設計系統建立、知識移轉與因外包導致產品決策延遲的機會成本。這些通常不會出現在供應商報價單，但會推高總成本。

實務判準（保守建議）： 若每月設計工作量穩定超過一位設計師的工作量（約 120 到 160 小時），或者每季需要 2 次以上重大介面改版，內製開始變得經濟且能提高產品一致性。

時程比較與常見延誤來源

項目	設計公司（外包）	內製
啟動速度	通常可在 1 至 2 週內開始專案，快速進入設計與切版流程	招聘與培訓需要 6 週到數月，若已有設計人員則可立即上手
變更反應時間	針對合約外變更需估價，回應時間視供應商負載而變動	小幅改版可立即處理，跨團隊協調成本較低
整體上線時間（MVP）	對單次任務通常最短；但交接與修改會拉長最終可維運的上線時間	初期較慢，但交付物通常內部可直接整合，後續迭代速度更快

時程風險經驗談： 設計公司把專案排進週期時常會出現平行任務競爭。同一周你可能被告知可交付初稿，但真正能把程式碼、設計系統與文件一併交接的時間常晚於預期兩到四週。

Concrete Example: 一家 B2B SaaS 初創需要在 8 週內推出邀請制 MVP。選擇設計公司後，視覺與前端切版在 6 週內完成，但因未包含完整設計系統與元件庫，內部工程上線整合花了額外 3 週。若當初以混合模式保留一位內部產品設計師負責設計系統，整體上線時間反而能縮短且後續改版成本更低。

關鍵取捨：外包換速度與專業度，但增加交接摩擦與長期維運成本；內製換控制與一致性，但前期投入時間與金錢較高。

判斷與下一步： 在評估成本和時程時，把供應商報價拆成交付、交接與後續小改三部分；談判時要求明確的交接里程碑與設計資產清單，並把保留款與驗收條款綁在交接品質上。下一步是把估算的工時換算成每月需求，決定採外包、內製或混合模式。

3. 品質、流程與技術差異：你要問設計公司哪些問題

關鍵觀點： 不要只看視覺好不好看，應該把作品集、交付流程和技術可移轉性當作同等指標來衡量設計公司的成熟度與風險。

檢驗設計作品集的實作指標

要問的第一組問題： 這個案子背後的商業目標是什麼、有沒有量化成果、團隊負責哪些部分。很多初創被漂亮截圖吸引，忽視了是否有 A/B 測試、是否改善了轉換或使用者反饋。若沒有可量化成果，視覺好看只是表面功夫。

• 作品集檢查表： 案例目標與度量指標是否明確
• 可量化成果： 有無轉換、留存或性能改善數據支持
• 同產業經驗： 是否做過相似商業模式的設計服務
• 交付深度： 有沒有設計系統、元件庫或詳細規格文件

技術棧與可移轉性檢查

實務判斷： 創意設計公司不等於工程導向公司。問清楚交付的是高保真視覺稿還是生產就緒的前端程式碼，並確認技術棧與你未來團隊能接手的能力相符。

• 技術細節要問： 是否使用 Figma 原檔、元件命名規則、是否有 tokens 或設計系統
• 前端技術： 交付 HTML/CSS/JS 是否符合可維護標準，使用的是 React、Vue、Next.js 還是僅提供靜態切版
• CMS 與整合： 是否支援 WordPress 或 headless CMS，資料結構是否清楚
• 版本與部署： 是否使用 Git、CI/CD 流程、測試和環境分級

Trade-off 注意： 要快速上線的案子常得到捷徑式切版，短期看起來便宜但未來改版成本高。若你預計頻繁變更介面，寧可在合約初期把元件化與文件化列為交付條件。

專案流程與溝通治理要驗證的項目

流程不是花瓶： 一個成熟的設計公司會把專案管理、變更管理和交付驗收寫進流程，而不是口頭承諾。問他們如何處理 scope creep、誰負責 QA，以及交付後的維運支援如何啟動。

1. 溝通頻率： 每週同步、決策人員到位與會議紀錄機制
2. Issue 管理： 使用哪個工具（Jira、Trello、Asana）以及 ticket 完成定義
3. 驗收標準： 明確列出交付格式、缺陷等級與修復時限
4. 交接義務： 設計檔、原始碼、部署腳本、環境憑證與讀我文件

具體案例： 一家 B2B SaaS 初創在外包 UI/UX 時要求設計公司同時交付 Figma 元件庫和可重用的 React 元件。結果發現視覺團隊交了高品質稿，但沒有聯合工程師進行元件拆解，導致內部工程師重寫 60 的元件。這種情形可以用合約要求的交付項目與代碼審查點事前避免。

不要只問有沒有做過類似案子，問清楚他們在那個案子負責到什麼程度，以及可展示的後續維運數據。

下一步考量： 把這組問題直接放進你的 RFP 與面談腳本，並在初期里程碑中要求示範交付物與一次代碼審查，這比口頭承諾更能降低接手風險。

4. 設計公司選擇檢核表與 RFP 範本要點

關鍵斷言： 寫一份好用的 RFP 並不是把需求寫得最長，而是把可驗收的交付物、技術限制和評分標準寫清楚，這會讓比較供應商變成客觀的數學題，而不是審美投票。

設計公司選擇檢核表（可量化指標）

• 作品集與案例相關度（權重 25%）: 評估同產業案例、同類目標指標的改善數據（轉換率、留存、下載量等）。
• 技術與交付能⼒（權重 20%）: 能否交付你要求的格式與技術棧，例如 Figma 元件庫、React 元件、WordPress 整合或 Headless CMS 支援。
• 專案管理成熟度（權重 15%）: 是否有專案經理、Issue 管理流程、週會節奏與 CI/CD 交付管道。
• 團隊穩定性與替代人力（權重 10%）: 關鍵設計師或工程師是否能被替換，取替成本與交接計劃。
• 維運與支援能力（權重 10%）: SLA、回應時間、每月包時數或保固期內容是否明確。
• 價格透明度與變更政策（權重 10%）: 價格是否拆解為人日、里程碑與額外費率，變更如何估價。
• 客戶口碑與參考（權重 10%）: 提供可聯絡的客戶參考與公開評價，並檢查是否能展示 A/B 或 KPI 結果。

評分項目	範例權重	說明
作品集相關度	30	有直接同業或同目標案例並能提供數據
技術棧與交付格式	20	能交付 Figma、HTML/CSS/JS、元件庫與部署文件
維運 SLA	15	回應時間與月保養時數明確

RFP 範本要點 — 必含段落與範例表述

• 專案摘要與目標: 簡短說明商業目標與主要衡量指標，例如：提升註冊轉換 20% 或縮短新使用者學習時間。
• 範圍與交付物（必列）: Figma 原始檔與元件庫、HTML/CSS/JS 或 React 元件、CMS 接口文件、測試用例與驗收報告、培訓錄影與操作手冊。
• 驗收標準: 指定跨瀏覽器清單、行動裝置支援、功能測試明細與缺陷分級與修復時限。
• 時程與里程碑: 明確欲達成的日期、里程碑交付物與對應付款比例。
• 預算範圍與付款條件: 建議採分段里程碑付款，保留 10–20% 作最終驗收保留金。
• 技術限制與整合需求: 指定需相容的框架或第三方系統（例如 React、WordPress、Google Analytics 等）。
• 維運、保固與 SLA: 明確回應時間、修復時間與每月包時數或額外費用計價方式。
• 變更請求流程: 指定如何提出變更、估價依據與時程影響計算方式。
• 提交說明與評分標準: 要求供應商回覆文件清單、報價表格與預期樣板，並說明評分權重。

範例表述： 我們期望在 12 週內完成高傳真介面與前端交付，交付內容包括完整 Figma 元件庫、React 元件套件、可在 staging 環境運行的前端程式碼與 8 小時的交接訓練課程。

面談與 RFP 補充問題（12 個實務問法）

1. 請描述最接近我們需求的兩個案例與可量化結果。
2. 關鍵設計師與工程師名單為何？若有變動如何保證交付品質？
3. 你們如何把設計決策連結到商業 KPI？有無 A/B 或追蹤範例？
4. 交付的設計檔與原始碼會包含哪些說明文件？
5. 若專案中途要變更範圍，你們的變更流程與計價方式為何？
6. 如何在專案中管理 accessibility 與跨瀏覽器相容性？
7. 是否提供源碼 escrow 或在終止時的交接保證？
8. 維運期內的回應與修復時間如何量化？例外如何計費？
9. 專案是否包含自動化測試或 CI/CD？部署流程怎麼做？
10. 你們如何處理第三方元件或授權成本？
11. 能否提供三個客戶參考的聯絡方式？
12. 在發現重大質量問題時，你們的補救方案與時間表是？

實務限制與取捨： 寫太詳細的 RFP 會把創意鎖死且抬高報價，太模糊則會造成範圍漂移。實務上最佳作法是先用精簡 RFP 篩選 3 家進入付費 discovery sprint，該 sprint 用 2 周時間產出真正可驗收的原型，然後以成果決定長合約。

Concrete Example: 一家 B2B SaaS 要重設後台儀表板，我們在 RFP 指定必須提供 React 元件、符合公司資料隱私政策的資料流設計、以及交付一套可重用的元件庫。供應商被要求先做一個 2 週付費 discovery 並交付三個高傳真畫面與資料串接樣本，這樣可以在正式簽約前驗證技術與溝通適配度。

判斷力提示： 不要只看視覺漂亮與獎項，優先檢查能否用數據證明成果、是否能交付可維護的元件庫，以及在合約終止時你能否拿到完整原始檔與部署權限。獲獎作品往往欠缺可維護性。

下一步考量：把此檢核表做成可量化評分表，先用兩個真實專案做短名單比較，然後用 2 週付費 discovery 來檢驗溝通與技術能⼒。

5. 合約要點檢核清單：交付、驗收與智慧財產

關鍵斷言：合約爭議大多來自於交付物定義不清、驗收標準模糊與智慧財產權歧義。把這三項條款當作防火牆：明確格式、測試流程與權利範圍，才能在專案中保留修正空間而不喪失控制權。

必列的交付物與檔案格式

• 完整交付清單：列出每個里程碑應交付的具體檔案，例如 Figma 檔、標註規格、SVG 圖示、壓縮圖片、HTML/CSS/JS 原始碼、後端整合接口文件與測試資料。
• 可用於上線的交付格式：說清楚版本（例如 Figma vX、React 17、Node 14）、檔案命名規則與導出設定，避免供應商交來非生產可用的 ZIP 檔。
• 元件化與設計系統交付：如果要轉內部維運，合約應要求交付元件庫、story 文件與使用範例，而不是單純的畫面圖檔。
• 第三方資源清單：列出所有外部字體、授權圖片、icon 套件及其授權型態（商業授權或僅展示），防止日後版權問題。

驗收流程、缺陷分級與里程碑付款

具體流程：合約應定義驗收窗口（例如交付後 10 個工作日內完成驗收）、驗收清單（功能測試、跨瀏覽器檢查、可存取性基本項目）與雙方簽署的驗收紀錄。

缺陷等級	示例	修復時限 / 付款影響
重大 (P0)	功能無法使用或資料遺失	48 小時內修復；保留 20% 最終款直到驗收通過
中等 (P1)	樣式錯位、少數頁面顯示錯誤	5 個工作日內修復；保留 10% 最終款
輕微 (P2)	文案小錯、間距微調	下一個維運週期修正；無扣款或最多 2% 最終款

實務判斷：里程碑付款是必要但不足。保留款比例通常落在 5~20% 之間；高風險專案可要求 escrow 或階段性交付到第三方代管。多數創意設計公司會接受保留款，但對於 IP 完整讓渡會索價更高。

智慧財產與原始碼：轉讓、授權或限定使用

• 明確歸屬或授權範圍：不要用模糊用語。寫清楚是「著作財產權讓渡」還是「專案範圍內之永久排他授權」，以及是否包含修改權、再授權權與商業使用權。
• 原始檔交付點：指定在 X 個里程碑通過後交付，或在最終驗收後 5 個工作日內交付所有源碼與設計檔案。
• Escrow 或第三方保管：對於核心平台或關鍵前端邏輯，考慮程式碼 escrow（或使用 GitHub 私有 repo 並在合約中指定存取條件）。

限制與折衷：完全的 IP 讓渡會提高報價，因為設計公司須放棄可重複使用的模板或元件。實務上，對於模板類資產採用「專案專用永久授權」，對於客製程式碼採用原始碼交付並保留作者著作 moral rights，是更常見的折衷方案。

Concrete Example: 一家 B2B SaaS 初創將官網與管理後台的視覺與前端委外。合約列明每個頁面需交付 Figma 檔、可重用 React 元件、API mock 文件與 15% 的保留款，並在最終驗收後 7 個工作日內完成 GitHub 存取移交與設計系統文件。這讓團隊在交接時能直接在內部繼續開發，減少後續返工。

重要：在合約中把交付時間點、驗收標準與 IP 條款放在同一節陳述，避免供應商在交付格式或測試範圍上做不同解讀。

下一步要點：簽約前把這份檢核清單逐條對照供應商範本；談不攏的 IP 要求用授權期限或 escrow 作為替代，然後把最終協議送律師確認。

6. 實際談判策略與範例條款提示

關鍵前提：把不確定性貨幣化。 在談判前先量化你能承受的交付風險、時間風險與追加成本，談判的每一個點都應該回到一個金額或時間窗口上。這樣你才能在交換條件時有實際籌碼，而不是被抽象的法律條文拖延上線。

談判優先順序（先談後簽）

1. 智慧財產與原始碼： 明確是轉讓、排他授權或使用授權，規定交付時點與格式。
2. 驗收準則： 用可執行的測試清單、缺陷分級與修復時限來替換模糊字眼。
3. 付款與保留款： 里程碑+保留款（通常 10-20%）以維持廠商動機與你的保護。
4. 維運 SLA 與支援期： 回應時間、修復 SLA、包含幾個月免費 bug fix。
5. 變更與追加工作： 預先訂好時薪上限或估價流程，避免每次改動都重談價格。

務實判斷： 要求完全 IP 轉讓可以解決長期風險，但通常會提高報價 15-40% 並延長談判時間。當你不是要把設計公司變成純包商時，較有效的策略是談 永久、全球、免版稅的專屬使用授權 加上明確的交接支援，這在實務上更容易達成且成本更可控。

里程碑付款範例與談判變體

• 範例分配（實務常見）： 20% 設計啟動（簽約後）、30% 設計交付並確認、40% 功能完成上線候驗、10% 驗收後 30 天無重大缺陷才付。
• 保留款策略： 要求保留款 10-15% 並於 30 天無重大瑕疵或完成交接培訓後支付；必要時把保留款設為 escrow 機制。
• 混合付款（降低風險）： 把較高風險或核心模組改為里程碑下的 T&M 上限，其他採固定價。

Concrete Example: 一家 SaaS 初創委託設計公司做 MVP 與後台介面。談判結果：甲方支付 20% 啟動金，設計稿確認付 30%，前端上線付 40%，最後 10% 放入 escrow 並於交接文件、Figma 原檔與 Git repository 完整移交後 30 天解除。供應商同意在上線後兩週內修正重大缺陷（免費）。

範例條款提示與可接受替代方案

• 原始碼與設計檔交付： 供應商應於最終款項支付或 escrow 解除後 5 個工作日內交付全部原始碼、建置腳本、CI 配置與 Figma 檔；甲方得以永久、全球、免版稅方式使用。可選替代：改為專屬使用授權 + 90 天交接支援（成本較低）。
• 驗收測試： 驗收應以雙方同意的測試清單為準，缺陷分類為 P0/P1/P2，P0 24 小時回應、72 小時修復；未達標供應商須以每日 0.5% 合約價金作為服務信用。可選替代：罰則改為延長免費維運日數。
• 變更控制： 任一變更需以變更單作業，超過原估 15% 時須重新估價並提出時間影響表。可選替代：設置月度小額 buffer（如 20 小時/月）以快速處理小變更。

最後一點可執行的建議： 在簽約前準備好驗收腳本、明確的交接文件清單與內部負責人，這些是談判中最強的槓桿：廠商知道你能迅速驗收，會更願意接受保留款而非提高價格。閱讀我們的 WordPress 選擇指南以了解常見交付格式與驗收項目：如何挑選 WordPress 網站設計公司。

7. 專案執行與交接治理：確保外包後能順利過渡或轉內部維運

直接切入重點：交接不是一天的事，而是一套可驗證的流程。 如果你把交接留到專案末期臨時處理，結果通常是文件不全、設計系統碎片化、以及工程團隊要花數倍時間重構。把治理當作專案核心活動，能把未來維運成本降到可控範圍。

專案啟動與通訊治理

角色與責任先寫死。 在啟動會議就發布一份 RACI 或責任矩陣，明確誰負責設計系統、誰負責元件測試、誰接單維運請求。把通訊協議、問題升級路徑、每週同步節奏也列為專案合規項目，不要讓口頭約定成為日後漏洞。

• 必備啟動交付物： 需求範圍、版本控管約定、部署管道說明、驗收時間表
• 通訊規則： 主要聯絡窗口、回覆 SLA（例如工作日 24 小時內回覆）、會議頻率與議程模板
• 權限治理： Git 存取層級、Figma 檔案權限、第三方套件授權清單

知識移轉與交付物清單（可驗證）

交付物要能直接上手，不是備忘錄堆積。 要求供應商交付：完整元件庫（含設計 Tokens）、可運行的 Storybook 或實例頁、Figma 原檔與註解、前端 repo（含 README、CI 設定）、測試用例與自動化測試指引。

交付物	驗收標準 / 驗收者
Figma 元件庫 + Tokens	所有核心元件有使用指南、版本註記（產品經理驗收）
前端 Repo + CI	能在乾淨環境跑起來、部署到 staging（工程師驗收）
Storybook 或元件示例頁	互動狀態與邊界情境覆蓋 90%（QA 驗收）
操作手冊與培訓錄影	執行兩次現場教學並提供錄影（PM 與設計師共同驗收）

實際權衡： 要完整交接，需要把時間與預算納入里程碑。這會把外包成本往上推，但省下未來 3~6 個月內內部工程與設計重工的風險成本。採取局部交接策略時，先挑高頻改動區域（例如帳戶設定頁、付款流程）優先交接。

Concrete Example: 一家 B2B SaaS 在 MVP 後準備把外包視覺改為內部維運，合約要求設計公司在最後兩週內提供 3 次 90 分鐘的工作坊、交付完整 Figma tokens、以及 40 小時的交接支援。結果是內部工程師能在兩週內獨立部署小改版，原本預計需要一個月的學習成本被壓縮到半週。

中止與替代供應商接手流程

失敗要有可操作的路線圖。 合約裡應該規定中止情境下的資產交付清單與時間點，以及一套替代供應商接手程序，包括臨時維運包、短期保留款用於修復漏洞，以及存取權限與授權轉移步驟。這是常被低估但決定能否平穩過渡的關鍵。

1. 中止啟動： 觸發條件、通知窗口、初步三日回應計畫
2. 臨時維運： 30 天 SLA、每日修復優先序、臨時費率與付款條件
3. 接手交付： 全量 repo、第三方授權證明、訓練錄影與文檔

額外資源： 需要具體樣板可參考我們的專案治理範本與啟動清單，或查閱 台灣智慧財產局 了解著作權在交接時的法律處理要點。

下一步考量： 在簽約前把交接里程碑列為必過項目，並在評標時把交接能力（有無 Storybook、教學經驗、歷史接手案例）設為硬指標，不然你付了錢但拿不到能用的資產。

8. 三個常見初創情境建議與範例解法

直說結論： 初創的設計取捨不是抽象選擇，而是把有限人力與時間對準近期商業風險。下面三個情境給出可直接執行的團隊配置、短期目標與實務 guardrail，幫你快速落地而不是空談原則。

情境 A — 早期 SaaS：驗證市場配適（推薦：外包 + 內部產品負責人）

策略重點： 把速度放在第一位，保留產品方向與使用者假設的所有權在內部。委外設計公司負責快速完成 MVP 視覺與切版，內部保留一名產品或 UX 負責人做驗收與 A/B 指標監控。

• 短期 90 天目標： 上線可測量的核心流程（註冊、付費轉換）並收集量化指標
• 必備契約 guardrail： 里程碑交付 + 原始設計檔與 style guide 的階段性交付
• 工具同步： 要求 Figma 可編輯檔案與基本元件庫

限制與取捨： 外包能換速度但會降低設計沉澱。若驗證失敗，外包資產通常能快速丟棄；若成功，準備把核心 UX 角色轉內部，並計算轉換成本。

具體例子： 一家 B2B SaaS 以外包在 8 週內把訂閱流程做成可測版，上線後兩週內發現註冊漏斗掉落 40%，產品經理用數據快速提出三項改版假設，下一階段改由內部設計師負責優化。

情境 B — 已有穩定付費客戶：快速迭代與穩定維運（推薦：小型內製 + 視覺與切版外包）

策略重點： 把核心交互與產品設計留在內部，外包處理高週期、可規模化的視覺資產與著陸頁實作。內部團隊應包含一名產品設計師與一名設計系統或前端工程師做版本管理。

• 短期 90 天目標： 建立一套可重複使用的設計元件庫與交付流程
• 衡量指標： 平均交付週期、A/B 測試成功率、每月回歸缺陷數
• 實務建議： 對外包設定模板與檔案規範，減少來回與合併成本

限制與取捨： 內製能降低溝通成本但人事成本增加。這種模式適合能承擔基礎設計薪資的公司，但仍需把大量短期任務委外以避免設計師被瑣事消耗。

具體例子： 一家訂閱電商建立了內部設計師與前端工程師，同時把每月促銷頁面交給視覺設計公司，結果促銷交付週期從 10 天降到 4 天，內部人力專注於轉換率優化與設計系統擴充。

情境 C — 設計或資料敏感為核心競爭力：以內製為主，外包需嚴格受限

策略重點： 當產品介面、資料處理或專利構成商業壁壘時，內製是必要條件。外包僅限於非核心、可隔離的工作，且要有嚴格 NDA、最小權限與交付保證。

• 短期 90 天目標： 建構不可外包的設計核心與內部知識庫
• 合規要點： 設計師招聘要有資安背景或簽署技術保密條款，第三方僅能接觸模組化接口
• 切換策略： 為未來可能的外包限縮建立測試沙盒與模擬資料

限制與取捨： 完全內製成本高且招募難。很多團隊在這一路徑卡住不是技術問題而是招募與文化配適，必要時把非核心工作外包給受信任夥伴并分階段放大信任。

情境	推薦模式	90 天重點	主要風險
A 早期驗證	外包 + 內部 PM/UX	MVP 可量化流程上線	設計資產難沉澱
B 穩定付費客戶	小型內製 + 外包視覺	元件庫與交付標準化	人事成本與知識孤島
C 設計或資料為核心	以內製為主，受限外包	建立內部設計核心與合規	招募難度與短期成本高

關鍵判斷： 如果你的商業風險在於市場不接受產品，用外包換速度；如果風險是競爭者抄襲你的使用經驗或資料價值，投資內製。

9. 可下載的工具與範本（在文中提供連結）

直接可用的套件比單純建議更有用。 我把常用的三個檔案打包成可下載範本：決策打分表（ .xlsx / Google Sheets）、RFP + 供應商評分表（ .docx / Google Docs）與合約檢核清單（ .pdf）。這些範本設計為可立即套用但也容易修改，下載與說明請見我們的資源頁面與範例文章： 網站設計公司推薦：針對初創公司的 8 類型 以及 頂級網頁設計公司如何幫助您的業務線上轉型。

如何在實務中使用這些範本

1. 先跑一次快速版本： 把決策打分表套到你目前的三個候選設計公司，別糾結精確分數，重點是看排名是否穩定。
2. 用 RFP 把範圍鎖住： 對外發 RFP 時把驗收標準和交付格式寫清楚，能把價格比較變成可比較的數據。
3. 合約檢核清單只做決策把關： 在談判前用檢核清單標出你的紅線（IP、原始碼交付、保固期），把這些點當作優先談判項目。

實務範例： 一家早期 B2B SaaS 用決策打分表比對三家設計公司，最終選擇不是最低價者，而是那家在可交付元件庫與前端支援得分最高的公司。使用 RFP 將交付物標準化後，第二輪報價差距縮小，談判時能直接把保固時數列為里程碑付款條件。

重要限制與取捨： 範本能節省時間但不是萬靈丹。決策打分表會對權重敏感 — 如果你把速度權重設太高，會系統性偏好一種供應商；如果把 IP 權重設太高，可能把合適的創意設計公司排除。模板的正確使用需要你事先明確商業優先順序。

下載後的第一件事：在範本上做兩次敏感度測試（高/低速度權重），看排名是否穩定；不穩定就回頭調整你的商業優先順序。

關於法律與在地化： 合約檢核清單含常見條款範例與談判提示，但它不是法律意見。在台灣簽約前把重點條款交給律師檢視，並參考 台灣智慧財產局 以確認著作權與授權細節。

額外附件（可在下載包調整）： 包含 Figma 交接檢核（元件命名、變數、切圖設定）、標準里程碑時間表範本與簡易 SLA 範例。這些小檔案會在交接時節省大量溝通成本，特別是當你打算未來把工作轉內部時。

下一步（實用指示）： 下載範本，先用一個真實候選供應商跑一遍流程（打分、RFP 回覆比對、合約檢核），把發現記錄回到範本裡再做第二輪決策。