Practical guide

A Practical System for AI-Assisted Communications Deliverables

AI-assisted communications work is not one generic writing task. A decision memo, service notice, executive update, public explanation, and internal change announcement have different audiences, evidence burdens, and failure modes. A useful communications system therefore begins with the reader action and the source record, then chooses an artifact shape. It does not begin by asking a model to.

By Two Prune

AI-assisted communications work is not one generic writing task. A decision memo, service notice, executive update, public explanation, and internal change announcement have different audiences, evidence burdens, and failure modes. A useful communications system therefore begins with the reader action and the source record, then chooses an artifact shape. It does not begin by asking a model to “make this sound professional.”

Route the work by communication job

Before drafting, classify the deliverable by the change it should produce. Informing helps a reader understand a fact. Instructing helps a reader complete an action. Persuading presents a recommendation and tradeoffs. Coordinating assigns owners and timing. Recording preserves a decision and its rationale.

Then define audience, channel, required action, deadline, evidence sensitivity, approver, and failure consequence. The same source material may need different outputs. A service outage notice should lead with impact and immediate action. A post-incident review needs sequence, cause evidence, and corrective ownership. Combining both into one polished essay serves neither reader.

Digital.gov’s plain-language guidance recommends clear audience-specific writing, short sections, active voice, and key information near the top. Its design guidance explains how headings, lists, and page organization support understanding (writing for understanding, design for understanding). These are useful editing standards, not evidence that a message achieved its outcome.

Sources: [1] [2]

Create a claim and action ledger

Build a small ledger before prose. Each row contains a proposed claim, source, source date, owner, confidence, sensitivity, and whether the claim may be published. Add a parallel action row with actor, action, deadline, route for questions, and confirmation method.

Ask AI to identify unsupported claims and vague actors. “The issue has been resolved” needs operational confirmation and a defined scope. “Teams should update soon” hides both responsibility and timing. The model may suggest clearer language, but an authorized owner must confirm facts and commitments.

Worked artifact: operational change notice

Suppose a synthetic operations team will retire an internal upload route. The verified facts are: the old route closes on 18 October, existing files remain available, new uploads move to a named workspace, and the service desk owns access questions. The communication job is instructing.

The artifact uses this sequence:

The claim ledger links the date to the approved change record, availability to the migration test, and support route to the service desk owner. The action ledger gives each step an actor and date.

A failed version opens with “We are excited to announce a transformative platform enhancement.” It delays the reader’s task and makes an unsupported value claim. Repair it by leading with the concrete change and verified consequences.

  • What changes: New uploads move to the Workspace Library on 18 October.
  • Who is affected: People who currently upload evidence through the legacy form.
  • What to do: Finish in-progress uploads, bookmark the new route, and test access before 15 October.
  • What stays the same: Existing files remain available under the current retention policy.
  • Where to get help: Contact the service desk with the project ID and an access screenshot.

Adapt without fragmenting the truth

Create a canonical fact sheet, then adapt tone and length by channel. An email may include context; an in-product notice may contain only impact, date, and link; a manager brief may add questions and escalation. Do not let channel variants develop conflicting dates or promises.

Keep accessibility in the review. Digital.gov’s content guidance advises defining unfamiliar terms, avoiding idioms, and testing content as part of the process (accessibility for content designers). Human review is still needed because automated checks do not resolve factual or contextual ambiguity.

Sources: [3]

Release checklist

This system improves traceability and clarity. It does not prove that a message changed behavior; that requires separate delivery and outcome evidence.

  • The first lines state the reader-relevant fact or action.
  • Every external claim maps to an approved source.
  • Actors, dates, and channels are explicit.
  • Channel variants use one canonical fact sheet.
  • Sensitive or uncertain details are excluded or clearly qualified.
  • Links, contact routes, reading order, and accessibility are checked.
  • The accountable owner approves commitments before release.

Sources

  1. 1.writing for understanding · U.S. General Services Administration
  2. 2.design for understanding · U.S. General Services Administration
  3. 3.accessibility for content designers · U.S. General Services Administration

Related resources