UI/UX 設計接案怎麼入門？作品準備、報價區間與交付流程的實務拆解

你接到一則訊息：「我們 App 想改版，可以幫我們做 UI 嗎？大概要多少錢？」對方沒有給你頁面清單、沒有給你現有版本的使用數據、也沒說要不要含切圖。這時候你回一個數字，之後兩個月會發生什麼事，大概已經決定了。

UI/UX 接案在台灣有一個結構性的麻煩：這個職稱在官方統計裡根本不存在。勞動部的職類別薪資調查裡沒有「UI 設計師」也沒有「UX 設計師」，最接近的職類叫「平面及多媒體設計師」；而且那份調查的受僱員工定義裡，明文把自營作業者排除在外。所以你在網路上看到的那些「台灣 UI/UX 接案行情大約多少」，幾乎沒有一個說得出母體。這篇文章不會給你一個編出來的數字，會給你的是自己算出報價的方法，以及那些數字背後真正該談清楚的東西。

整篇會處理八件事：客戶說的「做 UI」在台灣實際上包含什麼、沒有真實案子時作品集怎麼準備、四種報價模型各自會在哪裡失控、需求訪談要問哪九個問題、五類交付物與「交付到哪裡算完」、改稿輪次在設計案的特殊定義、Figma 檔案的所有權與交接（含著作權法第 12 條與 Figma 官方的五條交接路徑）、以及跟工程端的責任分界。所有價格與功能限制都附上官方頁面與查核日。

客戶說的「做 UI」，在台灣接案現場通常包含什麼

教科書會告訴你 UI 是介面的視覺與互動、UX 是整體體驗的研究與流程設計。這個定義沒有錯，但它幫不上你報價。因為在台灣的中小型案子裡，客戶說「做 UI」的時候，他心裡想的是一個從無到有、直到工程師能開工為止的完整區間，中間有多少工作他不知道，也不覺得需要知道。

先講一個常被誤解的前提：這不是客戶惡意。多數中小企業主與行銷窗口沒有跟設計師合作過完整的產品週期，他們的參照點是「找人畫個圖」。你的工作不是糾正他的用詞，是在報價前把區間切開，讓他看見自己買的是哪幾段。

把「做 UI」拆成六段，客戶通常以為只有第五段

以一個中小型 App 或 SaaS 改版案為例，從接到需求到工程師能開工，實際會發生的工作依序是這六段。

1. 需求與限制的釐清：這個改版要解決什麼問題、成功的標準是什麼、有哪些不能動的東西（既有品牌規範、後端資料結構、法規欄位）。
2. 資訊架構與流程：有哪些頁面、頁面之間怎麼走、每一條路徑的分支與失敗狀態。這一段的產出通常是流程圖與頁面清單，不是漂亮的畫面。
3. 低保真結構：線框階段。決定每個畫面上放什麼、優先順序如何、哪些資訊要收在第二層。
4. 視覺語言的建立：色彩、字級階層、間距系統、元件樣式。這一段做完，後面每一頁的速度會差三倍以上。
5. 高保真畫面：客戶想像中的「UI」就是這一段。
6. 交付與工程協作：切圖、標註、狀態補齊、Dev Mode 或標註工具的整理、開發期間的問答與微調。

客戶報價時想的是第五段，付錢時願意付的通常是第四到第六段，而讓案子準時交付的關鍵是第一到第三段。這個錯位就是 UI/UX 接案最主要的虧損來源。

「做 UI」與「做 UX」在台灣案子裡的實際切分

依案子規模，市場上大致有三種切法，你要先判斷客戶屬於哪一種，再決定報價要涵蓋幾段。

• 全包型（最常見）：客戶只找一個人，從第一段做到第六段。這種案子的名稱通常寫「網站／App 設計」，客戶心裡沒有 UI 與 UX 的分別。優點是你有完整控制權，風險是前三段的工時完全沒被計入報價。
• 視覺外包型：客戶內部已有 PM 或產品負責人做完前三段，給你線框或頁面清單，請你做第四到第六段。這種案子的名稱常寫「UI 視覺」「介面美化」。它的報價可以比較準，但風險在於客戶給的線框品質決定你的返工次數，而線框品質在報價階段看不出來。
• 研究與流程顧問型：客戶要的是第一到第三段，最後交流程與線框，視覺另外找人或由內部團隊做。這種案子在台灣中小企業比例低，多半出現在有產品團隊的公司。

三種切法對應到三種完全不同的失敗模式。全包型會敗在範圍無邊界，視覺外包型會敗在上游品質不受你控制，顧問型會敗在成果難以驗收（因為交付物是判斷與文件，不是畫面）。報價的第一個動作，是先把案子歸類。

一個判斷你是不是「被當成免費 UX」的檢查

有一個很實用的訊號：客戶給你的資訊，是「答案」還是「問題」。

如果對方說「我要一個報名頁，欄位是這五個，送出後跳感謝頁」，那是答案，你在做第四到第六段。如果對方說「我們報名轉換率很低，想改一下」，那是問題——決定要放哪五個欄位、要不要分兩步、送出後導向哪裡，這些判斷全部要你做，而這是第一到第三段的工作。

兩種情境的工時可以差三倍，但客戶開口的方式一模一樣。所以需求訪談不是禮貌流程，是報價的必要前置。這一點跟通用的接案訪談有共通處，客戶提案簡報與需求訪談的四組問題那篇有一套通用的訪談骨架，本篇後面會補上 UI/UX 案子特有的那幾題。

報價之前先認清：台灣有 UI/UX 薪資調查，但沒有接案報價統計

這一章可能是全篇最重要的一章，因為它決定你要不要相信網路上看到的數字。

官方統計裡查得到什麼、查不到什麼

先講查得到的。勞動部《職類別薪資調查報告》（資料時期民國 114 年 7 月，115 年 6 月編印）裡，設計相關職類有三個：平面及多媒體設計師（受僱員工 23,143 人，每人每月經常性薪資 45,413 元，113 年全年薪資所得 61.2 萬元）、室內設計師（7,961 人，50,555 元）、產品及服裝設計師（含工業設計）（19,388 人，56,669 元）。對照組是專業人員合計 1,120,407 人、67,806 元。

再講查不到的，而這一段才是重點。該報告全文檢索「網頁」「UI」「UX」「視覺傳達」，命中數都是零。也就是說，官方統計裡沒有「UI/UX 設計師」這個職類，最接近的是「平面及多媒體設計師」，兩者的工作內容差距不小。

更關鍵的是母體定義。該調查的對象是「從事工業及服務業（不含公共行政業）之事業場所單位」，母體檔約 86 萬家有僱用員工的事業單位，總樣本約 1 萬家；而受僱員工的定義逐字寫著「不包括參加作業而不支領薪資之雇主、自營作業者及無酬家屬工作者」。接案者在定義上就不在樣本裡。

還有一層量綱問題：經常性薪資是「該月全月工作報酬」，包含本薪與按月給付的固定津貼獎金。它是月薪，不是案件報價。一個月薪 45,413 元的受僱設計師，跟一個接案設計師的每小時成本，中間隔著勞健保雇主負擔、辦公空間、軟體授權、沒有案子的空窗期、以及你自己承擔的收款風險。把月薪除以 176 小時當成你的時薪，是接案第一年最常見的自殺方式。

求職平台的數字是受僱月薪，而且母體要看清楚

104 薪資情報有「UI 設計師」與「UX 設計師」兩個獨立頁面，這是目前台灣少數把兩者分開的公開資料。查核日當天頁面標示：UX 設計師有效樣本 97 筆、UI 設計師有效樣本 259 筆，資料更新日 2026 年 7 月 27 日。頁面會依年資顯示月均薪與 P25／P50／P75 三個分位。

