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

最後更新：2026 年 10 月 21 日

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

再乘以六位請求者，隊列就不再是隊列，而是一堆私下的默契，每位請求者都相信自己是下一個。

設計核准流程還要經得起重複。合約只簽一次，但同一份設計稿會被決定三、四次，而每位決策者看到的版本都不同。

它在兩個沒人規範的地方出問題：請求如何送達，以及第一次審閱到第四次審閱之間發生甚麼事。

甚麼是設計核准流程？

設計核准流程分六個階段：已提出、設計中、內部審閱、等待核准、需要修改和已交付。請求以書面需求說明和日期背後的原因進入流程，每次修改令輪次加一，最後的批准則以一位指定人員的核准記錄在請求上。

大部分團隊兩端都略過了。

為甚麼設計核准流程在設計開始前已經出問題？

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

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

最後這一點很容易補救。幾乎每個請求都有日期，卻幾乎沒有一個附上原因。

把原因單獨放在請求的一個欄位裏，兩種請求就自然分開。「印刷廠截稿日是 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 的文字欄位，然後為最舊的五個未完成請求填寫。很可能有兩個完全沒有原因，這就已經證明了論點。

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

六個階段是已提出、設計中、內部審閱、等待核准、需要修改和已交付。這六個階段追蹤作品所在的位置。決定則有獨立的記錄，即任務上的核准，把兩者分開正是整件事的關鍵。

以下是設計流程範本中各階段的運作方式：

內部審閱是團隊最常略過的階段，卻最值回票價。有了它，與核准人的第一輪就可以用來討論構思，而不是糾纏於圓角半徑。

需要修改是唯一會逆向運行的階段，所以最值得計算。下文會再詳述。

表中每個階段都是兩個團隊之間的交接：提出需求的一方和負責設計的一方。跨部門專案管理實戰指南闡述了背後的責任歸屬和交接層面。若想先為自己的流程畫出這些交接，業務流程圖會教你怎樣做，包括泳道圖。

Quire 的設計流程範本包含甚麼？

一個可以直接運作的設計隊列：上述六個階段、三個自訂欄位、兩個子清單、一個創意簽核核准類別、兩份文件和一個儀表板。打開 Quire 的設計流程範本，點進 Intake: not triaged 子清單，整個論點就在三行資料裏。

招聘海報的 Why this date 寫着「Careers fair is 16 Aug」。提早一星期到期的合作夥伴聯名套件，則寫着「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，一個放置已完成、停在核准人手上的作品的子清單。請按停留時間而不是數量來看。
• 一個預先建好的創意簽核核准類別，完成的作品會交給指定人員，得到記錄在案的批准或一份修改清單。
• 兩份文件：How to request design work 是給請求者的六項答案清單，How to use this template 是五個步驟的設定指南。
• 一個 Creative Ops 儀表板，附有受阻任務小工具，以及六個狀態的分布。

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

在示範資料開始像是你自己的東西之前，先把它們刪掉；也別急着加第四個欄位，除非同一個問題出現過兩次。三個欄位會有人填，六個欄位只會被忽略，而被忽略的欄位比沒有更糟，因為它看起來仍像資料。

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

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

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

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

兩個子清單承擔了大部分工作。子清單就是專案中主清單旁邊一個儲存下來的切片。兩者人人可見，開啟「核准」欄後，每一行的裁決也一目了然。

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

有一個區別決定你該看哪裏。

等待核准階段是共用的隊列，可以排序，也是你在星期一檢視的對象。

審核與請求小工具是你個人的收件匣，計算等待你核准的項目和你發出的請求，所以對兩者都沾不上邊的人來說，它顯示為零。只有前者能回答團隊層面的問題。

已經在專門工具裏校對檔案，並在設計稿上加了標記？繼續用它來做標記，然後把校對連結貼到請求裏。隊列、輪次計數和簽核仍然留在任務上，全隊都看得見。

外部審閱者卡在建立帳號的時間，比卡在設計本身的更多。只需要看一看的客戶，可以打開一條完全不需要帳號的連結，範圍還可以限定在單一子清單：這裏教你不用註冊也能與客戶共用專案。

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

