去年接手過一個爛攤子。客戶是一家健康食品品牌，NT$60 萬的官網加會員系統，設計找了一家工作室，開發找了另一家。設計端交了 42 張 Figma 畫板，開發端做完了，驗收時客戶說「跟設計稿不一樣」。往下追，爭議項目有 63 條，其中 51 條的本質是同一件事：設計稿沒有畫到那個狀態——按鈕按下去的樣子、輸入框錯誤的樣子、清單沒資料的樣子、文字超長的樣子、手機上第三個斷點的樣子。
設計端說「那是常識」，開發端說「規格沒寫」。兩邊都沒有錯，因為合約裡從來沒有一行字定義過「設計交付完成」的標準。這 27 個工作天的延誤，帳單最後落在客戶頭上。
業界迷思打破
迷思一：「設計稿交出來就算交付完成了」
真相：Figma 檔案是媒介，不是交付物。真正的交付物是一份能被工程實作、且能被客戶驗收的規格：畫板、元件庫、狀態清單、斷點規則與內容極值範例五件事。少了後三項，工程師只能猜，而猜出來的一定跟客戶腦中的不一樣。
迷思二：「開發應該照著設計稿做，不用問」
真相：一個中等複雜度的頁面通常有 30 到 60 種可能狀態（載入中、空狀態、錯誤、權限不足、資料超長、離線…），設計稿畫得再細也只涵蓋其中 8 到 15 種。剩下的必然要靠事先約定的預設規則，不是靠開發臨場發揮，也不是靠事後爭吵。
迷思三：「找同一家做設計加開發就不會有這問題」
真相：會少一點，但不會沒有。同一家的好處是責任單一；壞處是爭議被內化，客戶反而看不見——你不會知道哪些細節是工程師自己決定掉的。解方不是「找同一家」，是「不管幾家都要有交界規格」。
迷思四：「Figma 有 Dev Mode，工程師自己看就好」
真相：Dev Mode 給的是數值，不是意圖。它會告訴你這個 margin 是 24px，不會告訴你這是「全站統一的卡片間距」還是「這裡剛好好看」。前者該抽成變數，後者可以硬寫。分不清楚的結果，是三個月後改一個間距要動 40 個檔案。
核心框架：交界責任四象限
把所有爭議項目丟進這張表，九成能當場定位。
| 設計稿有畫 | 設計稿沒畫 | |
|---|---|---|
| 規格有定義 | A 象限｜照做 做不一樣就是開發的責任，免費修正。 | B 象限｜照規則做 依約定的預設規則（設計系統／元件庫）實作，做不一樣是開發責任。 |
| 規格沒定義 | C 象限｜以稿為準 畫面照畫板，但互動與極端情況需另行確認，屬於變更單範圍。 | D 象限｜新需求 雙方都沒定義過，屬於新增需求，走變更控制與計價。 |
這張表最重要的作用不是判責，是把爭吵變成分類動作。爭論「這該不該算 bug」是無解的，但爭論「這一條該放哪一格」是有解的——因為判準是客觀事實（設計稿有沒有、規格有沒有）。
配套的計價公式很簡單：A、B 象限免費修正並計入驗收；C 象限每項以 0.5 到 2 小時估算，累積超過 8 小時開變更單；D 象限一律開變更單，按工作室標準時薪計價。把這三句話寫進合約，可以省下我們那個案子的 27 天。
三類典型情境對照
- 小型專案（NT$15–40 萬，單一廠商包全）：通常沒有正式標註稿。不要求完整設計系統，但要求一份「狀態清單」——所有互動元件的按下、停用、載入、錯誤四種狀態，加三個斷點示意。成本增加約 8 到 12 小時，能擋掉七成爭議。
- 中型專案（NT$40–120 萬，設計與開發分包）：最容易出事的規模。合約明訂設計交付驗收清單，並要求兩家在開發啟動前開一次交界會議，逐項確認元件命名、間距系統、色彩變數與圖示規格。兩小時的會議，省下後面二十天。
- 大型或長期專案（NT$120 萬以上或年度 Retainer）：需要真正的設計系統與變數機制。把 Figma Variables 與程式端變數寫成對照表，約定「設計端改變數、工程端一週內同步」的節奏。這階段值得投資的是流程，不是更多畫板。
隱藏成本完整清單
- 狀態補畫：每個中等複雜頁面 3 到 6 設計小時，以 NT$1,500/小時計、10 個頁面就是 NT$45,000–90,000。事前做是這個價，事後吵是三倍。
- 元件命名不一致：設計端叫「主要按鈕」、工程端叫
btn-primary、客戶叫「橘色那個」。每次對不上多花 15 到 30 分鐘，一個專案累積 20 到 40 小時。 - 字型授權：上線前才發現設計稿用了未購買商用授權的字型。繁中字型商用授權年費常見 NT$8,000–60,000，換字型還要重調全站行高與斷行。
- 圖片與圖示規格：沒約定輸出格式與尺寸，工程端自行匯出導致模糊或檔案過大。重整一套圖示約 6 到 15 小時，且直接影響首屏載入速度指標。
- 極端內容測試：中文姓名 2 到 15 字、商品名稱 5 到 60 字、金額到億位。沒測就上線，第一週必爆版，補救 10 到 20 小時。
- 驗收會議本身：三人開 2 小時等於 6 個工時。爭議多的專案開 8 到 12 次很常見，就是 50 到 70 個工時憑空消失。
- 第二次設計：開發做完客戶說「跟想的不一樣」，設計端重做一輪。這筆通常沒人願意付，最後由總包吸收或轉嫁成延期。
合計，一個 NT$60 萬專案的交界隱藏成本落在 NT$120,000 到 NT$250,000，佔專案 20% 到 40%。而前置把規格寫清楚，通常只要 NT$30,000 到 NT$60,000。
評估外包夥伴的 12 維計分卡
簽約前拿這張表去問設計方與開發方，每項 0 到 3 分，36 分滿分。低於 24 分的組合，建議先補流程再開工。
- ☐ 1. 能否提供過去專案的「設計交付驗收清單」範本？
- ☐ 2. 設計檔是否使用元件（Component）與變數，而非散裝圖層？
- ☐ 3. 是否提供互動狀態清單（按下／停用／載入／錯誤／空狀態）？
- ☐ 4. 是否定義間距系統與字級階層，而非逐頁自由排版？
- ☐ 5. 斷點規則是否明確（含最小與最大寬度行為）？
- ☐ 6. 是否提供極端內容範例（最長／最短／無資料）？
- ☐ 7. 字型與圖片授權是否書面確認可商用？
- ☐ 8. 元件命名是否與工程端約定一致？
- ☐ 9. 是否願意參加開發啟動前的交界會議？
- ☐ 10. 開發端是否能在兩週內產出可點擊的前端骨架供設計方回饋？
- ☐ 11. 是否有明確的變更單流程與計價標準？
- ☐ 12. 驗收爭議是否約定用可分類的判準（如四象限），而非個案協商？
ScriptWalker 的對應方案與不適合情境
我們最常被找上的三種情況：客戶已有設計稿要找開發、客戶要設計加開發一起包、以及像開頭那個案子——兩家吵起來了要找第三方收尾。
第一種，我們先做設計稿可實作性檢查（6 到 10 小時，NT$12,000–20,000），標出缺少的狀態、不一致的間距、無法實作的效果，產出補件清單交回設計方；這份清單通常能把後續爭議壓到 20% 以下。第二種，交界規格直接寫進合約附件。第三種，用四象限把爭議分類，先讓雙方對「哪些免費修、哪些另外算」達成共識，再談排程。
不適合找我們的情境：
- 只想找人把 Figma「像素完美」複製成網頁，不接受任何實作性回饋——這種需求應該找純切版廠商，價格會低很多。
- 設計稿還在頻繁大改中就要求開始開發——並行做得到，但需要接受返工，且要以 Retainer 而非固定價計費。
- 希望我們同時擔任設計方與開發方的仲裁者，但不願意調整合約與流程——沒有規格的仲裁，只是換個人吵。
啟動期遊戲書
- 第 1 週：三方交界會議。確認元件命名對照表、間距與字級系統、色彩變數清單、圖示輸出規格。交付物是一份兩頁的交界備忘錄，三方簽名。
- 第 2 週：設計方補齊狀態清單與極端內容範例；開發方產出可點擊的前端骨架（無樣式，只有結構與流程），讓設計方與客戶提早看到動線。
- 第 3–4 週：完成 2 到 3 個代表性頁面的完整實作，做第一次交界驗收。這次驗收的目的不是驗功能，是校準標準——把爭議項目丟進四象限跑一次，確認三方對判準的理解一致。
- 第 5 週起：進入常規開發節奏，每兩週一次交界檢查，累積的 C、D 象限項目統一開變更單。
- 驗收前 2 週：凍結設計變更，只處理 A、B 象限修正。這條線一定要寫進合約，否則永遠收不了尾。
決策清單
- ☐ 合約裡有沒有定義「設計交付完成」的驗收標準？
- ☐ 有沒有一份互動狀態清單？
- ☐ 間距與字級是系統化的，還是逐頁自由的？
- ☐ 斷點規則寫清楚了嗎？
- ☐ 極端內容（最長／無資料）有範例嗎？
- ☐ 字型與圖片的商用授權確認了嗎？
- ☐ 設計方與開發方的元件命名對得上嗎？
- ☐ 開發啟動前有排交界會議嗎？
- ☐ 爭議判準是四象限這類可分類方法，還是個案協商？
- ☐ 變更單的計價標準寫在合約裡了嗎？
- ☐ 驗收前的設計凍結期有寫進合約嗎？
- ☐ 誰是最終拍板的人？只有一個人嗎？
- ☐ 前四週有沒有安排一次「校準用」的小規模驗收？
勾不到 8 項，你的專案有很高機率會在驗收期卡住兩到四週。
常見問題 FAQ
設計與開發到底該不該分開發包？
分開不是問題，沒有交界規格才是。分包的優點是各自找到專長最強的團隊、議價空間大；缺點是責任分散。判斷方式：如果你自己（或有專人）能主持交界會議並拍板判準，分包沒問題；如果沒有人能做這件事，找總包並多付 10% 到 20% 的整合費是划算的。
「像素完美」是合理的要求嗎？
對靜態畫面是合理的，對響應式與互動不是。同一份設計稿在不同裝置、不同字體渲染引擎、不同內容長度下必然有差異。合理的驗收標準是「設計系統一致」——間距用同一組數值、色彩用同一組變數、元件行為一致，而不是逐頁比對像素。
開發做出來跟設計稿不一樣，該由誰付錢修？
用四象限判。設計稿有畫且規格有定義（A 象限）是開發責任，免費修；設計稿沒畫但有設計系統可依循（B 象限）也是開發責任；設計稿有畫但互動未定義（C 象限）小量吸收、超量開單；兩邊都沒定義（D 象限）是新需求，另外計價。把這四句寫進合約，爭議會從「誰的錯」變成「這條在哪一格」。
需要導入完整的設計系統嗎？我們公司很小。
不需要完整，但需要最小可用版本：一組間距數值（例如 4、8、12、16、24、32、48）、一組字級階層（5 到 7 級）、一組色彩變數（含語意命名如 danger、success）、以及按鈕與輸入框的四種狀態。這四樣東西一個下午就能定完，能擋掉最多爭議。
驗收期卡住了，現在怎麼止血？
三步：第一，把所有爭議項目列成一張表，不辯論、只記錄。第二，用四象限逐條分類，先處理雙方無異議的 A、B 象限，讓進度動起來。第三，把 C、D 象限打包成一張變更單，一次談價與排程，不要逐條談。實務上這三步通常能把兩到四週的僵局壓到五個工作天內。
你的專案卡在設計與開發之間嗎？
ScriptWalker 提供「設計稿可實作性檢查」（NT$12,000 起，6 到 10 小時）與「交界爭議分類與收尾」兩項服務。前者在開發前做，後者在吵起來之後做——前者便宜很多。我們也承接設計加開發整包的專案，交界規格直接寫進合約附件。
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p