設計核准流程：6 個階段、請求清單與範本

最後更新：2026 年 10 月 1 日

「可以順手幫個忙嗎」是創作工作中代價最高的一句話。這句話後面通常跟着一個真實的需求和真實的死線，但它是以訊息的形式出現，而不是正式請求，所以只有在有人記得的時候才存在。

六位請求者各自這樣做，佇列就不再是佇列，而變成一堆私下的默契，每位請求者都相信自己排在下一個。

設計核准流程還要經得起重複。合約簽一次就完事，但同一份美術稿會被決定三、四次，而且每位審閱者看到的版本都不一樣。

流程會在兩處出問題，而這兩處都沒人整理：請求如何送來，以及第一次審閱與第四次審閱之間發生什麼事。

為什麼設計核准流程在設計開始前就會出問題？

問題出在收件：以訊息形式送來的請求沒有狀態，所以它所屬的佇列是看不見的。訊息不能「等待中」、「已接受」或「排第三」，只有已讀和未讀。

於是聲量最大的請求者勝出，因為音量是大家唯一的訊號，而設計師就默默變成了佇列。更糟的是，優先級再也無從討論：「這個很急」根本無法對照任何東西去核實。

這一點其實很容易補救。幾乎每份請求都有日期，卻幾乎都沒有原因。

把原因單獨放成一個欄位，兩種請求自然分開。「印刷廠截稿日是 7 月 16 日，沒有彈性」是死線；「沒有硬性日期，只是現有範本在手機上會跑版」則不是。兩者都是真實的工作，但只有一種可以插隊。

在 Quire 中，把關發生在分流階段：請求者和原因欄位沒填好，就不能離開收件清單。這樣「這個很急」就變成可以核實的事。

設計佇列也會因為太多人可以留言、卻沒有人負責拍板而塞車：RACI、DACI 與 RAPID 比較講的是誰決定、誰提意見這一層，是下文一切的底層。

設計請求在開工前必須說明什麼？

六個答案。同時具備六項的請求今天就可以開工；缺了其中兩項的，就是一場要談三天的對話。

• 是什麼，用一句話說明。「Instagram 輪播，五張」比「為發佈會做點東西」好得多。
• 出現在哪裡，以及尺寸。網站橫幅、32px 的應用程式圖示和兩米寬的展覽板，雖然都叫一個詞，卻是三種不同的工作。
• 給誰看。指的是目標受眾，不是內部的持份者。
• 何時，以及為什麼是那個日期。原因比日期包含更多資訊。
• 誰簽核。只寫一個名字。
• 現有什麼。簡報、文案、上一個版本。每項缺少的資料都會變成問題，而問題會把三天拖成兩星期。

專案經理早已用數字說明了這一點。

PMI 的 Pulse of the Profession 需求研究發現，近半（47%）失敗的專案是因為需求管理不準確而未能達成目標。設計請求就是縮小版的需求，含糊的請求同樣會失敗，只是來得更快。

六項之中有一項值得有自己的欄位，因為欄位能讓答案可以排序：日期背後的原因就成為 Why this date。

旁邊還有兩個欄位，Requested by 記錄提出請求的人，Review round 記錄作品被退回的次數。

其餘的內容放在任務描述裡，而範本把六項全都附在 How to request design work 文件中，你可以直接請大家參考。

十分鐘就能試出效果。開始一個免費的 Quire 專案，或打開你現有的專案，新增一個名為 Why this date 的文字欄位，然後替最舊的五份未完成請求填上。很可能有兩份根本沒有原因，這樣你就不必再多說了。

設計核准流程的六個階段是什麼？

六個階段是 Requested、In Design、Internal Review、Awaiting Approval、Changes Requested 和 Delivered。這六個階段記錄作品在哪裡。決定則另有記錄，即任務上的核准，把兩者分開就是成功的大半。

以下是 Design Pipeline 範本中每個階段的運作方式：

Internal Review 是團隊最常略過的階段，卻也最值回票價。它讓與核准人的第一輪用來討論創意，而不是圓角。

Changes Requested 是唯一往回走的階段，所以最值得計算。下文會再詳述。

上表的每個階段都是兩個團隊之間的交接，一方提出需求，另一方負責設計。跨職能專案管理指南介紹了底層的責任歸屬與交接層面。

Quire 的 Design Pipeline 範本包含什麼？

一個可以直接運作的設計佇列：上述六個階段、三個自訂欄位、兩個子清單、一個 Creative sign-off 核准類別、兩份文件和一個儀表板。打開 Quire 的 Design Pipeline 範本，進入 Intake: not triaged 子清單，整個論點就在三行之中。