但要注意兩件事。第一，104 這兩個頁面上沒有任何方法論說明——沒寫樣本是來自求職者填的履歷薪資、還是企業開出的職缺薪資，也沒寫統計期間。第二，樣本數不大，UX 那一頁的「1 年以下」與「10 年以上」都直接顯示樣本不足。所以引用它時，能講的只有「該頁面標示了什麼」，不能宣稱它代表市場。

1111 的薪資公秤有「UI/UX 設計師」這個合併職務，並且自己揭露了方法論，這一點比 104 誠實。頁面逐字寫著資料來源是「1111 人力銀行會員履歷資料庫」，「根據會員履歷工作待遇欄位資料採用月薪類型計算平均薪資，但獎金及其他收入則不列入其中」，有效樣本 714,505 筆、信心水準 95%、誤差正負 3 個百分點。但這 71 萬筆是全站所有職務的總樣本，不是 UI/UX 這一個職務的樣本數。而且資料來源區間是 2021 年 1 月到 2024 年 12 月，到現在已經落後一年半以上。頁面自己也寫了一句警語：「自發性回應樣本，會可能產生系統的偏向於母體中的某一部份」。

唯一台灣本地的 UI/UX 專屬調查：有樣本數，但問的不是報價

比前面兩個求職平台更接近的，是台灣使用者經驗設計協會（UXTW）做的《台灣使用者經驗設計產業與工作者調查報告》，自 2015 年起共出過 2015–2018、2020–2023 八個年度（2019 年缺）。以查核日能取得的最新一版（2023 年版）為例，全份標明總樣本 n=346，每一張圖也各自標了該題的 n，並註明「樣本數少於 10 人之職稱未製圖」。就「這個數字是幾個人回答的」這一點而言，它比 104（頁面完全沒有方法論）和 1111（只給全站總樣本，不給該職務的樣本數）都具體，而且它是查核時找得到、唯一針對 UI/UX 這個族群本身而且逐項標註樣本數的台灣公開調查。

但它一樣回答不了報價問題，原因有三個。第一，它問的是年薪：報告寫台灣 UX 工作者（不含海外）年薪平均 97 萬、中位數 75 萬，全份沒有任何報價、時薪或專案價的欄位。第二，樣本壓倒性地是受僱者：職稱分佈裡「自由工作者」只有 2 人（1%），連把設計顧問公司與個人自由工作者合併起來的「乙方」那一組也只有 n=66。第三，它是自願填答的自選樣本，跟 1111 那句警語踩的是同一個坑。

還有一件取得性上的事要講清楚：查核日當天，協會官網 uxtw.org 這個網域查不到 A 紀錄、連不上，報告本體目前只能從協會放在雲端硬碟的檔案取得（連結列於文末）。所以正確的說法不是「台灣沒有 UI/UX 的調查」，而是——有從業者的薪資調查，沒有接案者的報價調查。這兩句話的差別，就是這一章存在的理由。

國際平台的數字：母體是全球，不是台灣

Upwork 的 UX designer 費率頁寫「UX Designers on Upwork cost $25–$39/hr」，UI designer 頁寫「UI Designers on Upwork cost $20–$40/hr」，標籤是「Median hourly rates (USD)」。看起來很具體，但同一頁的星號註解逐字說明了母體：「This data represents typical hourly rate ranges of certain historical contracts worldwide.」——全球、部分歷史合約，Upwork 沒有揭露樣本數、期間與篩選規則。（附帶一提：Upwork 這兩個頁面會擋自動化存取，本文的引文核對自 2025 年 12 月的網站封存版本，數字可能已與現行頁面不同——這正好又證明了一次，連要「查證一個行情數字」本身都不容易。）

Fiverr 的成本指南（頁面標示 2026 年 4 月 23 日）寫「professional UI UX design services range from $150 to $717 per project, with hourly rates between $20 and $125 based on marketplace insights」，並在「Average UI UX Designer Costs」段標注來源為 Fiverr 自家的近期平台資料，細分成網站 UI/UX（固定價 $103–$327）、App 設計（$185–$717）、到達頁設計（$103–$121）等等。這是平台賣家自訂價格的觀察，同樣沒有樣本數與統計方法。

這些數字有它的用處：如果你打算接國際案，它們是你在那個平台上會被拿來比較的價格帶。但它們不能換算成台灣行情，因為幣別、客戶對交付物的期待、以及平台抽成完全不同。要走國際平台這條路，先把抽成算進去，四大接案平台的官方費率與提領條款那篇有逐項的抽成比較。

連美國都是 2026 年才第一次做這件事

值得知道的一個背景：Fast Company 與 AIGA 在 2026 年做了 The Design Pricing Transparency Project，公開的說明寫著他們花六週調查了近 1,300 位自由設計師與 150 位招募方。這是設計圈第一次規模化地公開費率。換句話說，費率資訊不透明不是台灣獨有的問題，是這個產業的通病。（該報告的費率數字位於付費牆之後，本文不引用任何金額。）

另一份可查的是 User Interviews 與 Levels.fyi 的 2026 UX Salary Report，其中 UX freelancer 的全球年收入中位數為 US$90,000（n=293），美國為 US$125,000（n=166），美國以外為 US$39,000（n=127）。注意這是年收入不是報價費率，樣本也是自願回報，且沒有台灣的單獨切分。美國與非美國之間三倍多的落差，本身就說明了「不能用單一國際數字推台灣」。

結論：你要建立的是算法，不是行情表

把上面整理成一句可以直接用的話：台灣查得到 UI/UX 從業者的薪資調查，查不到 UI/UX 接案報價的權威統計。 前者（勞動部、104、1111、UXTW）的母體是受僱員工或從業者、量綱是月薪或年薪；後者到查核日為止，沒有任何具備母體定義與樣本數的公開資料。請把這兩件事分清楚——這不是「我查不到所以略過」，是把上面每一個來源打開來讀完母體說明之後，確認那個東西沒有。你看到的每一個「行情大約 X 萬」，如果沒有附上母體，它就是某個人的個人經驗被包裝成通則。下一章講的就是替代方案：自己算。

四種報價模型：適用情境與各自的失控風險

定價模型的通則（成本加成、價值定價、套餐化那一套）在五種定價模型的整理那篇談過，這裡只講 UI/UX 案子特有的四種計價單位，以及每一種在設計案上會從哪裡崩掉。

先算出你自己的底價時薪（這一步不能跳）

四種模型最後都要回到同一個地基：你一小時的成本是多少。算式只有三行，把你自己的數字填進去。

1. 年度需開票金額 ＝ 你想拿到的年度稅後收入 ＋ 應繳稅費 ＋ 年度固定成本（勞健保或職業工會保費、設備攤提、軟體年費、辦公或共享空間、進修、保險、會計費用）。
2. 年度可計費工時 ＝ 一年實際工作週數 × 每週工作時數 × 可計費比例。可計費比例是關鍵：找案、報價、行政、對帳、進修、社群經營都不能計費。全職接案者的可計費比例落在什麼區間因人而異，但它絕對不是 100%，先用你自己上一季的工時紀錄算出真實值。
3. 底價時薪 ＝ 年度需開票金額 ÷ 年度可計費工時。

舉一個純粹用來示範算式的例子（這些數字請一律換成你自己的，它們不代表任何行情）：假設某人的年度需開票金額填 120 萬，一年工作 46 週、每週 40 小時、可計費比例 55%，那麼可計費工時是 46 × 40 × 0.55 ＝ 1,012 小時，底價時薪是 1,200,000 ÷ 1,012 ≒ 1,186 元。這個數字是你不能低於的成本線，不是你的報價；報價還要再乘上風險係數與價值溢價。

可計費比例這一項多數人都高估了，而它對結果的影響最大：同樣的年度目標，可計費比例從 55% 掉到 40%，底價時薪會直接從 1,186 元跳到 1,630 元。要拿到真實的可計費比例，唯一的辦法是記錄，工時追蹤與計費的完整流程那篇有可以直接沿用的分類方式。

