Quick answer: A feature graphic is a single image that announces one capability and shows what it does. It is the most useful repeatable asset in a launch week: it works in the feed, in the product update post, in the release email, and in the changelog.

The four elements

Every feature graphic needs:

  1. The label. A small category line, usually "New" or the feature family name.
  2. The headline. The feature name, or the outcome in a short sentence.
  3. The proof. The screenshot, a short diagram, or the steps.
  4. The brand. The logo and the handle, kept small and constant.

Everything else is decoration.

The three layouts that work

The proof-first card

The screenshot occupies 60–70% of the frame. The headline sits on the top band, the label above it. This is the default when the feature is visible — a new panel, an export button, a new view.

The steps card

A numbered three-step flow. Used for features that are a process: "Import, map, export." This works because the viewer sees the mechanism instead of trusting the claim.

The comparison card

A two-column before and after. Used for features whose value is the removal of a chore: "Before: seven exports and a zip. Now: one click."

The headline patterns

The headline should name the feature or the outcome, not the marketing:

  • Weak: "Introducing the next generation of our platform."
  • Strong: "Export the whole workspace to a PDF."

The reliable patterns:

  • The verb phrase. "Turn one paragraph into a deck."
  • The job-to-be-done. "Resize for every platform in one pass."
  • The removal. "No more manual layout."
  • The number. "Eight social assets from one source."

The hook writing guide and the CTA guide cover the phrasing.

The screenshot rules

The screenshot is the proof; treat it carefully:

  • Use a clean, framed capture; the app screenshot guide and device frames set the standard.
  • Add at most one annotation, pointing at the new element.
  • Make the screenshot large enough to see at phone size.
  • Remove unrelated tabs and personal data.
  • Do not fake a screen that does not exist — the feature fact-check applies to graphics too.

The visual hierarchy

  • The headline is the largest type, around 72–96 px at 1080 wide.
  • The label is a small uppercase pill.
  • The outcome line is roughly half the headline size.
  • The logo is a footer element; it never competes.
  • The accent color appears once, on the thing the feature is about.

The dimensions

  • The feed default: 1080×1080 square or 1080×1350 portrait.
  • The X or LinkedIn link card: 1200×675 or 1200×627.
  • The story version: 1080×1920.

Do not scale between them; reflow per the resize guide.

The caption that completes the image

The graphic carries the glance; the caption carries the details:

  • First sentence: what changed and why.
  • Second sentence: where to find it.
  • Third sentence: the link or the action.

The feature announcement template and the social caption guide give the full pattern.

The production path

  1. Write the feature in one plain sentence.
  2. Capture the screen or sketch the steps.
  3. Choose the layout (proof, steps, or comparison).
  4. Set the headline and the label.
  5. Generate the feed version first.
  6. Reflow the story and the 16:9 versions.
  7. Review the proof against the shipped product.
  8. Post with the caption.

A campaign generator can produce the feature card and the related variants in one pass; a tool such as Neatico takes the plain feature description and generates the card set with the screenshot and the platform-specific captions.

What to avoid

  • Labeling the image with the internal codename instead of the shipped feature name.
  • A screenshot without the new element visible — the viewer cannot find the news.
  • Five colors, three fonts, and a tagline war on one card.
  • A headline that promises a capability the release does not include.
  • Posting the same graphic for every feature; the layouts should vary across the campaign.
  • Forgetting the in-product announcement; the release notes and the update post keep the existing users informed.

Frequently asked questions

Does every feature need a graphic? Every user-visible feature deserves at least one. Internal improvements and bug fixes belong in the text changelog.

One graphic per feature or a combined set? The headline feature gets its own card; two or three smaller changes can share a list card. The changelog visual guide covers the set.

Should the graphic include a screenshot? When the feature is visible, yes — proof beats abstraction. A conceptual card is the right choice only when the feature is invisible (infrastructure, speed, or security).

How long does it take to make one? With a clean screenshot and one sentence, a first version takes minutes. The review, not the design, is the real cost.

Name the change, show the proof, and give the reader one action. That is the whole feature graphic.

Related guide: the screenshot marketing guide.

Related guide: the product demo video guide.