Write Acceptance Criteria for Creative Deliverables

AI-generated conceptual illustration; not a product screenshot, measured result, or factual diagram.

“Make it feel premium” can start a useful conversation. It cannot tell a designer whether the deliverable is ready to approve. Neither can “engaging,” “on brand,” or “something people will share.” Those phrases leave the team to discover the decision rules after the work is already in front of everyone.

Acceptance criteria make the review more concrete. They describe what the deliverable must contain, what it must do, how it will be checked, and who can approve it. They also leave room for creative judgment instead of pretending every design decision can be reduced to a yes-or-no test.

This guide focuses on that part of a creative brief. If you need the wider project structure, start with the site's creative brief guide. Here, the outcome is a deliverable-specific approval matrix you can use to review a video, landing page, or illustration set without inventing the rules halfway through.

Separate three kinds of decision

Most confused reviews mix together requirements, quality judgments, and hoped-for business results. Write them separately.

A requirement is directly checkable: the landing page includes a working registration link, the video includes the agreed closing card, or the illustration set contains six assets in the required dimensions. Someone can inspect the deliverable and record whether the requirement is met.

A quality judgment concerns how well the work serves its purpose: whether the opening makes the offer understandable, whether an illustration feels consistent with the others, or whether the page's hierarchy helps the intended reader find the next step. A reviewer still needs to exercise judgment, but the question can be focused and tied to an audience.

A business result is an outcome after release, such as completed registrations. It belongs in the brief and the measurement plan. It is usually a poor acceptance gate for a deliverable that must be approved before anyone sees it. The team can approve the tracking implementation and the clarity of the call to action; it cannot honestly approve a conversion result that has not happened.

Use a record that names the evidence

For each criterion, capture six fields: deliverable, criterion, type of check, evidence, reviewer, and decision point. Add a status and a note when the review happens. This can be a small table in your working document or a set of repeated cards. The structure matters more than the software.

“Mobile-friendly” is too broad to be a useful row. A better requirement might be: “The agreed page content and registration control remain available in the project’s named narrow-screen test cases, without overlap or clipped labels.” The evidence is the tested page and the results of those checks, not a designer saying it looks fine on a phone.

Then add the quality question separately: “Can a first-time visitor explain who the event is for and what they will do there after reading the page?” That question may be explored through a small content review or a usability session. Record the method and its limits rather than claiming that a handful of reviewers represents the whole audience.

A fictional launch with three deliverables

Imagine a community workshop called Open Bench announcing a beginner repair evening. The fictional project includes a 45-second launch video, a registration landing page, and three original illustrations. All names, deadlines, quantities, and proposed decisions below are invented to demonstrate the process.

The audience is adults who own an item they would like help repairing but are unsure whether the event welcomes beginners. The communication goal is to help them understand the format and decide whether to register. The approved offer says participants bring one small item, work with a volunteer, and receive guidance rather than a guaranteed repair.

That last distinction should survive every deliverable. An image of a perfectly restored object, a triumphant video ending, and a “Get it fixed” button could collectively imply a promise the event does not make. An approval matrix helps the team inspect that implication across formats.

Worked approval matrix: the launch video

V1: Content requirement. The final video states the event name, date, location, beginner welcome, and registration destination using the approved facts. Evidence: the final playback plus a comparison against the dated source sheet. Reviewer: the event producer. Decision point: final factual review.

V2: Scope and technical requirement. Deliver one 45-second landscape master and one separately composed vertical version in the export specifications agreed for the two destinations. Evidence: the delivered files, their properties, and playback at each intended destination or an agreed equivalent. Reviewer: the editor and delivery owner. Decision point: delivery review. The exact codecs, dimensions, and platform requirements belong in the project specification, where they can be checked when the work is commissioned.

V3: Meaning judgment. The video should convey guided participation without promising that every object will be repaired. Evidence: a review of the narration, selected footage, captions, and closing card together. Reviewer: the producer, with the creative lead advising on execution. Decision point: rough-cut review, then confirmation after final changes.

V4: Comprehension judgment. The opening should give a new viewer a concrete reason to keep watching by showing the repair activity and establishing who can attend. Evidence: the rough cut watched without the project team narrating over it. Reviewer: the creative lead. Decision point: rough-cut review. This is a focused creative question; it does not require a claim that the video will achieve a particular retention rate.

If V3 fails, a technically perfect export is still not ready. If V2 fails because the vertical file is missing, the team does not need another debate about the concept. Different failure types need different fixes.

Worked approval matrix: the landing page

P1: Information requirement. Include the approved event details, what participants can bring, the limits of the session, cost, and the registration action. Evidence: the review page compared with the source sheet. Reviewer: the producer. Decision point: content review before visual polish.

P2: Interaction requirement. The registration action leads to the approved destination, with the expected event selected when the destination supports that behavior. Evidence: a complete test of the agreed registration path using an appropriate test method. Reviewer: the delivery owner. Decision point: pre-release review. Avoid creating real registrations or sending test messages to attendees unless the team has authorized that test.

