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

最後更新：2026 年 10 月 1 日

「可以順便幫我弄一下嗎」是創意工作中代價最高的一句話。這句話後面通常跟著一個真實的需求和真實的期限，但它是以訊息的形式出現，而不是正式需求，也就是說，只有在有人記得的時候它才存在。

乘上六位提出者，佇列就不再是佇列。它變成一堆私下的默契，每個人都相信自己的案子是下一個。

設計核准流程還必須禁得起重複。合約簽一次就好，但同一份稿件會被決定三、四次，而且每位決定者看到的版本都不一樣。

它會壞在兩個沒人建立結構的地方：需求如何送進來，以及第一次審閱到第四次審閱之間發生了什麼事。

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

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

於是聲音最大的提出者獲勝，因為音量是大家唯一的判斷依據，設計師也悄悄變成了佇列本身。更糟的是，優先級再也無法討論：「這很急」沒有任何東西可以查證。

最後這點其實很容易解決。幾乎每筆需求都有日期，卻幾乎沒有人寫理由。

把理由獨立成需求上的一個欄位，兩種需求就會自動分開。「印刷廠截止日是 7 月 16 日，沒有彈性」是期限，「沒有硬性日期，現有範本在手機上會跑版」則不是。兩者都是真實的工作，但只有一個能插隊。

在 Quire 中，關卡就設在分流階段：沒有提出者與該欄位理由的需求，就不能離開收件清單。這樣一來，「這很急」就成了可以查證的事。

當太多人能留言、卻沒有人是決策者時，設計佇列也會卡住：RACI、DACI 與 RAPID 比較講的是「誰決定、誰提供意見」，是以下所有內容的底層。

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

六個答案。備齊六項的需求今天就能開工；缺了其中兩項的需求，光是溝通就要花三天。

• 是什麼，用一句話說明。「Instagram 輪播，五張」勝過「為上市做點東西」。
• 出現在哪裡，尺寸多大。網站橫幅、32px 的 App 圖示與兩公尺寬的展位看板，是同一個詞背後的三種工作。
• 給誰看。指的是目標受眾，而不是公司內部的利害關係人。
• 何時，以及為什麼是那天。理由比日期更有資訊量。
• 誰簽核。一個名字。
• 現有什麼資料。簡報、文案、前一版。每一項缺少的素材都會變成問題，而問題會把三天拖成兩週。

專案經理已經把這件事量化了。

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 範本中各階段的運作方式：

內部審閱是團隊最常跳過的階段，卻也最值回票價。它讓與核准者的第一輪把時間花在想法上，而不是圓角半徑。

需要修改是唯一會往回走的階段，所以最值得計數。後面會再詳談。

表中的每個階段，都是提出需求的團隊與負責設計的團隊之間的交接。跨部門專案管理攻略說明了其底層的責任歸屬與交接層面。

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 儀表板，附有受阻任務小工具，以及六個狀態的分布圖。

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

在範例資料開始變得像你自己的之前就把它們刪掉，而且在事情出錯兩次之前，先別加第四個欄位。三個欄位會有人填，六個就會被忽略，而被忽略的欄位比沒有更糟，因為它看起來還像資料。

Design Pipeline 是 Quire 範本庫中的分階段流程首選。專案管理範本整理把其餘範本依有限、重複與分階段的工作分類，方便你找到下一個需要的範本。

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

因為需求一旦變成任務，管線階段就能做到訊息串做不到的事。任何人打開專案，就能從範例資料看到有四筆在核准者手上、三筆尚未分流，不必請設計師逐項報告。

這就是任務管理軟體在創意工作中的全部任務：每筆需求都有階段、負責人與排隊位置，這是聊天記錄從來做不到的。

這兩個子清單承擔了大部分工作，子清單就是專案旁的一份已儲存的切片。兩者所有人都看得到，開啟核准欄後，每一列的結論也看得到。

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

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

等待核准階段是共用的佇列，可以排序，也是你週一要檢視的內容。

審核與請求小工具是你個人的收件匣，統計等你處理的核准以及你送出的請求，所以對兩者都沒有的人來說顯示為零。只有前者能回答團隊層級的問題。

已經在用專門的工具校對檔案、在稿件上加標記嗎？那就保留它做標註，再把校對連結貼到需求裡。佇列、輪次數與簽核都留在任務上，讓整個團隊看得見。

