Building a Better Creative Approval Flow

Good ideas shouldn't disappear into an approval chain.

A communications team creates a thoughtful campaign for a new public service. The program director wants the headline to sound more formal. The legal reviewer flags a sentence that could be interpreted as a guarantee. An executive asks for a different photograph. A second department replies to an earlier draft with an entirely new message.

By Friday, everyone has contributed. Nobody knows which version is final.

This is not simply a design problem. It is a decision-making problem. Creative work becomes difficult to approve when the team has not agreed on what success looks like, who has authority to decide, which reviews are essential, and what a comment is supposed to accomplish.

An effective approval process protects the things that matter—accuracy, accessibility, public trust, appropriate oversight, and responsible use of resources—while making the remaining decisions easier.

This Harbor Creative field note is for municipal and public-agency communicators, nonprofit teams, project managers, and the vendors who support them. It is a practical workflow, not an official government approval standard. Adapt it to your organization's laws, policies, contracting terms, records schedules, and risk level.

Five decisions to make before the first creative draft

A better approval flow begins long before somebody opens a PDF and starts leaving comments.

Decision 1: What must this work accomplish?

Write the audience, purpose, intended action, and factual boundaries in a short brief.

For a public notice, success might mean that affected residents understand a service change, know when it begins, and can find an accessible source for updates. For an annual report, it might mean explaining verified results and finances to readers who are not technical specialists.

A design preference is not a communication objective. “Make it feel more exciting” is not a substitute for “people need to see the application deadline within five seconds.”

The U.S. Web Design System's design principles put real user needs, accessibility, trust, and listening at the center of public digital experiences. Those principles make useful criteria for reviewing creative work across formats—not just websites.

Agree on three to five acceptance criteria. For example:

• Residents can identify who is affected, what changes, and when.
• Every claim is supported by a designated source owner.
• The design follows approved brand and accessibility requirements.
• The deliverable fits its actual distribution channels.
• The approved final files can be archived and updated without confusion.

The criteria should be specific enough to resolve a disagreement, not merely describe an aesthetic.

Decision 2: Who provides expertise—and who makes the decision?

Many people may need to review a public communication. That does not mean every reviewer has the same role.

Assign an accountable content owner, a final release authority, and named specialists for factual, technical, accessibility, legal, privacy, finance, or policy matters where they apply.

Do not use “everyone has to approve it” as a substitute for identifying actual authority.

The GOV.UK publishing process illustrates a useful distinction: a draft can be sent to an independent editorial reviewer for a “second pair of eyes,” while subject-matter experts can also fact-check particular content. These are different responsibilities. See the GOV.UK review workflow.

Important: A single creative lead can coordinate decisions, but that person's approval does not override required legal clearance, procurement authority, accessibility obligations, or any other mandatory review.

Decision 3: What is being approved at each stage?

A team should not be debating headline strategy during the final printer proof—unless new evidence shows the headline is wrong.

Separate approval of the direction from approval of the facts, then from approval of the finished publication.

• Direction: Audience, message, concept, format, and selected approach.
• Content: Claims, dates, figures, program eligibility, privacy, and policy accuracy.
• Production: Final copy, layout, accessible formats, URLs, print specifications, and channel adaptations.
• Release: Confirmation that required reviews are complete and this exact version is authorized for publication.

A late factual correction is always valid. A late personal preference may need to be deferred if it is outside the approved scope and introduces avoidable risk or delay.

Decision 4: How will feedback be submitted and resolved?

Feedback should be tied to the same current version, in one known location, with a deadline and a clear standard.

A useful comment explains what is wrong, why it matters, and what would fix it. It identifies whether the issue is factual, required for compliance or safety, important for reader understanding, or simply a preference.

Ask each review lead to consolidate feedback for their group before sending it to the project owner. This does not prevent multiple subject-matter reviewers from participating; it prevents the production team from having to reconcile competing instructions across separate emails.

Decision 5: What counts as approval?

“Looks good” in a chat is not a reliable release record when multiple formats, stakeholders, and deadlines are involved.

Agree in advance that final approval identifies:

1. The specific file or version being approved.
2. The named authorized approver.
3. The date and recorded decision.
4. Any conditions or required remaining clearances.
5. The channels or formats covered by the decision.

Do not treat silence as approval unless a clearly established, authorized policy permits it for that decision. For public notices, legal disclosures, contractual deliverables, or other high-risk content, explicit sign-off is the safer default.

A practical approval map for a small public-sector team

Use this table at kickoff. The assignments are illustrative, not prescribed legal roles.

The key is not to build a complicated chart. It is to prevent two predictable failures: a reviewer making a decision they are not authorized to make, and a necessary reviewer discovering the project only at the end.