模型一：按頁數（畫面數）計價

怎麼算：先數畫面，一個畫面一個單價，再依複雜度分級（例如靜態內容頁、含表單頁、含資料清單與篩選的頁）。

適用：形象官網、活動到達頁、規格明確的內容型網站。這類案子的畫面數在報價階段就能數清楚，而且畫面之間的邏輯簡單。

失控風險：「一頁」在響應式與狀態上的定義完全沒有共識。 一個商品清單頁，桌機版、平板版、手機版算一頁還是三頁？空清單、載入中、搜尋無結果、網路錯誤這四個狀態算不算頁？點開篩選面板算不算新的一頁？如果報價單沒定義，客戶會用最省錢的算法，你會用最耗工的做法，兩邊都覺得對方在鑽漏洞。

怎麼防：在報價單裡把「一頁」定義成三件事的組合——一個網址、一組響應式斷點、以及列舉出來的狀態數。超過列舉狀態數的另外計價。斷點數要寫死（例如「含桌機與手機兩個斷點，平板沿用桌機規則」）。

模型二：按功能（元件／流程）計價

怎麼算：以功能單元報價，例如「登入註冊流程」「購物車與結帳流程」「後台訂單管理」各一個價，不管它展開成幾個畫面。

適用：App 與 SaaS，因為這類產品的畫面是流程的副產品，數畫面沒有意義（同一個流程可能因為設計決策而變成三頁或一頁）。

失控風險：功能的邊界比頁數更模糊。「結帳流程」包不包含優惠券？包不包含超商取貨的門市選擇？包不包含結帳失敗後的重試？每一個「包不包含」都是好幾個畫面加上一組狀態。這個模型的另一個風險是客戶會在中途說「這本來就是結帳的一部分吧」，而你很難反駁，因為功能名稱本來就是模糊的。

怎麼防：每個功能單元下面列出使用者故事清單（例如「使用者可以套用一張優惠券」「使用者在庫存不足時看到替代建議」），報價針對這份清單，不針對功能名稱。清單以外的故事就是新增項目。這比爭論「這算不算結帳的一部分」有效得多。

模型三：按時薪計價

怎麼算：底價時薪 × 實際工時，通常搭配一個工時上限或分階段的預估區間。

適用：三種情境。一是需求真的還沒定型的探索期；二是既有產品的持續優化（沒有明確終點的長期合作）；三是你完全沒做過的案型，估不準工時的時候。

失控風險：你的效率愈高，收入愈低。 這是時薪制的結構性問題——你花五年練出來的判斷力，讓你三十分鐘做完別人三小時的事，然後你只能收三十分鐘的錢。第二個風險是客戶會開始盯工時明細並質疑每一項，把合作關係變成監工關係。第三個風險最實際：客戶對「總價會是多少」沒有安全感，很多台灣中小企業客戶直接不接受這種計價。

怎麼防：報價時給區間與上限，並寫明「達到上限前會先書面通知」。工時紀錄以工作項目為單位彙整（例如「結帳流程線框與三輪修正：14 小時」），不要交出逐分鐘的原始紀錄。如果你的效率明顯高於市場，這個模型長期而言不利於你，應該逐步轉向專案制。

模型四：專案制（總包價）

怎麼算：整個案子一個總價，內部用工時估算加風險係數推導出來，但對外只呈現總價與分期付款節點。

適用：範圍能凍結、你做過類似案型、而且客戶方的決策鏈單純。這是多數成熟接案者的預設模型。

失控風險：風險全部轉移到你身上。 估錯就是你吃下去。而且專案制最容易發生的不是估錯工時，是估錯「客戶的決策速度」——同一份設計，一個窗口拍板跟五個主管輪流看，工時可以差一倍以上，但這個變數不在你的估算表裡。

怎麼防：三件事。第一，在合約裡寫單一窗口與有權指示的人；第二，寫明客戶方的配合義務與逾期規則（素材未提供、回饋逾期，時程順延且逾期部分不計入你的責任）；第三，估算時把「客戶端來回的等待與重工」當成獨立一項加進去，不要藏在設計工時裡。要判斷這個客戶的決策鏈會不會失控，開案前的六個警訊與篩選問題那篇的檢查可以在報價前跑一次。

四種模型速查表

模型	最適合的案型	最容易失控的地方	報價單裡一定要寫死的東西
按頁數	形象官網、到達頁、內容型網站	「一頁」的定義（斷點數、狀態數）	網址數 × 斷點數 × 列舉的狀態清單
按功能	App、SaaS、後台系統	功能邊界（「這本來就該包含吧」）	每個功能單元底下的使用者故事清單
按時薪	探索期、長期優化、沒做過的案型	效率愈高收入愈低；客戶盯工時	工時區間與上限、超出前的通知義務
專案制	範圍可凍結、做過的案型	客戶決策速度（不是設計工時）	單一窗口、客戶配合義務、逾期順延規則

實務上最穩的組合是混合制：探索期（第一到第三段）按時薪或用一個獨立的小額專案收費，範圍凍結後的執行期（第四到第六段）改成專案制。這樣你不用在資訊最少的時候承擔最大的估算風險，客戶也不用在還沒看到方向時就簽下一個大數字。報價單的欄位結構怎麼安排、代墊費用與著作權條款怎麼寫，網頁設計報價單的十二個欄位那篇有完整的範本，這裡不重複。

沒有實案的時候，作品集怎麼準備

這是入門者最卡的一關，也是最容易做錯的一關。先把三個做法攤開來看，包括它們各自的爭議。

爭議最大的做法：重做既有的知名 App

「某某銀行 App 改版概念」「某某外送平台重新設計」，這類作品在設計社群非常多。它受歡迎是有原因的——題目自帶脈絡，觀眾不用花力氣理解你在解決什麼問題。但它有三層問題，而且大多數人只看到第一層。

第一層是法律。 你重繪的是別人的商標、產品名稱與品牌識別。單純的個人練習與非商業展示，通常不會有人來找你；但一旦你把它放在以承接業務為目的的作品集網站上，性質就開始滑動。最低限度的自保是：不要使用對方的商標作為你的作品標題視覺、在頁面上明確標示「未受委託的個人概念練習，與該公司無關」、不要暗示曾有合作關係。

還有一條平台層面的硬規定常被漏掉。Dribbble 的社群指南逐字寫著：「Do not share work that contains copyrighted or trademarked content.」這跟「概念稿要不要標示」是兩個不同的問題——後者沒有規定，前者有。 把帶著對方 logo、品牌色與產品名稱的改版稿貼上 Dribbble，違反的是這一條，跟你有沒有寫「未受委託」無關。Behance 的社群指南也寫了「Broadcasting or uploading other people’s work as your own is copyright infringement and is not tolerated.」，並要求你不確定商標使用是否合法時自行確認。實務上的解法很簡單：要公開展示，就把可辨識的商標與品牌識別換成虛構的，只保留你真正想展示的資訊架構與介面決策。

第二層是專業判斷，而這一層才是真正會扣分的。 你看到的那個「明明可以更好」的介面，背後可能有你看不到的約束：法規要求的欄位順序、資安考量下刻意的多一步驟、與舊系統的資料結構相容、A/B 測試後留下來的版本、或是某個高流量族群的使用習慣。一份沒有提到任何約束的改版概念，在有經驗的招募方或客戶眼中，讀起來是「這個人不知道真實產品有約束」。

第三層是它證明不了你最值錢的能力。 接案最難的部分不是畫得好看，是在資訊不足、預算有限、客戶意見分歧的情況下做出可執行的決定。重做既有 App 完全繞過了這一段——你沒有客戶、沒有預算限制、沒有工程可行性的約束、也沒有人在第三輪推翻方向。