外部審閱者卡關的原因，往往是建立帳號，而不是設計本身。只需要看的客戶可以打開連結，完全不用帳號，需要的話還能限定在單一子清單：以下是如何與客戶共用專案而不需對方註冊。

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

預算會一次一次重畫地流失，而一般的設定完全不會記錄。第一輪沒問題，第四輪是預算死亡的地方，而幾乎沒有任何流程文件涵蓋中間這一段。

所以要計數。Review round 欄位把模糊的來回折騰感，變成可以排序的欄位。一輪很正常，兩輪沒問題，一堆第三輪則是披著設計問題外衣的收件問題：簡報錯了，而重畫無法修正簡報。

另一半是輪次裡的內容。在一項針對七家公司 264 名員工的研究中，Zhenxing Gong 與 Na Zhang 發現，支持性的回饋環境會透過人們的情緒，間接促進創意表現。

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

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

「沒有感覺」不是修改請求。「徽章在 375px 時跑到卡片外面」才是。說不出要改什麼的審閱者，還沒準備好審閱，早點這樣說，比猜三輪更體貼。

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

範本在個案研究單頁上有一個實例，就是上方清單中標示 Creative sign-off：變更請求回應的兩列之一。

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

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

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

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

每項決定指定一個人，決定直接記錄在需求本身。一份設計有兩位核准者，等於沒有核准者。範本使用 Creative sign-off 類別，讓決定歸屬於指定的核准者，而不是一個房間的人。

也請在任務中說明哪項決定歸對方。「你要核准的是字標組合，而不是色彩配置」，可以避免最常見的審閱偏題，也就是審閱者回答了沒人問的問題。

流程很短。開啟需求，在 Creative sign-off 下請求核准，它就會送到那個人手上。對方選擇核准，或要求修改。

不論哪種，答案都會留在需求上。要求修改會讓作品退回一輪，所以 Review round 要加一。

有一項設定能讓簽核變成真正的關卡。在專案設定的狀態下，開啟「核准尚未完成時禁止完成任務」的選項，在核准者說好之前，沒有任何東西能進入已交付。

複製之後要立刻調整一件事：範例中的 Creative sign-off 附有兩位核准者。請在專案設定中填入你真正的審閱者並改為一位，因為一份設計有兩位核准者，就又回到沒有核准者。

核准功能適用於 Premium 及更高等級的 Quire 方案。支援六階段管線的自訂狀態則所有方案都有，包括 Free。完整詳情請見價格頁面。

這些機制各有專文介紹：以自訂狀態建立的核准流程，以及專用的核准功能。本文談的是兩者的前提，也就是為它們供應需求的佇列。

重點整理

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

在你的任務管理軟體中計算輪次，證據自然會指向上游，也就是那個模糊到無法據以製作的需求。其餘的就水到渠成了。

Design Pipeline 範本已經備有計數器、收件清單與六答案需求文件，所以下一步很小。把需求文件貼到你目前收需求的任何頻道，看看這週有多少需求能回答全部六個問題。

註冊新帳號，複製這條管線，然後讓你的下一個設計需求跑過一遍。

常見問題

什麼是設計核准流程？

創意作品從有人提出需求，到指定人員簽核所經過的路徑。多數團隊只有中間段，缺少頭尾。Quire 的 Design Pipeline 範本兩者都有，前端是需求文件，後端是有紀錄的核准。

如何避免設計需求以零散訊息的形式出現？

給大家更好的管道，並讓它成為更快的路徑。範本附有一份列出需求必備六個答案的需求文件，以及一個收件子清單，新需求會以「已提出」狀態進入。

設計修改幾輪算正常？

一輪很正常，兩輪沒問題，三輪通常表示問題出在簡報，而不是作品。Review round 欄位讓它從一種感覺，變成可以排序的欄位。

誰該核准設計作品？

每項決定指定一個人，而且對方清楚哪項決定歸自己。Quire 的核准類別把決定歸屬於人，而不是頻道。

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

只需要看的客戶可以開啟免註冊的共用連結，需要的話可限定在單一子清單。要做決定的客戶則以指定核准者的身分加入專案，簽核就會留在該筆需求上。

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

可以。在 Quire 中，每筆需求是一個任務、每個階段是一個狀態、簽核是任務上的核准，所以佇列、輪次與決定共用同一筆記錄。

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

減少重畫。在 Quire 計算審閱輪次，就能看出第三輪集中在哪裡。修正那些簡報，就不必再為同一份稿件付兩次成本，把原本耗在重畫上的時數還給設計師。