Diagram Altitude
The level of abstraction a diagram commits to, and the rule that mixing levels in one picture makes it useless to every audience.
The most common defect in architecture diagrams is not ugliness, it is inconsistent altitude: a single picture showing a business capability next to a Kubernetes pod next to a specific database table. Each element is correct, and the diagram serves nobody, because no audience operates at all three levels simultaneously.
The discipline is one diagram, one altitude, one audience, one question. The C4 model is a useful scaffold for this precisely because its levels are explicit — context for who uses the system and what it depends on, containers for the deployable units, components for the inside of one container, code for the rare case where it helps. Each level is a separate diagram with a different reader.
The supporting habits that matter as much as the level. Label the arrows with what flows and in which direction, since an unlabelled line between two boxes conveys almost nothing. State the diagram's question in the title — "how a payment request traverses the system" rather than "architecture". Include a legend if shapes or colours carry meaning, and if they do not, do not use them decoratively. And keep the element count in the range a person can hold — roughly nine or fewer per diagram, with detail pushed to another one.
The test before publishing: name the audience and the decision this picture supports. If neither is specific, the diagram is documentation of the author's mental state.