那能不能做？可以，但要把它變成有約束的題目。具體做法是：自己先寫下一組虛擬但合理的約束（「不改後端資料結構」「不新增頁面，只能在既有三頁內解決」「開發預算只有兩人週」），然後在案例頁裡先呈現這組約束，再呈現你的設計。這樣觀眾看到的不是「我覺得這樣比較美」，是「在這些條件下我怎麼取捨」。

虛構專案要怎麼標示才不算灌水

先講一件很多人以為有、但其實沒有的事：Behance 與 Dribbble 的官方社群規範裡，都沒有任何要求你標示「概念稿」與「真實客戶案」的條文。

我逐條讀過兩邊的規範。Behance 的社群指南在「Be Authentic」一節寫的是「Using fake, misleading, or inaccurate information in your profile」「Impersonating other people or entities」「Falsely attributing someone’s work」；Dribbble 的指南寫的是「Only share work that you have permission to share」「Do not post work created by other designers」「Don’t take credit for others’ work」。這些條文管的是作品是誰做的，也就是歸屬問題；而「這是概念稿還是真實委託」是委託脈絡問題，是另一個維度。Behance 那句「fake, misleading, or inaccurate information」在原文裡明確限定在 in your profile（個人檔案內），不能擴張解釋到作品內容。（兩邊唯一帶有揭露義務語氣的條文是關於 AI：Dribbble 寫「When creating content with AI assistance, it is recommended to acknowledge the contribution of AI in your Shot description」，用的是 recommended，不是規定。）要注意這裡談的只有「標示概念稿」這一件事——兩邊對於作品裡能不能出現別人的商標都另有明文規定，那一段在上一節已經講過，不要把「不用標概念稿」誤讀成「什麼都能貼」。

所以標示概念稿的理由，不是平台規定，是客戶與招募方的期待，以及一個更現實的理由：不標，你會在第一次視訊時被拆穿。當對方問「這個案子當時客戶的預算是多少」「這個決定客戶怎麼反應」，你只有兩條路——承認它是概念稿（比一開始就標更尷尬），或是繼續編（然後被下一個問題問倒）。

可以直接照抄的標示方式是在案例頁最上方放一行狀態標籤，用三選一：

• 「委託案｜客戶：某某公司（已獲授權公開）」——真實客戶案，而且你確認過可以公開。
• 「委託案｜客戶名稱依保密協定不公開」——真實客戶案但簽了保密條款。這種情況下不要放可辨識的品牌元素，用替換過的色彩與名稱重製畫面，並在頁面上說明「以下畫面已依保密要求重製」。
• 「個人概念專案｜未受委託」——虛構或自主發起的專案。同一行後面接一句約束說明會更好：「設定的約束：不改動後端資料結構、開發預算兩人週」。

團隊作品還要多一層。Behance 的 Credits 功能只是把協作者顯示在專案資訊裡，沒有欄位讓你註明「你在團隊中負責哪一部分」，所以那句話要你自己寫在案例內文：具體到「我負責結帳流程的線框與高保真畫面，視覺語言由團隊的設計主管建立，使用者訪談由 PM 執行、我參與整理」。寫得愈具體，可信度愈高；含糊的「參與了某某專案」反而讓人懷疑你什麼都沒做。

三種比「重做知名 App」更值錢的替代品

如果你的目標是接到案子（而不是累積社群按讚），下面三種的轉換率明顯更高，因為它們都有真實的約束與真實的對話對象。

第一種：小型組織的真實案子。 在地店家、社團、非營利組織、學校社團、朋友的側業。可以低價或免費，但一定要跑完整的流程——簽一份簡單的協議（哪怕只有一頁）、做需求訪談、給報價（哪怕金額很低）、走改稿輪次、正式交付。整個過程的價值不在那份設計稿，在於你之後可以誠實地寫「這是一個真實委託案」，而且你會親身遇到所有難處。免費做的時候，合約反而更重要，因為沒有錢當籌碼時，範圍最容易失控——哪怕只有一頁，也要寫清楚交付物、輪次與截止日。

第二種：自己的產品。 一個真的上線、真的有人用的小工具、小網站或小 App。它勝過所有概念稿的地方在於你有數據：多少人來、多少人卡在哪一步、你改了什麼、數字怎麼變。案例頁裡能寫出「改版後某個步驟的完成率變化」，這件事概念稿永遠做不到。

第三種：既有作品的深度重寫。 如果你已經有三五件作品但都只有幾張圖，與其再做第四件，不如把現有的其中一件寫成完整案例。多數入門作品集的問題不是件數不夠，是每一件都只有結果沒有過程。

UI/UX 案例頁該有的六個區塊

作品集網站本身怎麼架、要放哪些頁面、SEO 怎麼處理，作品集網站的實作那篇談得比較完整。這裡只講 UI/UX 案例頁內容本身的結構，這六塊缺哪一塊，客戶就少一個下單的理由。

1. 狀態標籤與角色：委託案還是概念案、你負責哪幾段（用本文第一章的六段來寫最清楚）、專案期間多長。
2. 問題與約束：客戶原本遇到什麼問題，以及有哪些不能動的東西。約束比問題更能證明你的專業。
3. 你排除掉的選項：這一塊 90% 的作品集沒有，但它是最有說服力的一塊。寫「我們考慮過把註冊拆成三步，但因為既有的簡訊驗證成本，最後選擇單頁加即時驗證」，比放十張漂亮的畫面有用。
4. 關鍵畫面（不是全部畫面）：挑三到五張能講出決策的畫面，每張配一句「這裡為什麼這樣做」。放三十張畫面只會讓人滑過去。
5. 交付與協作：你交了什麼（設計稿、原型、切圖、標註、設計系統）、工程端怎麼接手、上線後有沒有回頭調整。這一塊直接對應客戶心裡的「這個人交出來的東西工程師能不能用」。
6. 結果或誠實的替代：有數據就放數據；沒有數據就誠實寫「本案上線後未取得後續數據」，然後改放客戶的一句回饋、或是你自己的復盤（「如果重來我會先做的一件事」）。編一個假的轉換率提升數字，是這個產業最容易被抓包的謊。

需求訪談：UI/UX 案子特有的九個問題

通用的訪談骨架（為什麼是現在、誰說了算、成功長什麼樣、不做什麼）在需求確認防呆流程那篇有完整版。下面九題是設計案專屬的，每一題後面標了「答案會影響你報價的哪一項」——訪談不是為了理解客戶，是為了讓報價可以算。

關於範圍的三題

1.「這次要做的畫面，有沒有一份清單？沒有的話，你能列出使用者會走的三條主要路徑嗎？」——影響：畫面數，也就是報價的基數。客戶列不出來，代表這案子的第二段（資訊架構）還沒做，那一段必須算進報價。

2.「要支援哪些裝置與斷點？平板要單獨設計還是沿用桌機規則？」——影響：畫面數的乘數。這一題不問，你會在交付前一週被要求補一整套平板版。

3.「除了正常狀態，有哪些狀態需要設計？空資料、載入中、錯誤、無權限、搜尋無結果、超長文字。」——影響：實際工時。狀態設計佔一個複雜介面的工時比例很高，卻幾乎不會出現在客戶的想像裡。問這一題的附加效果是你會立刻顯得專業，因為多數客戶沒被問過。

關於上游條件的三題

4.「有沒有既有的品牌規範或設計系統？如果有，能不能先給我看？」——影響：第四段（視覺語言）要不要做。有規範且品質好，這一段可以大幅壓縮；有規範但殘破（常見情況是一份三年前的 PDF，跟現行產品完全對不上），那反而更花時間，因為你要先做考古，再說服客戶哪些該廢掉。

