修改地獄的真實成因

設計案超時超預算的主要原因通常不是一次大的改動，而是無數次「小修改」的累積。

這些小修改的背後有幾個常見原因：

需求沒有在一開始被充分定義：當 Brief 不夠清楚，設計師基於自己的理解做出來，客戶基於自己的想象看到成果，兩者不一致時的修改是「修正理解偏差」，不是真的需求改變。

決策者不在場：設計師和窗口確認沒問題，但窗口的上司或老闆看到後說「不是我要的」，造成已確認的設計大改。

客戶在過程中改變了想法：這是正常的，但如果合約沒有說清楚，誰來承擔因此而來的額外工作？

邊界不清楚：客戶不知道什麼算「修改範圍內」，什麼算「需要追加費用」。設計師也因為沒有明確的規則，不好意思說「這需要另外計費」。

在合約中定義修改規則

合約中對修改次數的條款，建議包含：

明確定義什麼是「一個修改回合」：

一個修改回合 = 客戶在設計師交付稿件後，整理並提交的一次完整修改意見，設計師依據這份意見進行修改並更新稿件。

注意：客戶在看到更新稿後又提出「剛才忘記說的」不算同一回合——鼓勵客戶在提出修改意見前徹底整理好所有意見。

例如：本方案包含每個設計模塊 2 次修改回合。超出的修改回合，按每回合 NT$X,XXX 另計費用。

2 次修改回合的結構通常是：

2 輪通常對需求清楚的案子足夠，對需求複雜的案子可以設定 3 輪。

超出包含回合的修改，按 NT$X,XXX / 回合計費，在開始修改前以訊息通知並確認。

這個透明的「超出計費規則」給雙方都帶來安全感：客戶知道可以無限修改但需要付費；設計師不需要擔心一直做免費修改。

在設計流程的關鍵節點（例如：設計方向確認後、線稿確認後、視覺稿確認後），要求客戶以書面（LINE 或 Email）確認這個階段的成果已確認，後續若有重大改動才能明確邊界。

當收到修改意見時，如果意見是口頭或零散的，把它整理成一份結構化的清單並發回確認：

「根據您的意見，我整理以下修改項目：1. 首頁 Hero 背景改為深色 2. 標題字型改小 3. CTA 按鈕改為方形。請確認這 3 項是本次修改的完整範圍。」

這個整理動作能避免「又冒出來的」意見，也讓客戶知道設計師有認真記錄每個意見。

當客戶說「感覺太普通了，可以更有質感嗎？」，不要直接就改，先問清楚：

「您說的『有質感』，可以舉一兩個您覺得質感好的參考案例嗎？或者您在哪些方面感覺目前的設計不夠好（顏色、字型、留白、還是整體排版）？」

把模糊的反饋轉化為具體的方向，才能做出符合期望的修改。

與其在修改發生後管理，不如在專案開始前就做好預防：

需求釐清投資時間：在設計開始前，花足夠的時間在需求訪談和 Design Brief 的確認上。

確保決策者在場：明確要求「最終決策者也要參與中間的確認會議」，避免最後突然出現改變方向的意見。

展示設計的方式要對：用「這是基於 X 目標的設計決策，它能達成 Y 效果」的方式說明設計，而不只是「這是設計稿，你覺得如何」——這讓修改討論有邏輯基礎，而不是純粹的個人好惡。