For federal contract work, FAR 43.102 specifies that only contracting officers acting within their authority may execute contract modifications on behalf of the government. A creative comment from another employee is not automatically authorization for extra paid scope. State, local, and nonprofit procurement rules differ; follow the actual contract and appropriate purchasing authority.

The four-gate Harbor review process

A structured process does not have to be bureaucratic. Four gates can give a small team clear checkpoints without creating endless meetings.

Gate 1 — Approve the brief and direction

Review package: One-page brief, intended audience, distribution plan, requirements, and one or two recommended creative directions.

Decision: Is this the right message and approach for the intended audience?

Approver: Named project or content decision-maker, with any required early stakeholder input.

Exit condition: An approved brief and selected direction. Unresolved issues and changes in scope are documented.

This is the best point to challenge an assumption. If a project is designed for an audience that may not use social media, the answer is not merely to make the social post prettier.

Gate 2 — Verify the content

Review package: Complete copy, data and source references, operational details, translations where applicable, required disclosures, and proposed images.

Decision: Are the claims accurate, current, appropriate, and ready to place into final formats?

Reviewers: Program experts and all relevant specialists.

Exit condition: Material facts verified; required changes resolved; remaining questions assigned to an owner.

Keep content review distinct from stylistic edits. When a department reports that a deadline is incorrect, that is not one opinion among many—it is a verification issue.

Gate 3 — Review the real deliverable

Review package: Production-ready web page, proof PDF, social variants, email, signage, or other formats in context, not just screenshots of an artboard.

Decision: Does the final work function as intended in every required format?

Reviewers: Editorial lead, accessibility and production reviewers, plus designated final checkers.

Exit condition: Layout, links, reading order, alt text, responsive behavior, print specifications, file names, and distribution details checked; substantive content has not drifted from the verified version.

The UK's Department for Education recommends a final “second eyes” check on content in its real production or preview environment after factual review and clearance. That is a practical model for civic teams: DfE Quality and Assurance.

Gate 4 — Authorize and release

Review package: Exact final file/version, resolved issues log, completed clearance record, and publication plan.

Decision: Is this precise version authorized to go live or go to print?

Approver: The person or role with the required publishing or sign-off authority.

Exit condition: Documented decision, controlled release, archived approved artifact, and assigned post-publication owner.

The GOV.UK model separates review from publication permissions and has a controlled exception for urgent publishing that is subsequently flagged for review. That is an example of another government's process, not a general permission to bypass requirements. See GOV.UK publishing guidance. Define any emergency route under your own agency's policies in advance.

Give feedback a shared language

One of the most useful changes a team can make is to stop treating all comments as equally urgent.

Classify every comment

A “required correction” might need a specialist to determine whether it is legally or technically required; the label is an operational triage tool, not a legal ruling.

Replace vague comments with decision-ready feedback

Instead of: “Can we make the graphic pop more?”

Try: “The registration deadline is difficult to see on mobile. Please increase its prominence without changing the approved hierarchy of the other information.”

Instead of: “Legal doesn't like this.”

Try: “The phrase ‘guaranteed approval’ is not supported by the program rules. Replace it with the verified eligibility language in the approved policy summary. Policy owner: [name].”

Instead of: “Use the other photo.”

Try: “The current image appears to show a facility that is not part of this project. Use a verified image of the actual site, or a neutral illustration clearly identified as such.”

The best feedback gives a creator the problem to solve, not only an unexplained instruction.

One version. One comment log. One source of truth.

When reviewers edit four emailed files independently, nobody can reliably say what was approved.

Establish a canonical project location and a recognizable status. For example:

Keep a short issue register with: issue number, asset/version, location, comment, category, owner, decision, action, and resolution date.

Use descriptive file names when files move outside the review system: for example, ParksNotice_Flyer_v03_CONTENT-REVIEW_2026-10-16.pdf. A date or label helps humans, but the system's immutable revision history is better evidence of the exact approved version.

Do not call a file “FINAL_FINAL_2” and assume everybody will interpret it the same way.

For public institutions, recordkeeping is more than neat project management. The National Archives' federal social media guidance explains that official social content may constitute federal records, including associated context and metadata. NARA's 2025 memorandum on third-party messaging reinforces that federal recordkeeping responsibilities can apply to official messages exchanged outside traditional email. These are federal rules; local agencies should consult their own public records, retention, and disclosure requirements. Do not assume a collaboration app automatically satisfies them.

Handle disagreement before it becomes a new round

When two reviewers give contradictory instructions, stop asking the designer to pick a side.

Try this five-step resolution:

1. Name the conflict. “Operations wants the start date in the headline; communications wants the benefit first.”
2. Identify the relevant standard. Which version helps the intended reader act? Are there legal or accessibility requirements?
3. Show the alternatives. Present no more than two credible choices, with tradeoffs.
4. Ask the accountable authority to decide. Necessary specialist clearance still applies.
5. Record the decision once. Close the issue and update the single current version.

