An Arrow Is a Claim: Explaining Dependencies on a Technology Diagram

A planning slide has boxes for three projects and arrows between them. One reader sees order: A happens before B. Another sees information flowing from A to B. A third sees a team supporting both.

The diagram looks simple because the words have been removed. That does not necessarily make its meaning simple. An arrow is a claim about a relationship, and the reader needs to know which relationship.

TLDR

• An arrow can mean sequence, information flow or another relationship.

• Use one meaning consistently or distinguish meanings explicitly.

• An invented example can reveal an ambiguous convention.

• A diagram explains a plan; it does not establish that the plan is feasible.

Write the relationship as a sentence

In a fictional project, a draft glossary comes before a reader review. The sentence is "The review uses the glossary draft." An arrow could express that relationship, but the wording tells the audience what the arrow means.

Compare that with "The glossary comes first." Does it have to be finished before review can begin, or is that simply the order used in this example? The difference belongs in the explanation rather than in the reader's imagination.

Give the convention a small legend

A short legend might say "Arrows show documents used by the next activity." That is not the only possible convention. It is a clear one for this fictional illustration.

If another kind of relationship matters, give it its own explanation. Adding different colors without explaining them merely replaces one ambiguity with another.

Keep the picture and the prose aligned

Google's audience guidance asks writers to account for what the audience does not already know. The diagram's visual convention is part of that missing knowledge, especially for a colleague seeing the project for the first time.

Read the diagram back as sentences. If the prose says two reviews can happen independently while the picture draws one as feeding the other, the explanation disagrees with itself.

This check concerns the clarity of the diagram. It does not validate timing, staffing or the project sequence. An understandable representation and a workable plan are different claims, and a useful slide does not confuse them.

Sources for the definitions and writing principles discussed here: Google, Technical Writing One: Audience, last updated March 28, 2025. The examples and suggested discussion formats are illustrative.

Frequently asked questions

Must every arrow have a label?

Not always. A clear shared convention or legend may be enough. Label the relationship when the convention is not obvious.

Can a diagram show uncertainty?

Yes. Explain which relationships are established and which are still questions rather than making them look identical.

Is this project scheduling advice?

No. It is advice about explaining relationships on a page, not deciding a project's timing or resources.

A practical next step

Take one arrow from a sample diagram and turn it into a sentence. If several people write different sentences, clarify the convention. Book a Decision-Clarity Call for help making technology work easier to explain.