5.「現在的產品有數據嗎？哪一步流失最多人？」——影響：這案子是「有問題要解決」還是「想換個樣子」。有數據的案子好做很多，因為驗收標準可以綁在數據上而不是「好不好看」。沒有數據就要在報價前講清楚：沒有數據就沒有客觀驗收標準，驗收會回到主觀判斷。

6.「內容（文案、圖片、商品資料）誰提供？什麼時候能給我？」——影響：時程風險，而這是設計案延期的頭號原因。客戶說「你先用假字，之後我們再放」的案子，最後幾乎都會在上線前一週因為真實內容爆版而重排一輪。把「內容提供期限」寫進合約的配合義務，逾期則時程順延。

關於下游與驗收的三題

7.「工程端是誰？用什麼技術？有沒有既有的元件庫？」——影響：交付格式與後續協作成本。對方用現成的元件框架，你的設計就該對齊它的元件規格，否則工程端每一頁都要客製，落差與返工全部回到你身上。這一題如果客戶答不出來，請他把工程負責人拉進來聊十五分鐘，這十五分鐘可以省下之後十小時。

8.「設計要交到什麼程度？工程需要切圖嗎？需要標註文件嗎？誰負責標註？」——影響：第六段的工時，也是最常被漏報的一段。詳見下一章。

9.「這次改版有沒有無障礙或法規上的要求？」——影響：色彩對比、鍵盤操作、表單標籤、焦點順序這些會反過來限制視覺方案。政府與教育相關的案子多半有明確要求，一般商業案則常常在最後才冒出來。要先估這一塊的工作量，可以參考網站無障礙設計的 WCAG 重點那篇。

訪談完的動作跟其他案型一樣：寄一封「我聽到的是這樣」的信，把九題的答案寫成條列請對方確認。這封信在之後所有爭議裡都是你最有力的證據。

交付物清單：五類產出與「交付到哪裡算完」

設計案最常見的收尾糾紛不是品質，是雙方對「做完」的定義不同。客戶以為交了畫面就結束，你以為交了畫面就結束，但工程師開工後發現少了東西，客戶回頭找你，這時候你才發現合約沒寫。

五類交付物，以及各自的計數單位

報價單上不要只寫「設計稿」三個字。把五類分開列，每一類寫清楚計數單位與數量。

• 設計稿（高保真畫面）：計數單位是「畫面 × 斷點 × 狀態」。這是報價的主體，也是唯一客戶心裡本來就有的一項。
• 原型（可點擊的流程串接）：計數單位是「流程條數」，不是畫面數。一條流程從入口串到結束（含至少一條失敗路徑）算一條。要不要做失敗路徑的原型，價差不小，一定要問清楚。
• 切圖（匯出的圖片資源）：計數單位是「資源數 × 格式 × 倍率」。這一項現在最容易估錯，因為多數專案已經改用向量圖示與程式繪製，真正需要匯出的只剩實拍照片與複雜插畫。先問工程端要什麼，不要憑習慣報。
• 標註（尺寸、間距、色值、字級的說明）：計數單位是「畫面數」，但重點在於誰做。如果工程端會自己用 Dev Mode 或標註工具讀取，你只需要把圖層整理乾淨；如果客戶要一份可以離線看的標註文件，那是額外的工時。
• 設計系統（可重複使用的樣式與元件）：計數單位是「元件數 × 變體數」加上「樣式與變數的組數」。這是五項裡最容易被當成贈品的一項，也是價值最高的一項。

設計系統到底交付了什麼

「設計系統」這個詞在報價單上非常危險，因為它從「一組共用色票」到「一套完整的元件庫加文件」都可以叫這個名字，中間差十倍工時。

用 Figma 的官方定義來拆比較清楚。Figma 說明文件把 Styles 定義為「Use styles to define the color, text and any effects applied to objects」，把 Variables 定義為「Variables are raw values—like color, numbers, and strings—that can change in value depending on the context of a design, such as light and dark modes, or mobile and desktop modes」。兩者的關鍵差別在於別名（aliasing）：官方文件寫「Styles don’t support aliasing. In other words, they cannot be applied to variables and other styles. Variables can be applied to both.」

順帶更正一個常見的誤寫：Figma 官方沒有說 variables 就是 design tokens。 官方的說法是「A design token is an industry term to refer to reusable values」，然後說明 variables 讓你做到 token 需要的別名機制。要匯入 token 檔的話，官方要求是 JSON 格式且符合 Design Tokens Community Group（DTCG）規格。另外 variables 現在官方列的是六種型別：Color、Number、String、Boolean、Timing（毫秒）、Easing（緩動曲線或彈簧動畫），每個 collection 上限 5,000 個變數。

所以報價單上的「設計系統」要拆成三個層級，讓客戶自己選：

1. 層級一：樣式集——色彩、字級、陰影、圓角的 styles 建好並套用在設計稿上。這是最低限度，通常已經含在畫面報價裡。
2. 層級二：元件庫——按鈕、輸入框、卡片、導覽等元件做成 component 與 variant，含各種狀態。這一層要按元件數報價。
3. 層級三：變數與模式——用 variables 支援深淺色模式或多品牌切換，並發布到 team library 供其他檔案引用。注意這一層有方案限制：發布 variables 到 team library 需要付費方案（官方原文為「the education plan and any paid plans」，免費的 Starter 不含），Variable modes 的數量上限依方案不同（Professional 為 10 個 modes、Organization 為 20 個），Starter 免費方案不含 modes（查核日 2026-08-02）。這一層要一併確認由誰付 Figma 的費用。

「交付到哪裡算完」的三個層級

這一句話一定要寫進報價單或合約，三選一：

層級 A：檔案交付即完成。 你把設計檔、原型連結、切圖資料夾交出去，驗收依據是「交付物清單上的項目都存在且可開啟」。這是最乾淨的一種，適合客戶內部有產品團隊、你只負責設計的案子。

層級 B：含開發期問答。 交付之後，在約定期間內（例如四週）回答工程端關於設計的問題、補齊漏掉的狀態、微調不合理的規格。這一段要明訂期間與問答的形式（例如「四週內，透過同一個訊息群組，累計不超過 X 小時」），否則它會無限延伸。這是實務上最常見也最合理的一種。

層級 C：含上線後驗收。 產品上線後你要比對實作與設計的落差並提出修正清單。這一層等於把你的責任綁在別人的執行品質上，除非另外計價、而且你對工程端有一定的影響力，否則不要接。真的要接，也必須寫清楚你只負責提出清單，不負責對方是否修改。

三個層級對應到不同的尾款觸發點。民法第 505 條規定「報酬應於工作交付時給付之，無須交付者，應於工作完成時給付之。工作係分部交付，而報酬係就各部分定之者，應於每部分交付時，給付該部分之報酬」。這一條的實務意義是：如果你採用分階段交付、分階段計價，每一段交付完就可以請該段的報酬，不必等整個案子結束。這對現金流的意義比多數人想像的大。

改稿輪次：設計案跟其他案型不一樣的地方

「一次修改」的通用定義（一次彙整、書面、有期限）在需求變更的加價話術與變更單那篇拆得很細，這裡只補設計案獨有的三件事。

探索期與收斂期的輪次要分開算

設計案有一個其他案型少見的結構：前期本來就該多方向、後期本來就該少改動。 如果你的合約寫「全案含三次修改」，會發生兩種悲劇之一——要嘛你在探索期就用掉三次（因為前期本來就要試方向），後面每個小調整都要開變更單，客戶覺得你在斤斤計較；要嘛你放寬前期，然後在後期無限期地改。

正確的寫法是分段各給輪次：

• 方向探索階段：提供 N 個視覺方向（通常 2–3 個），客戶選定一個，含 1 次方向調整。選定後不可回頭換方向，要換視為新增階段。
• 風格定調階段：以選定方向做出 1–2 個代表性畫面，含 2 次修改。這個階段結束後，色彩、字級、間距、元件樣式全部凍結。
• 套版展開階段：其餘畫面依定調的規則展開，含 1–2 次修改，且修改範圍限於該畫面自身的內容與排版，不含已凍結的樣式。

