核准设计的流程：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。

其余内容属于任务描述中的文字，模板把六项全部做成了一份「如何提出设计需求」文档，你可以直接指给大家看。

十分钟就能试出来。开始一个免费的 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 子清单，整套论点就在三行里。

招聘海报的 Why this date 写着「校园招聘会在 8 月 16 日」。合作品牌套件早一周到期，却写着「合作方的发布尚无日期」。同一个队列、同一个字段，但只有一个是真正的期限。

让这些行成立的是：

• 三个字段，类型很重要。Requested by 是用户字段，队列因此能按提出者筛选。Why this date 是文本。Review round 是数字，没有小数，所以能排序。在任何地方重建这三个，你就拿到了大部分价值。
• 用标签标明用途：web、brand、social、print、email、video，以及真正紧急才用的 rush。
• Intake: not triaged，存放尚未接受、估时或排期的需求的子清单。它的长度是产能信号；它的分流规则才是真正的关卡，因为每一项都需要需求方、理由，以及档期或回绝。
• Waiting on a decision，存放交给核准人、等待决定的完成作品的子清单。看的是时间长短，不是条数。
• 一个预先建好的 Creative sign-off 核准类别，完成的作品会交给指定的人，得到有记录的同意，或一份修改清单。
• 两份文档：「如何提出设计需求」是给需求方的六项答案清单，「如何使用此模板」是五步设置指南。
• 一个 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，拷贝这条管线，让你的下一个设计需求走一遍。

常见问题

什么是设计核准流程？

创意作品从有人提出需求，到指定的人签核通过所经过的路径。多数团队只有中间，缺少头尾。Quire 的 Design Pipeline 模板两头都补上了：前端是需求文档，后端是有记录的核准。

怎样避免设计需求变成零散的消息？

给大家一个更好的地方，并让它成为更快的路径。模板附带一份文档，列出需求需要的六个答案，还有一个接收子清单，新需求进来时状态为 Requested。

设计修改几轮才算正常？

一轮正常，两轮没问题，三轮通常说明简报有误，而不是作品有问题。Review round 字段让它从一种感觉变成可以排序的一列。

谁应该核准设计作品？

每项决定由一位指定的人负责，且他们清楚哪项决定归自己。Quire 的核准类别把决定附加到某个人身上，而不是某个频道。

外部客户如何在 Quire 中评审设计作品？

只需要查看的客户打开无须注册的共用链接，需要的话可限定在一个子清单。要做决定的客户则以指定核准人的身份加入项目，签核因此会落在需求上。

任务管理软件能运行设计核准流程吗？

可以。在 Quire 中，每个需求是一个任务，每个阶段是一个状态，签核是任务上的核准，因此队列、轮次和决定共用同一条记录。

规范的设计核准流程如何帮助团队提高工作效率？

减少重画。在 Quire 中计算评审轮次，能让你看出第三轮集中在哪里。改好这些简报，就不必再为同一份设计稿付两次工，设计师也能拿回被重画吃掉的时间。