Recruiting posters 的 Why this date 寫着「Careers fair is 16 Aug」。Partner co-brand kit 早一星期到期，卻寫着「Partner launch has no date yet」。同一個佇列、同一個欄位，只有其中一個是真正的死線。

這些行背後的組成：

• 三個欄位，類型很重要。Requested by 是用戶欄位，所以佇列可按提出者篩選。Why this date 是文字。Review round 是數字，沒有小數，因此可以排序。在任何地方重建這三個欄位，你就得到大部分價值。
• 按用途設標籤：web、brand、social、print、email、video，以及真正緊急的 rush。
• Intake: not triaged，這個子清單放着尚未接受、估算或排期的請求。它的長度是產能的訊號，分流規則才是真正的把關，因為每一項都需要請求者、原因，以及排期或拒絕的決定。
• Waiting on a decision，這個子清單放着交給核准人、等候決定的完成作品。要看停留了多久，而不是有多少項。
• 一個預先建好的 Creative sign-off 核准類別，完成的作品交給指定人員，得到有記錄的同意，或一份修改清單。
• 兩份文件：How to request design work 是給請求者的六項答案清單，How to use this template 是五個步驟的設定指南。
• 一個 Creative Ops 儀表板，附有受阻任務小工具和六個狀態的分佈。

複製只需大約一分鐘。打開範本名稱旁的下拉選單，進入 More，選擇 Duplicate（複製），再選擇副本要放在哪個組織。

在範例資料開始變得像你自己的資料之前，先把它們刪掉；在同一件事出錯兩次之前，不要加第四個欄位。三個欄位會被填寫，六個欄位會被忽略，而被忽略的欄位比沒有更糟，因為它看起來仍像數據。

Design Pipeline 是 Quire 範本庫中的分階段流程之選。專案管理範本總覽把其餘範本分為有限、重複和分階段三類工作，讓你輕鬆找到下一個需要的範本。

為什麼設計請求應該放在任務管理軟件而不是聊天群組？

因為請求一旦成為任務，流程階段就能做到訊息串做不到的事。任何人打開專案，就能在範例資料中看到四項在核准人手上、三項尚未分流，不必叫設計師逐項背誦。

這就是創作工作中任務管理軟件的全部作用：每份請求都有階段、負責人和排隊位置，這是聊天記錄從來做不到的。

兩個子清單承擔了大部分工作，子清單就是主清單旁邊一份已儲存的專案切片。兩者人人可見，開啟 Approval 欄後，每一行的裁決也一樣可見。

在 Waiting on a decision 停留三天，通常代表有人在迴避。

有一個分別決定你該看哪裡。

Awaiting Approval 階段是共用的佇列，可以排序，也是你星期一要審閱的內容。

審核與請求小工具是你自己的收件匣，計算等你處理的核准和你送出的請求，所以對兩者都不沾邊的人來說就顯示為零。只有前者能回答團隊層面的問題。

已經在專門工具裡校對檔案、直接在美術稿上標註嗎？繼續用它做標註，再把校對連結貼到請求裡。佇列、輪次數目和簽核都留在任務上，整個團隊都看得到。

外部審閱者卡在建立帳號的時間，往往比卡在設計本身更多。只需要查看的客戶可以用連結直接打開，完全不需要帳號，需要的話還可限定在單一子清單：看看如何讓客戶不用註冊就能共用專案。

設計審閱的第一輪到第四輪之間會發生什麼事？

預算一次重畫就流失一點，而一般的設定完全不會記錄。第一輪沒問題，第四輪就是預算消耗殆盡的時候，而幾乎沒有任何流程文件談到中間這段。

所以要計算輪次。Review round 欄位把模糊的反覆感覺變成可以排序的欄位。一輪正常，兩輪無妨，一堆第三輪就是披着設計問題外衣的收件問題：簡報錯了，重畫是解決不了簡報的。

另一半是每一輪裡面有什麼。Zhenxing Gong 和 Na Zhang 研究了七家公司的 264 名員工，發現具支持性的回饋環境會透過人們的情緒，間接促進創作表現。

他們的結論是：「塑造具支持性的主管回饋環境，對提升創作表現相當重要」。這是問卷數據，所以應視為相關性而不是槓桿，不過重點依然成立：回饋是工作的一部分，而不是對工作的反應。

由此得出一條值得執行的規則：回饋要說明要改什麼，而不是感覺如何。