這樣寫的好處是它符合設計實際發生的順序，客戶讀起來也合理。最重要的是它建立了凍結點：風格定調結束就凍結，之後客戶說「我覺得主色還是換一下」，那不是一次修改，那是回到上一個階段，全案所有畫面都要重跑。

三個在設計案裡必須先定義的邊界

第一，新增畫面不算修改。 這一點必須白紙黑字。客戶回饋「這裡加一個確認頁比較好」，聽起來像修改意見，實際上是新增交付物。定義：修改是在既有畫面清單內調整，任何清單外的畫面都是新增項目。

第二，狀態的補齊算不算。 如果報價時列舉了狀態清單，清單內的狀態是本來就該交的，不算修改；清單外的新狀態是新增。如果報價時沒列舉狀態清單，這個爭議無解——所以回到第五章那三題，訪談時就要問。

第三，內容替換不是修改，但爆版是。 客戶把假字換成真實文案，這是他的工作。但如果真實文案長度導致排版必須調整（中文標題從 8 個字變成 22 個字，整個卡片版面垮掉），那個調整算誰的？建議寫成：「因客戶提供之實際內容長度顯著超出設計時之範例長度，所需之版面調整視為修改次數之一」。並且在設計時就用接近真實長度的範例文字，這比事後爭論有效得多。

把改稿收斂成書面的三句話

設計改稿最耗損的不是改本身，是「口頭回饋 → 你理解 → 改錯 → 再改」的循環。三句話可以擋掉大部分：

1. 回饋請寫在同一個地方（Figma 檔案的留言，或同一份文件），不要散在訊息、Email 與會議口頭之間。Figma 的檢視與留言對客戶是免費的，這一點下一章會講。
2. 回饋請盡量描述問題而非解法。「這個按鈕不夠明顯」是問題，「把按鈕改成紅色」是解法。前者讓你能用專業判斷處理，後者你只能照做，然後兩週後客戶說「還是不夠明顯」。
3. 每一輪回饋請在約定的期限內一次給完，逾期或分批給的視為下一輪。

Figma 檔案的所有權與交接：三件常被混為一談的事

案子結束時，客戶說「檔案給我」。這句話裡其實有三件互相獨立的事，混在一起談就會出錯。

第一件：著作權歸誰（法律層）

台灣《著作權法》第 12 條的現行有效條文是：「出資聘請他人完成之著作，除前條情形外，以該受聘人為著作人。但契約約定以出資人為著作人者，從其約定。依前項規定，以受聘人為著作人者，其著作財產權依契約約定歸受聘人或出資人享有。未約定著作財產權之歸屬者，其著作財產權歸受聘人享有。依前項規定著作財產權歸受聘人享有者，出資人得利用該著作。」

白話說：接案（承攬）情況下，沒有約定的話，著作人與著作財產權預設都是你（設計師）的，而出資的客戶取得「利用」的權利。這跟很多人以為的「付錢的人就有版權」相反。

另外兩條要一起看。第 10 條：「著作人於著作完成時享有著作權。但本法另有規定者，從其規定。」第 21 條：「著作人格權專屬於著作人本身，不得讓與或繼承。」也就是說，即使你把著作財產權全部讓與客戶，著作人格權讓不掉——這是你之後能把作品放進作品集的最後一道保障，但實務上仍然要在合約寫明「乙方得於作品集與宣傳素材中使用本案成果」，因為著作人格權跟保密義務是兩回事，客戶可以用保密條款擋你公開。合約條款怎麼寫，接案合約的著作權歸屬那一節有可以直接抄的版本。

第二件：Figma 帳號層的「檔案所有權」（平台層）

這跟著作權完全無關，它是平台上的一個權限設定。而 Figma 官方對它的說明裡有一個很多人不知道的坑。

官方的「Transfer ownership of files or projects」說明頁寫著操作方式（在分享視窗把對方權限改成 Owner，再按 Transfer ownership 確認），但同一頁明確列出轉移不會做的事：「When you transfer ownership of a file, Figma will not: Move the file to a different location… Adjust your access permissions on the current file, or prevent you from viewing the file.」而且「It’s not possible to undo these actions.」

翻成實務語言：轉移所有權只是換名分，檔案還在你的空間裡，你還看得到、還能編輯。 如果客戶的期待是「檔案完全移交到我們公司的 Figma、你那邊不再保有」，光按這個按鈕做不到。

官方文件裡實際可行的交接路徑有五條，各有代價：

路徑	官方限制（查核日 2026-08-02）	適合的情境
轉移單一檔案 owner	不會搬動檔案位置、不會取消你的存取權，且無法復原	只是要把帳單與管理責任交出去
轉移整個 Project	「Owners can only transfer ownership to someone who is an existing collaborator on that project」	整個案子的檔案一起交
轉移整個 Team	「This process only changes the ownership of the team」，Professional 方案不會更新帳單資料；轉移後你仍留在該 team 擔任 admin	整個客戶專屬 team 交出去
把檔案 move 到客戶的 team	需同時加入兩個 team 且都有編輯權；官方明說「It’s not possible to move a file between different Figma accounts or organizations using the steps above」，跨帳號轉專案「requires both the sender and the receiver to be on a paid plan」	客戶已有付費 Figma 環境
匯出 .fig 檔給客戶匯入	「Available on any plan」，但「Any components in the imported file will become new main components… will not receive updates from components in the original file」，且「Figma doesn’t include any version history or comments when you save a local copy」	客戶不打算付 Figma 費用

兩個最痛的坑值得單獨標出來。第一，轉移 team 給客戶但沒有先改帳單資料，Figma 會繼續扣你的卡。 官方原文寫得很清楚：「If you also pay for the subscription, you will need to update the billing details for your team, before you transfer ownership.」第二，跨帳號搬專案需要收送雙方都在付費方案。 也就是說，如果客戶堅持不付 Figma 的錢，你唯一的路只剩 .fig 匯出，代價是元件全部斷連、版本歷史與留言全部丟失。這件事必須在報價階段問清楚，不是交付當天才發現。

第三件：客戶要不要付 Figma 的錢（成本層）

先把價格講精確，因為這是台灣中文文章最常寫錯的地方。Figma 定價頁預設顯示的是年繳均攤價，切到月付會變成另一組數字（查核日 2026-08-02，幣別 USD）：

方案／seat	年繳均攤（每月）	實際月付	價差
Professional｜Full seat	$16	$20	月付貴 25%
Professional｜Dev seat	$12	$15	月付貴 25%
Professional｜Collab seat	$3	$5	月付貴 67%
Organization｜Full／Dev／Collab	$55／$25／$5	官方僅提供年繳（Billed annually），無月付選項
Enterprise｜Full／Dev／Collab	$90／$35／$5	同上，僅年繳

還有一個接案者常踩的細節，官方 FAQ 逐字寫著：「If you’re on a Professional plan, if you add new paid seats to your team during your annual subscription term, Figma charges you a separate monthly subscription for those seats at the monthly price.」——年繳期間中途加人，那個人是按月付價另外算。案子中途拉客戶或協作者進來變成付費 seat 之前，先確認誰付這筆。

然後是好消息，而且是很多人不知道所以白花錢的一項：客戶端的檢視與留言完全免費。 Figma 定價頁的比較表在四個方案全欄都標示 Unlimited viewers，說明文字逐字是「Invite as many people as you want to view, comment, inspect, or export from your Figma files—for free!」FAQ 更進一步：「you can access inspect information as a free viewer… you will be able to view measurements and property values, copy CSS, iOS, and Android code, export assets, comment on files, and collaborate via cursor chat.」

