Proposal Graphics and Action Captions, Explained

A proposal graphic does a different job than the technical diagrams you are used to drawing. An architecture diagram exists to be studied by someone who already cares. A proposal graphic exists to stop a tired evaluator mid-skim, deliver one point in a few seconds, and bank it with a caption, often for a reader who is not technical. If you have been asked to produce the figures for a proposal, you are the right person for it, because you understand the work better than anyone. The shift to make is from drawing what the system looks like to drawing why your approach wins.

This is one place a technical contributor has a real advantage, if you use the medium the way evaluators actually consume it.

Evaluators skim, and graphics are what they skim

The senior people who influence a selection often do not read a proposal front to back. They skim, and what stops them is the visuals. They look at the graphics that stand out, read the captions, headings, and highlight statements, and form an impression before they have read a paragraph of body text. Shipley’s guidance, the closest thing the industry has to a standard, cites research that evaluators retain far more of what they see in a graphic than what they read in prose, and more still when a point is both shown and stated.

Two consequences fall out of this, and both run against a technical writer’s instincts. First, a proposal that is a wall of dense text with a few decorative pictures is throwing away its highest-bandwidth channel. Second, the old excuse that “our evaluators are engineers, they just want the facts” gets it backward. Graphics done well are the facts, delivered faster. A reader should be able to flip through your section, look only at the graphics and their captions, and come away knowing why you should be selected.

The action caption is where the points live

Here is the single highest-leverage habit in proposal graphics, and the one most often skipped. The caption under a graphic is not a label. It is where you state your point, because a skimming evaluator reads it more closely than any sentence in the body. A label wastes that attention. An action caption uses it.

An action caption is one complete sentence that ties a feature of the graphic to a benefit the customer cares about. Watch the same org chart caption move from wasted to working:

• Label: “Figure 3. Proposed program organization.” An evaluator can already see it is an org chart. This tells them nothing they did not know.
• Better: “Figure 3. Our structure gives the government a single, empowered program manager as its primary point of contact.” Now the caption states a benefit.
• Action caption: “Figure 3. Our structure gives the government a single, empowered program manager as its primary point of contact, enabling decisions in hours rather than days on urgent requirements.” Feature, benefit, and why it matters to the customer, in one sentence an evaluator will actually read.

Write the caption to carry the point even if the graphic is never studied, and work the solicitation’s own requirement language into it so an evaluator screening for keywords finds the match. On many procurements the first-pass reviewers are junior staff checking that each requirement is addressed, and a caption that echoes the requirement is doing compliance work and persuasion work at once.

The graphic has to stand on its own

A good proposal graphic passes a blunt test: a reader gets its message in a few seconds, without reading the caption, and without being a specialist. That last part is where technical contributors most often go wrong. Almost every evaluation board includes members who are not technically current, and a graphic that is obvious to you can be noise to them. If a non-technical evaluator cannot follow it, you have lost the points they control.

The fixes are mostly about restraint:

• One graphic, one message. If a figure is making three points, it is making none of them clearly. Break a dense diagram into a simple summary graphic plus detail, rather than one overloaded picture.
• Minimize text inside the graphic. Put the words in the caption, not crammed into the figure. The image carries the concept, the caption carries the argument.
• Simplify ruthlessly. Clarity beats polish, and it beats completeness. A clean process flow that a program manager grasps at a glance outperforms a precise engineering diagram that only you can read.
• Introduce every graphic in the text before it appears, and number figures in order, so the reader is never hunting for what a figure refers to.

Types that earn their place

Most federal proposal graphics describe a process or a structure. A useful prompt when you face a blank figure is to ask what the inputs are, what your approach does to them, and what results the customer gets, because that sequence is usually the picture, and the results are usually the caption. The common workhorses:

Every one of these should exist to make a point the customer needs, not to fill space. If a graphic does not respond to a requirement or sell a discriminator, it is decoration, and decoration costs page count without earning score.

Plan graphics before you write, not after

The habit that separates strong proposal visuals from afterthoughts is building them early, alongside the outline, rather than generating them the night before the deadline to break up the text. When you plan the graphic first, it forces the argument into shape: if you can draw the process that turns the customer’s problem into your result, the narrative almost writes itself, and the benefit you land in the caption becomes the point the surrounding text supports. This is the logic behind storyboarding, the Shipley practice of sketching each section’s message and visuals before drafting. You do not need to be an artist or expensive software to do this. A clear sketch a designer can polish is worth more than a beautiful graphic that makes no argument.

The compliance traps that get graphics rejected

Graphics are subject to the same Section L rules as text, and two traps catch technical contributors constantly because they come from reusing old material:

• Font rules apply inside graphics. If the solicitation requires a specific font and size for the proposal, that usually governs the text in your figures too. Drop in a reused diagram still set in the old font and you can be ruled non-compliant over a picture.
• Text shrinks when you scale. The most common graphic compliance failure is not the wrong font, it is legible text that becomes too small after the figure is resized to fit. Build graphics at the actual size they will appear, and confirm the smallest text still meets the minimum.
• Graphics count against the page limit. A figure occupies space text could have used, so each one has to be worth more than the words it displaces. This is also why an overloaded page of marginal graphics is a poor trade.

A last practical check: confirm your graphics still read when printed in black and white at actual size. Color that looks sharp on a monitor can collapse into indistinguishable grays on an evaluator’s printout, taking your message with it.

Common failure modes

• Label captions. Wasting the most-read line under the graphic on a restatement of what the figure obviously is.
• Engineer’s diagrams. A technically precise figure that a non-technical evaluator cannot decode, so the points they control go unscored.
• One graphic, many messages. An overloaded figure that buries its point under everything else it is trying to say.
• Decoration. Graphics that respond to no requirement and sell no discriminator, spending page count for nothing.
• Reused-graphic compliance misses. Old font, text too small after scaling, or color that dies in grayscale.
• Graphics as an afterthought. Generating figures at the end to fill space, instead of planning them first to carry the argument.

The one-line takeaway

Evaluators skim graphics and read the captions, so make each figure land one clear point a non-specialist gets in seconds, and put your real argument in an action caption that ties a feature to a benefit the customer wants. Plan the graphics before the prose, keep them compliant, and let them carry the story a busy evaluator will actually absorb.

The Proposal Stack is a newsletter for technical GovCon professionals who get pulled into proposal work and want to contribute well without becoming full-time proposal writers. The guides here decode the vocabulary. The newsletter covers how this plays out in practice, issue by issue. Subscribe here.