「感覺不對」不算修改要求。「徽章在 375px 時跑到卡片外面」才是。說不出要改什麼的審閱者，還沒有準備好審閱，早點說出來，比猜三輪來得厚道。

在 Quire 中，回饋和檔案一起放在任務上，所以第二輪面對的是第一輪討論的同一份美術稿，審閱者在提出新要求之前，也能看到上次要求了什麼。

範本在案例研究一頁紙上有一個實例，就是上面清單中兩行顯示 Creative sign-off: Request changes 的其中一行。

它處於第二輪，留言指出兩項修改：客戶引言缺少職稱，以及一個數字與正文不符。

然後留言明確保護第一輪已經簽核的部分。這一點比聽起來重要得多，因為重新打開已定案的決定，正是第二輪變成第五輪的原因。

客戶工作就是把音量調大的這個問題，因為修改意見來自團隊以外：不再混亂的代理商專案管理談到在審閱者就是付款人時，如何限制輪次。

誰來簽核，決定記錄在哪裡？

每項決定由一位指定人員負責，而決定要記錄在請求本身。有兩位核准人的設計等於沒有核准人。範本使用 Creative sign-off 類別，讓決定落在指定核准人身上，而不是落在一個房間裡。

也要在任務中說明哪項決定屬於他們。「你要核准的是字標組合，不是配色」，可以避免最常見的審閱偏題，也就是審閱者回答了一個沒人問過的問題。

流程很短。打開請求，在 Creative sign-off 下請求核准，請求就會送到那位人員手上。他們核准，或要求修改。

無論哪種結果，答案都會記錄在請求上。要求修改會讓作品退回一輪，所以 Review round 加一。

有一個設定可以把簽核變成真正的關卡。在專案設定的狀態下，開啟「核准仍待處理時阻止完成」的選項，在核准人同意之前，沒有任何東西能進入 Delivered。

複製範本後要馬上改一件事：範例的 Creative sign-off 附有兩位核准人。在專案設定中設定你真正的審閱者並減為一位，因為有兩位核准人的設計，又回到沒有核准人的狀態。

核准適用於 Premium 及以上的 Quire 方案。承載六階段流程的自訂狀態，所有方案都有，包括 Free。詳情請見價格頁面。

運作方式另有專文介紹：以自訂狀態建立的核准流程，以及專用的核准功能。本文講的是這兩者所預設的那一層，也就是為它們供應請求的佇列。

重點整理

如果只能記住一件事，就記住輪次計數器。第三輪的設計幾乎從來不是設計問題，每花一小時重畫，就是花一小時治標。

在你的任務管理軟件中計算輪次，證據自然會指向上游，指向那份含糊得無法着手的請求。其餘的就水到渠成。

Design Pipeline 範本已經備好計數器、收件清單和六項答案的請求文件，所以下一步很小。把請求文件貼到你現在接收請求的任何頻道，看看本星期有多少份請求能回答全部六個問題。

註冊新帳號，複製這個流程，然後用它處理你的下一份設計請求。

常見問題

什麼是設計核准流程？

創作作品從有人提出需求，到指定人員簽核的路徑。多數團隊只有中間一段，前後兩端都欠缺。Quire 的 Design Pipeline 範本把兩端都補上，前端有請求文件，後端有記錄在案的核准。

如何避免設計請求變成零散訊息？

給大家一個更好的地方，並讓它成為更快的途徑。範本附有請求文件，列出一份請求需要的六個答案，還有一個收件子清單，新請求會以狀態 Requested 進入。

設計修改幾輪才算正常？

一輪正常，兩輪也無妨，三輪通常代表問題出在簡報而不是作品。Review round 欄位把這件事變成可以排序的欄位，而不是一種感覺。

誰應該核准設計作品？

每項決定由一位指定人員負責，而且他們清楚知道哪項決定屬於自己。Quire 的核准類別把決定交到一個人手上，而不是一個頻道。

外部客戶如何在 Quire 審閱設計作品？

只需要查看的客戶，可開啟免註冊的共用連結，需要的話可限定在一個子清單。要做決定的客戶則以指定核准人身分加入專案，簽核便會記錄在請求上。

任務管理軟件可以運行設計核准流程嗎？

可以。在 Quire 中，每份請求是一項任務，每個階段是一個狀態，簽核是任務上的核准，所以佇列、輪次和決定都在同一份記錄上。

完善的設計核准流程如何幫助團隊提升工作效率？

減少重畫。在 Quire 計算審閱輪次，就能看到第三輪集中在哪裡。改善那些簡報，就不必再為同一份美術稿付兩次代價，設計師也能拿回被重畫佔去的時間。