所以客戶要看設計、要留言回饋、甚至工程端要複製基本的 CSS 或量測值，都不需要買 seat。需要付費 seat 的是編輯，以及完整的 Dev Mode。

免費方案能不能撐？先看清楚 Starter 的限制

Figma 的 Starter（免費）方案官方說明寫著：「The Starter plan includes a single team and project. Within the project, Starter teams are limited to: 3 total Figma Design and Figma Sites files / 3 FigJam files / 3 Figma Slides files」，另外「you can have an unlimited number of drafts」（drafts 是尚未移進 project 的檔案），版本歷史只有 30 天，沒有 team libraries，而且「Dev Mode is not available on the Starter plan.」邀請協作者時「you can only invite collaborators to drafts with can view access」，要給編輯權就必須升級。

降級或超過上限會怎樣？官方原文是「Figma will prevent you from being able to edit your files」，專案數超過則「Figma will lock your team and prevent you from editing your files」。注意官方用的字是「不能編輯」，沒有承諾「仍可檢視」，也明確寫了「Downgrading or cancelling your subscription does not automatically delete your account」以及「Payments for Figma subscriptions are non-refundable」。

對接案者的實務結論：你自己那一份付費 seat 是營業成本，該算進底價時薪的年度固定成本裡（回到第三章的算式）。客戶那一端，如果只是要看與回饋，不用花錢；如果客戶要長期持有並自行維護設計檔，那 Figma 訂閱是客戶的營運成本，這件事要在報價階段就說明，不要等交付當天才變成爭議。

順帶一提，交接時除了設計檔，通常還會有一堆帳號與權限要一起處理（圖庫授權、字型授權、原型連結的分享設定、共用雲端硬碟）。這一段的離場流程可以參考客戶帳密交接與離場撤銷的做法。

與工程端的協作介面：切版落差的責任歸屬

這一章談的是設計交出去之後的那段灰色地帶——實作出來的東西跟設計稿不一樣，誰負責。

先看工具實際提供了什麼

Figma Dev Mode 的官方說明頁在文章開頭列出兩行前提：「Available on all paid plans」與「Requires a Full or a Dev seat」。也就是說免費方案完全沒有 Dev Mode，而 Collab seat 與 View seat 的說明頁寫的是「No access to Dev Mode; basic inspection only.」

Dev Mode 官方列出的能力包含：Compare changes（「See exactly what has changed over time by comparing side-by-side」）、Focus view（「Get an isolated view of the frames you’re building, filtering out the rest of the canvas」）、Advanced inspection（「Access code snippets, component properties, and structured layer data directly from the canvas」）、Annotations（「Developers can retrieve variable, property, and measurement information for specific layers」）、Dev resources（可把 GitHub 檔案、Jira 票、Storybook stories 連到圖層）、以及 Dev statuses 與通知。說明文件裡的狀態標記操作是「Click Mark as ready for dev in the toolbar」，而「All plans that provide Dev Mode include the Ready for dev status. An additional status, Completed, is available if you’re on an Organization or Enterprise plan.」

程式碼輸出的語言常被寫錯，官方文件寫的是三個平台五種語言：「Select an option from the Language dropdown: CSS (Web) / SwiftUI or UIKit (iOS) / Compose or XML (Android).」單位也可切換（CSS 可 px 或 rem、iOS 可 px 或 pt、Android 可 px／dp／sp）。

如果團隊不用 Figma 或需要獨立的規格文件，Zeplin 仍然是選項。它的定價頁（查核日 2026-08-02，幣別 USD）現在只有 Free／Basic／Advanced／Enterprise 四個方案，FAQ 逐字說明「As of September 2024, Zeplin’s Team and Org plans are no longer available for new purchases」。計價分兩種模式：Basic 是「Pay per project」（1 個專案年繳均攤 $13.75／月、實際月付 $15；3 個專案為 $35.75／$39；6 個為 $63.25／$69），Advanced 是「Pay per seat」（年繳均攤每席每月 $12、實際月付 $15）。Free 方案限 1 個專案、100 個畫面、1 份 styleguide、最多 100 個 components、版本歷史 30 天，且 FAQ 寫明「on the Free Plan, ONLY Owners can publish designs and delete designs from Zeplin」。Reviewer 一樣免費且無人數上限，但「They however do not have access to developer specs」。

切版落差的四種成因，責任歸屬完全不同

「做出來跟設計稿不一樣」是一句沒有資訊量的抱怨。先分類，才有辦法談責任。

成因一：規格根本沒給。 設計稿上只畫了預設狀態，沒有 hover、沒有錯誤、沒有超長文字的處理，工程師只好自己決定。這是設計端的責任，而且是最常見的一種。防法是把狀態清單放進交付物定義（第六章），並在交付前自己走一遍每個互動元素。

成因二：規格給了但工程端沒讀。 標註都在、Dev Mode 也標了 ready for dev，但實作出來的間距全部是憑感覺抓的。這是工程端的責任，但你要能證明規格存在——這就是為什麼「所有規格集中在一個地方」比「散在訊息裡回答過」重要。

成因三：設計在技術上做不出來（或成本過高）。 你設計了一個需要客製元件才能實現的效果，而專案用的是現成框架。這是雙方的責任，而防範點在報價前的第七題（工程端用什麼技術、有沒有既有元件庫）。已經發生的話，正確的處理是提出一個成本較低的替代方案，而不是堅持照做。

成因四：實作過程中的取捨沒有回報。 工程端遇到問題，自己做了決定但沒告訴任何人，上線後才被發現。這是流程的責任，防法是在交付時約定一個「實作偏離設計時的回報管道」，並在合約的層級 B（開發期問答）裡涵蓋這類討論。

絕對不要寫進合約的一句話：「像素級還原」

這句話在報價單與合約裡很常見，通常是設計師為了展現專業而主動寫的。不要寫，理由有三個。

第一，它在技術上不成立。不同瀏覽器的字體算繪、不同裝置的像素密度、系統字體的替代規則、以及動態內容的長度，都會讓實作與設計稿有像素級差異。你寫下一個做不到的承諾，等於送給對方一張永久有效的挑錯券。

第二，它把驗收標準交到主觀判斷手上。差幾個像素算不算違反？沒有人說得清楚，而說不清楚的條款在爭議時對你不利。

第三，它綁住的是別人的執行。實作的人不是你，你卻承擔了實作結果的責任。

正確的替代寫法是把驗收綁在可檢驗的規格上：「實作應符合交付之設計規格，其中間距、字級、色值以交付檔案之標註為準；因瀏覽器或裝置差異造成之算繪落差不在此限」。這句話既保護你，也給工程端一個明確的依據。

前三個案子怎麼接：一條可執行的入門路徑

把前面所有東西收成一條路徑。這不是唯一的路，但它的每一步都有明確的產出，不會讓你卡在「我還沒準備好」。

第一步：先算出底價時薪（半天）。 用第三章的三行算式，把你自己的年度需開票金額、可計費工時填進去。這個數字先不對外，它只是你心裡的地板。沒有這個數字，你在第一次被砍價時會直接崩潰。

第二步：把現有的一件作品寫成完整案例（一到兩週）。 用第四章的六個區塊。如果一件都沒有，先找一個小型組織的真實案子，走完整流程。寧可要一件有過程的作品，不要五件只有結果的圖。

第三步：把訪談九題印出來（半小時）。 真的印出來或存成手機備忘。前三個案子的訪談你一定會忘記問其中幾題，照著念不丟臉，忘了問才會痛。

第四步：做一份自己的報價單範本（半天）。 含五類交付物的分項、「一頁」與「一次修改」的定義、分段的改稿輪次、交付到哪個層級、Figma 費用由誰負擔、著作權歸屬。第一版一定不完美，但每接一個案子就修一次，三個案子之後它會變成你最有價值的資產。

