A diagram for a report feature shows a Reports API box, a Renderer box, and an arrow labeled generate between them. One engineer expects the API to wait for the rendered file before replying. Another expects it to accept a job and let the renderer work later. Both can point to the same arrow.

This is a fictional system. The disagreement matters because the two readings give the person requesting a report different answers. If rendering takes longer than the request can wait, does the person see a failed request, or a pending report? The drawing has named the components without saying what the connection does.

The missing meaning is on the arrow

The first engineer reads Reports API → Renderer as a request made while the browser waits. In that reading, the API calls the renderer, receives a file or a failure, and only then answers the browser. The arrow is a runtime call. Slow rendering holds up the response.

The second engineer reads the same arrow as responsibility for a background job. In that reading, the API accepts a report request, records work for the renderer, and answers the browser before rendering finishes. The arrow says which component handles the work, but it does not show the route the work takes. A queue or durable job store may be part of the design even though it is absent from the picture.

Neither reader is being careless. Generate names an intention, not a communication method or a response boundary. An arrowhead suggests direction, but it does not say whether the API calls another service, publishes work, or merely depends on it. The layout may reinforce either story. Put the boxes close together and a reader may see a direct call; label the drawing "report pipeline" and another may expect stages of background work. Those cues are useful only when the author applies them consistently.

Marian Petre's 1995 paper on graphical programming describes how readers use learned conventions and layout cues, which she calls secondary notation, alongside the formal marks. Her observations concern graphical programming and expert and novice readers, not measurements of architecture teams. They help explain why a familiar looking arrangement can invite different inferences when its conventions are unstated.

Rewrite the view for the question it must answer

Suppose the intended design is background rendering. The author can revise the small view so the first engineer no longer has to infer that choice:

Browser -- request report --> Reports API
Reports API -- records job --> Report jobs
Browser <-- accepted; report pending -- Reports API
Renderer -- claims pending job --> Report jobs
Renderer -- saves finished file --> Report storage

Here Report jobs is a durable place for pending work, and Report storage holds finished files. The line back to the browser is as important as the line to the renderer. It says the immediate answer is "pending," not a completed file. The author can add one sentence under the drawing: "This view shows the immediate response and the route to a finished report; it omits job retries, access control, and how the browser learns that the file is ready." That sentence prevents the clean path from posing as a complete production design.

The revision also exposes a design question. If the API tells the browser "accepted" before the job is safely recorded, a crash can leave the person waiting for a report that nobody will render. The drawing alone cannot settle how the API makes that promise. It can, however, put records job before accepted in the intended sequence and mark the guarantee for separate design work. More boxes would not repair the original ambiguity if the arrows still said only generate.

Try the edit on a small diagram in Lycana. Replace generate with the job-recording path and add the immediate response to the browser. Then ask someone what the response promises before you explain it aloud. The answer tests the labels, not the job store's reliability.

If the intended design were a direct call instead, the honest revision would be smaller: Reports API -- requests file and waits --> Renderer, followed by a labeled result back to the API and a note about what the browser sees on timeout. The two revisions are not interchangeable visual styles. They describe different behavior.

Larkin and Simon's 1987 analysis of diagrams and text gives a useful way to judge the revised view. In the mathematics and physics problems they analyzed, a diagram could place task-related information together and reduce the search needed to use it. That is a task-specific representational advantage, not evidence that any diagram makes an engineering team faster or more accurate. In this report example, the task is to find the response boundary. Showing the browser's immediate answer beside the job route makes that boundary available to inspect; an unlabeled arrow leaves the reader to supply it.

The amount of detail should follow the question. A component inventory might reasonably show only that Reports uses Renderer. A view meant to explain what happens after someone clicks "Generate" must say whether the response waits and where the unfinished work lives. Before trusting either version, ask a reader to describe the immediate response using only the marks and caption. If they need the author's private convention, the drawing still has two stories in it.