預算一次重畫、一次流失，而一般的設置完全不會記錄。第一輪沒有問題。第四輪才是預算消耗殆盡的時候，而幾乎沒有流程文件涵蓋兩者之間的過程。

所以要計算。Review round 欄位把模糊的「來回折騰」感覺變成可排序的欄位。一輪是正常，兩輪沒問題，而一群第三輪的請求，就是穿着設計問題外衣的接收問題：需求說明出錯了，重畫是修補不了需求說明的。

另一半是各輪次的內容。龔振星（Zhenxing Gong）和張娜（Na Zhang）對七家公司 264 名僱員進行研究，發現具支持性的回饋環境會透過影響人的情緒，間接促進創意表現。

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

由此得出一條值得執行的規則：回饋要指出修改，而不是感覺。

「感覺不對」不是修改請求，「徽章在 375px 時跑到卡片外面」才是。無法指出修改處的審閱者還未準備好審閱，及早說明比讓人猜三輪來得體貼。

在 Quire 裏，這些回饋連同檔案都留在任務上，所以第二輪是針對第一輪所討論的同一份設計稿，審閱者在提出新要求之前，也能看到自己上次要求了甚麼。

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

它停在第二輪，留言指出兩項修改：客戶引言缺少職稱，以及一項指標與內文不符。

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

客戶工作是同一個問題的放大版，因為修改意見來自你的團隊之外：代理商專案管理，告別混亂談到當審閱者就是付款的人時，怎樣限制輪次。

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

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

也要在任務中說明哪個決定由他們負責。「你要核准的是字標組合，不是色彩配搭」可以避免最常見的審閱出軌，即審閱者回答了一個沒人問過的問題。

流程很簡單。打開請求，在創意簽核下提出核准請求，它就會送到那個人手上。他們核准，或者要求修改。

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

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

複製範本後要立即更改一件事：示範資料的 Creative sign-off 設了兩位核准人。請在專案設定中填上你真正的審閱者，並減至一位，因為有兩位核准人的設計又回到沒有核准人的狀態。

核准功能適用於 Premium 及以上的 Quire 方案。自訂狀態（六階段流程所用）則所有方案都有，包括免費方案。詳情請見價格頁面。

這些機制各有專文介紹：以自訂狀態建立的核准流程，以及專屬的核准功能。本文講的是兩者都預設已有的一層，即為它們供應請求的隊列。

重點整理

如果只能帶走一件事，就帶走輪次計數器。第三輪的設計幾乎從來不是設計問題，而每一小時花在重畫上，都是在處理症狀。

在你的任務管理軟件中計算輪次，證據自然會指向上游：那個含糊得無法動工的請求。其餘的事就順理成章。

設計流程範本已備有計數器、接收清單和六項答案的請求文件，所以下一步很小。把請求文件貼到你現時接收請求的頻道，看看這個星期的請求有多少能回答全部六項。

註冊新帳號，複製這個流程，把你下一個設計請求放進去跑一次。

常見問題

甚麼是設計核准流程？

創作工作由有人提出需求，到一位指定人員簽核所經過的路徑，分六個階段，由已提出到已交付。Quire 的設計流程範本把這些階段設為狀態，前端有請求文件，後端有記錄在案的核准。

如何避免設計請求以零散訊息形式送達？

提供更好的地方，並讓它成為更快的途徑。範本附有一份列明請求所需六項答案的請求文件，另有一個接收子清單，新請求會以「已提出」狀態進入其中。

設計修改多少輪才算正常？

一輪正常，兩輪沒問題，三輪通常代表需求說明有誤，而不是作品有問題。Review round 欄位把這件事變成可排序的欄位，而不是一種感覺。

誰應該核准設計工作？

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

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

只需要看一看的客戶，可以打開無須註冊的共用連結，範圍可限定在一個子清單。需要作決定的客戶則加入專案，擔任指定核准人，這樣簽核就會記錄在請求上。

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

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

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

減少重畫。在 Quire 計算審閱輪次，就能看到第三輪集中在哪些地方。修正那些需求說明，就不用為同一份設計稿付兩次費用，設計師也能拿回原本被重畫佔去的時間。