A ten-minute decision discussion can be more productive than a long thread. That duration is a suggested facilitation technique, not a research-backed efficiency guarantee.

Reopen an approved gate only for a reason. Examples include newly discovered factual errors, changed program rules, identified accessibility problems, a newly required disclosure, or a properly authorized scope change. A new favorite color is not necessarily a reason to restart a nearly complete release.

Accessibility belongs in the review—not at the end

Accessibility is easiest to protect when designers and content owners know the requirements before drafting.

For websites and digital communications, include checks for content order, meaningful headings, understandable link text, keyboard interaction where relevant, sufficient contrast, responsive layouts, and alternatives for informative imagery. For PDFs, validate document tags, reading order, tables, and text alternatives as applicable.

The W3C Web Accessibility Initiative states that automated tools cannot by themselves determine accessibility conformance; knowledgeable human evaluation is required. Section508.gov's PDF guidance likewise stresses accessible source documents, testing, and considering more accessible digital-first formats.

Make accessibility a role in the project, not a box that an untrained reviewer is expected to tick after a software scan.

Language access, plain-language review, privacy, photography permissions, and culturally appropriate messaging may also need named review responsibilities depending on the audience and the work.

A fictional city campaign: from comment chaos to a decision trail

Imagine a fictional city preparing a neighborhood recycling-schedule announcement. The deliverables include a postcard, an email, a website update, and social graphics. The change is planned but not yet public.

Without a defined flow: Public Works edits the postcard; customer service changes the call-to-action; the executive team comments on an old PDF; and the social media post goes out with a date that was revised after the first review.

With a defined flow:

• Monday — Direction gate: Communications approves a brief: households in the affected collection zone must understand their new pickup day and where to verify their address.
• Tuesday — Content gate: Operations confirms routes and dates from the authoritative schedule; customer service checks the phone script and lookup experience; language-access requirements are reviewed.
• Wednesday — Production gate: One current proof is reviewed across postcard, email, page, and social. A tester checks the address lookup and mobile versions; an accessibility reviewer verifies the required features.
• Thursday — Decision gate: The authorized publisher signs off on the exact files. Communications checks that all channels match, releases the announcement, and retains the approval trail.

The schedule and details are invented to illustrate the model. No actual city, recycling program, approval time, or result is being reported. In practice, schedule enough time for the reviews and public-notice requirements your organization needs.

Four templates you can copy into your next project

Template A — The one-page creative approval brief

Project: [Name]

Project owner: [Name and contact]

Audience: [Who must understand or act?]

Communication objective: [What must change for the reader?]

Core message: [One plain-language sentence]

Required facts and sources: [Dates, numbers, policies, source owners]

Non-negotiables: [Required wording, privacy, accessibility, branding, compliance]

Deliverables and formats: [Exact list of outputs and sizes]

Out of scope: [What is not part of this request?]

Reviewers and responsibilities: [Who reviews what?]

Final publishing authority: [Name or role]

Review gates and dates: [Direction / content / production / release]

Success test: [How will the team know the deliverable works?]

Template B — Review invitation

Subject: Review requested — [project] — [version] — due [date/time]

You're reviewing the [direction/content/production] stage of [project].

Current version: [single review link or file identifier]

What needs your attention: [specific facts, decisions, or risks relevant to this reviewer]

Already approved: [items that are not being reopened in this round]

Feedback due: [date, time, and time zone]

Please add comments directly to the current version. For each requested change, identify what needs to change, why, and whether it is a factual or required issue, an important improvement, a preference, or a new request.

If you cannot complete the review by the deadline, let [owner] know. Silence will not be treated as formal approval.

Thank you. We'll consolidate feedback, resolve conflicts with the appropriate decision-maker, and issue the next controlled version.

Template C — Comment and decision log

These are fictional sample entries. A language-access need must not be dismissed merely because it changes the initial scope.

Template D — Approval-of-record note

Project: [Name]

Final version / file identifiers: [Exact version numbers, links, or document IDs]

Formats covered: [Website / print / email / social / other]

Completed required reviews: [Names, roles, dates, and evidence]

Open conditions: [None, or clearly stated conditions and owners]

Approved for: [Specific publication or production action]

Authorized approver: [Name, role, recorded approval date/time]

Release owner: [Name]

Archive / record location: [Approved repository]

Post-release contact: [Person responsible for corrections and updates]

The record should distinguish “approved subject to conditions” from “ready to release.” Do not publish until any conditions that block release have actually been resolved.

The Harbor Creative Approval Flow Checklist

Use this from kickoff to release. The checklist below is an original Harbor working tool, not a formal government certification or a replacement for required review procedures.