第五步：前三個案子刻意選不同的計價模型。 一個用專案制、一個用時薪制、一個用混合制。三個做完你會知道自己的估算誤差在哪個方向、以及哪種模型跟你的工作方式相合。這件事沒有辦法用讀的學會。

第六步：每個案子結束後花一小時復盤。 記三個數字：估算工時、實際工時、以及「客戶端等待與重工」佔了多少。第三個數字累積三次之後，你的報價會開始準。

案源要從哪裡來、要不要走接案平台，是另一個獨立的決定，跟本文談的報價與交付是兩條平行線——先把報價算法與交付定義建立起來，換到哪個管道接案都還是用同一套。

常見問題

完全沒有相關背景，可以直接開始接 UI/UX 的案子嗎？

可以，但要選對第一批案子的類型。門檻最低而且最不容易出事的是範圍明確、畫面數少、沒有複雜狀態的案子：單頁式活動頁、小型形象官網、既有網站的局部改版。避開的是有登入系統、有金流、有後台管理的案子，因為那類案子的狀態數與流程分支會遠超過你的估算能力，而估錯在專案制下是你自己吃下去。另外一個實際的建議是：前兩個案子用時薪制或混合制報價，等你有了自己的估算誤差資料再轉專案制。

客戶問「你們的行情大概多少」，我該怎麼回答？

不要給一個數字，也不要說「看情況」（後者聽起來像在拖延）。可以這樣回：「這類案子的價格主要由三件事決定——畫面數與需要的狀態數、要不要含資訊架構與流程設計、以及交付到哪個程度（只交設計檔，還是含切圖標註與開發期支援）。我先問幾個問題，十五分鐘後可以給你一個區間。」

這個回答有三個作用：它避開了不存在的「行情」、它把接下來的訪談合理化、而且它已經開始教育客戶「價格是由範圍決定的」，這對後續的變更談判很有幫助。

客戶要求把 Figma 檔案「完全交出來」，我該答應嗎？

要先問清楚他說的是哪一種。如果是「我們要能繼續編輯與維護」，那是合理需求，交付路徑用第八章那張表選一條，並確認客戶端有付費的 Figma 環境（跨帳號轉專案需要雙方都在付費方案）。如果他說的是「你那邊不能再保留任何檔案」，那要分開談：平台上的存取權可以撤掉，但你的著作人格權讓不掉（著作權法第 21 條），而能不能公開展示則取決於合約的保密條款。實務上合理的折衷是：交出可編輯的完整檔案、你保留一份匯出的靜態版本供作品集使用，並在合約寫明可展示的範圍與時間點（例如上線三個月後）。

網路上的「台灣 UI/UX 接案行情表」到底能不能參考？

可以當成「別人的經驗」看，不能當成統計。判斷方式很簡單：看它有沒有寫母體。 有沒有說樣本從哪來、幾筆、什麼期間、包不包含哪些交付物。沒有寫母體的數字，你無法判斷它是十年資歷的人接大型 App 的價，還是新手接單頁的價，兩者可以差一個數量級。真的要參考，優先看有揭露方法論的來源——1111 的薪資公秤會寫樣本數與資料期間，UXTW 的年度產業調查會逐張圖標 n；但要記得那兩份都是受僱或從業者的月薪／年薪，不是接案報價。看完之後，永遠把它跟你自己的底價時薪對照，而不是拿它取代你的計算。

UI 跟 UX 要不要分開報價？

報價單上要分開，但不必用「UI」「UX」這兩個詞。用本文第一章的六段來分項會清楚得多——客戶看得懂「資訊架構與流程」「視覺語言建立」「高保真畫面」「交付與工程協作」各是一筆錢，但看不懂「UX 設計費」跟「UI 設計費」的差別在哪。分項的真正目的不是收更多錢，是讓客戶在砍價時能砍到具體的東西（例如「這次先不做流程重整」），而不是要你在總價上打折。

要不要買 Figma 的付費方案？免費的不能用嗎？

只要你開始接案，付費方案幾乎是必要的，理由不是功能多，是三個實務限制：免費的 Starter 方案在單一 team 的 project 內只能有 3 個 Figma Design 檔、版本歷史只有 30 天、沒有 Dev Mode、而且邀請協作者時只能給檢視權（要給編輯權必須升級）。版本歷史 30 天這一項對接案者特別致命——設計案的爭議常常在兩三個月後才浮現，那時候你想調出「客戶當初確認過的版本」，已經沒有了。把它當成營業成本算進底價時薪，而不是當成可省的開銷。

作品集裡的概念稿，客戶會在意嗎？

會，但在意的點跟多數人想的不同。客戶通常不在乎那個專案是不是虛構的，他在乎的是你有沒有在真實約束下工作過。所以一份標明「個人概念專案」但寫出了明確約束與取捨的案例，說服力會高於一份宣稱是委託案、卻只有漂亮畫面沒有任何過程的案例。真正扣分的只有一種：把概念稿寫得像委託案，然後在對話中被問倒。誠實標示的成本很低，被拆穿的成本很高。

接了案子才發現自己估錯工時，怎麼處理比較好？

先分清楚是「你估錯」還是「範圍變了」。範圍變了就走變更程序，這是正常的商業行為。如果純粹是你估錯（你以為三天、實際八天），那這一次原則上要吃下去——中途以「我算錯了」為由要求加價，會嚴重損害信任。但要做兩件事：第一，記錄下來，這是你估算模型的校正資料；第二，如果誤差大到會虧損嚴重，可以誠實跟客戶談「調整範圍」而不是「調整價格」——把某些次要畫面移到第二期，總價不變但範圍縮小，這比要求加錢容易被接受得多。

免責聲明與資料來源

法規

• 著作權法第 12 條（全國法規資料庫）——出資聘請他人完成之著作的歸屬
• 著作權法第 21 條——著作人格權不得讓與或繼承
• 著作權法第 10 條——著作人於著作完成時享有著作權
• 民法第 505 條——報酬給付時點與分部交付
• 民法第 490 條——承攬的定義

薪資與費率統計（各自的母體已於內文標明）

• 勞動部《職類別薪資調查報告》（資料時期民國 114 年 7 月）——設計職類的受僱員工薪資；調查對象明文排除自營作業者
• 104 薪資情報｜UX 設計師與UI 設計師——頁面未載明方法論
• 1111 薪資公秤｜UI/UX 設計師——來源為會員履歷資料庫，資料區間 2021-01 至 2024-12
• 台灣使用者經驗設計協會（UXTW）《2023 台灣使用者經驗設計產業與工作者調查報告》——總樣本 n=346，量綱為年薪；報告內無報價／時薪欄位。協會官網 uxtw.org 於查核日無法解析，此為協會置於雲端硬碟之報告本體
• Upwork｜UX designer 費率頁——母體為「certain historical contracts worldwide」
• Fiverr｜UI UX designer 成本指南——平台賣家自訂價格
• User Interviews × Levels.fyi｜2026 UX Salary Report——freelancer 為年收入，n=293
• Fast Company × AIGA｜The Design Pricing Transparency Project——費率數字位於付費牆後，本文未引用金額

工具官方頁面（查核日 2026-08-02）

• Figma 定價頁——預設顯示年繳均攤價，需手動切換才看得到月付價
• Figma｜Starter plan overview
• Figma｜Transfer ownership of files or projects
• Figma｜Transfer ownership of a team
• Figma｜Move a file
• Figma｜Save a local copy of files（.fig 匯出）
• Figma｜Upgrade or downgrade your plan
• Figma｜Guide to Dev Mode
• Figma｜Dev Mode 的程式碼輸出語言
• Figma｜Variables 與 Styles 的差別
• Zeplin 定價頁——Team 與 Org 方案自 2024 年 9 月起停止新購
• Behance Community Guidelines——無「概念稿標示」規範
• Dribbble Community Guidelines——無「概念稿標示」規範