P3: Layout requirement. The page works in the named browser, device-width, zoom, and keyboard checks in the project test plan. Evidence: a short record of the checks and any open defects. Reviewer: the developer or designated tester. Decision point: pre-release review. This row points to a defined test plan; the phrase “works everywhere” would create an unlimited and unverifiable obligation.

P4: Hierarchy judgment. The first section should make the event's purpose understandable before the reader encounters decorative detail. Evidence: the composed page with realistic copy, reviewed at the intended widths. Reviewer: the creative lead and content owner, with one named final approver. Decision point: layout review.

The page's eventual registration rate is tracked separately. If registrations are low, the team can investigate the offer, audience, traffic source, usability, and content. A result alone does not reveal which deliverable failed or whether the initial approval decision was careless.

Worked approval matrix: the illustration set

I1: Asset requirement. Deliver three original illustrations covering arrival, guided repair, and taking the item home, in the agreed editable and export formats. Evidence: the asset package and file inventory. Reviewer: the delivery owner. Decision point: handoff review.

I2: Consistency judgment. The three scenes share the approved palette, stroke treatment, level of detail, and character proportions while remaining distinguishable at their intended display sizes. Evidence: a contact sheet and the illustrations placed in their actual layouts. Reviewer: the creative lead. Decision point: style-frame review and final set review.

I3: Meaning judgment. The repair scene shows participation with a volunteer rather than a drop-off service. The final scene should not imply a guaranteed successful repair. Evidence: the sketches reviewed against the approved offer. Reviewer: the producer and creative lead. Decision point: sketch review, before finishing the artwork.

I4: Production requirement. References, licensed components, and any generative tools used in production are documented according to the project's agreed policy. Evidence: a concise provenance record and any required permissions. Reviewer: the person responsible for that policy. Decision point: before final approval. A filename or an “original” label alone is not evidence that a rights review occurred.

Compare the decision types side by side

Mark each detailed record pending, accepted, or changes required only after its evidence has been reviewed. In this fictional summary every decision remains pending. A checkmark on a mood board is not an approval record.

Review the riskiest decisions while they are cheap to change

Place each criterion at the first stage where it can be judged fairly. A sketch can reveal the wrong promise or an unsuitable scene. It cannot prove that a final export has the correct settings. A rough cut can reveal the story and pacing. It should not be rejected because an unfinished placeholder graphic lacks final polish.

The Design Council's Double Diamond describes an iterative process of exploring a problem, defining it, developing alternatives, and delivering a solution. The practical implication for this approval method is to leave room for learning before treating every choice as fixed. A review should be appropriate to the maturity of the work.

For Open Bench, approve the offer and key facts first, the storyboard and illustration sketches next, the rough cut and page layout after that, and the delivery details last. This order is an example, not a required number of review rounds. The important point is to settle a high-impact meaning problem before finishing several assets that repeat it.

Translate feedback into a decision or a test

When someone says “It needs more energy,” ask which moment feels slow, what the audience needs to understand there, and what evidence would show improvement. The answer may be a shorter opening, more visible activity, or a clearer line of copy. Faster music is only one possible response.

Use this feedback pattern: identify the deliverable and moment; name the criterion affected; describe the observed problem; propose a direction or ask for options; name who decides. For example: “At 00:06, we still have not shown anyone repairing an object. V4 asks the opening to establish the activity. Please explore starting with the hands-on shot, then bringing in the event title.”

Distinguish a required correction from a suggestion. A misspelled venue name has one straightforward acceptance issue. A preference for a different shade of blue may be an optional creative suggestion, an existing brand requirement, or a newly introduced constraint. Resolve which one it is before the team treats it as an instruction.

Handle changed requests without rewriting history

A late request may be reasonable. Suppose the organizer adds a second venue and asks for a version of every asset for each location. Record it as a change: what is added, which approved work is affected, what information is needed, and how the cost or delivery date changes. Do not pretend it was part of “all final assets” from the beginning.

For a smaller change, use the same logic without unnecessary ceremony. Replacing a supplied date before exports may be easy; replacing it after a scheduled campaign has begun can touch many files and destinations. The size of the edit on screen does not determine the size of the work.

Keep one current approval matrix and retain prior versions. Name a final approver for each decision area and a person who resolves conflicting feedback. A group can contribute useful observations, but the creator still needs one clear direction when comments disagree.

A final check before work begins

Read the criteria with the people who will create and approve the work. Ask them to identify anything they could interpret differently. Replace “high quality” with the relevant production checks and review questions. Replace “all formats” with a list. Replace “approved by the team” with an accountable decision-maker.

Then confirm that the criteria leave enough creative room to solve the problem. If every shot, word, and visual detail is fixed without a reason, the brief may be dictating a solution before exploration. Keep genuine requirements firm and make provisional preferences visible.

The useful acceptance matrix is short enough to consult during a review and specific enough to settle a disagreement. When the deliverable is ready, the team should be able to point to the work, the evidence, and the recorded decision, rather than trying to remember what “premium” meant at the kickoff.