A. Before creative begins

• The audience and intended action are stated clearly.
• A named project owner is accountable for coordination.
• The communication objective and acceptance criteria are approved.
• Required deliverables, formats, and channels are defined.
• The reporting, program, or policy facts have named source owners.
• Brand, accessibility, language, privacy, and legal requirements are identified.
• Contract scope and any purchasing approval boundaries are understood.
• The approval authority and mandatory reviewers are recorded.

B. Direction review

• The selected concept addresses the real audience need.
• Reviewers are commenting on the same current version.
• The team knows what is in scope for this round.
• Feedback is tied to clear acceptance criteria.
• Conflicting directions are resolved by the responsible authority.
• The approved direction and remaining questions are documented.

C. Content and fact verification

• Claims, numbers, dates, addresses, and deadlines are verified.
• Subject-matter experts have confirmed their assigned information.
• Mandatory policy, privacy, legal, or procurement reviews are completed where applicable.
• Image rights, quotes, and permissions are confirmed.
• Meaningful language-access and accessibility needs are addressed.
• New requests are assessed and authorized before expanding scope.
• Corrected facts are updated consistently across all related assets.
• The content gate is explicitly recorded.

D. Production and accessibility

• The proof matches the approved content and direction.
• Actual web, mobile, print, and other delivery contexts have been reviewed.
• Links, contact details, forms, QR destinations, and action paths are tested.
• Headings, reading order, contrast, and image alternatives are reviewed.
• PDF or other downloadable formats receive appropriate accessibility checks.
• Proofreading covers all sizes, versions, and translated formats as applicable.
• File names and version identifiers are unambiguous.
• No unverified edit was introduced after technical review.

E. Final approval and release

• All mandatory clearances are recorded.
• Required corrections are resolved or formally escalated.
• The exact final version and distribution channels are identified.
• Authorized approval is explicit and preserved.
• Print, digital, social, and email files match approved information.
• The publication owner and scheduled release time are confirmed.
• The approved files, substantive decisions, and relevant messages are retained under applicable policy.
• A post-publication correction contact and process are assigned.

Measure whether the process is getting better

Do not invent a “50% faster” success story or adopt somebody else's benchmark without supporting data. Establish a baseline in your own team.

Four useful measures are:

• Review cycle time: Calendar or business time from a complete review request to a recorded decision, by gate.
• Revision rounds: How many distinct consolidated review cycles occur before approval?
• Late-stage rework: How often does a previously approved decision have to be reopened, and why?
• Post-release corrections: What factual, accessibility, or production issues escaped the process?

Review the trends together. Fewer rounds are not inherently better if they result from suppressing essential scrutiny. A slower review may be appropriate for a legally sensitive notice or a complex multilingual publication.

An additional qualitative question is worth asking: Did each reviewer know exactly what decision was expected of them? If the answer is no, improve the brief before adding another software tool.

Better creative approval means clearer responsibility.

Good review processes make room for different kinds of expertise without making every decision a committee debate.

Start with the five decisions. Give the team a brief, specific review gates, one canonical version, a shared language for comments, and a genuine approval record. Protect essential checks for public accuracy, access, and accountability. Then let the creative team solve the problems it was hired to solve.

The goal is not to remove oversight. It is to make oversight useful—and make the final work better for the people who receive it.

Research and further reading

This field note synthesizes public guidance and applies it to a Harbor-designed workflow. The five decisions, four gates, templates, checklist, sample case, and suggested metrics are original practical recommendations, not requirements imposed by the referenced organizations.

• U.S. Web Design System — Design Principles: user needs, trust, accessibility, and listening as evaluation criteria.
• GOV.UK — Send Standard Content for Review: independent “second eyes” review, preview, internal notes, and separate fact checking.
• UK Department for Education — Content Quality and Assurance: constructive critique, specialist verification, and a final review in context.
• GOV.UK — Publish Standard Content: permission-controlled publishing, urgent exceptions, and post-publication review.
• W3C Web Accessibility Initiative — Evaluating Web Accessibility: continuous evaluation and why human judgment is necessary.
• Section508.gov — Create Accessible PDFs: accessible documents, testing, and digital-first alternatives.
• National Archives — Social Media Records Guidance: when U.S. federal social content and associated information may be records.
• National Archives — Third-Party Messaging Memorandum (2025): federal recordkeeping considerations for official messages.
• Federal Acquisition Regulation 43.102: who can authorize modifications to federal government contracts.

Editorial note: This guide provides general process and communications guidance. It is not legal, procurement, records-management, accessibility-conformance, or contracting advice. Agencies and contractors must follow requirements applicable to their particular jurisdiction and agreement. All example people, project details, and schedules are fictional unless explicitly identified as sourced guidance.