Crossing lines break the readability of a relationship
Aliases: edge crossing · line crossing
What it is
In any display that uses lines to show relationships — node-link diagrams, flowcharts, connector lines pointing between controls — every crossing between two lines makes it noticeably slower and more error-prone to tell whether two given things are actually connected. This is a different problem from how dense or busy a drawing looks: a diagram with many lines that never cross is typically far more readable than one with fewer lines that cross often.
Why it happens
Telling which two endpoints a line joins requires continuously tracing its path — an attention-demanding, step-by-step process, not something read off as a single global impression. Without a crossing, tracing just follows one unbroken path to the end. At a crossing, tracing arrives at a point with two possible directions to continue in, and resolving which one to follow requires comparing direction, curvature, or line style right at that intersection — every crossing adds one more of these local judgments on top of the tracing task. That is exactly why crossings hurt readability more than mere density does: density just means more lines to trace, while a crossing makes the tracing of any single line uncertain at that point.
Studying it
Graph-drawing readability research typically takes the same set of nodes and the same relationships and re-lays them out, producing several versions that differ only in crossing count while carrying identical information. Participants then perform tasks like judging whether two named nodes are connected or finding a path between two points, with completion time and error rate recorded as a function of crossing count. This line of work repeatedly finds crossing count to be one of the strongest layout predictors of task performance — more crossings mean longer completion times and higher error rates, and the effect is observable even at modest crossing counts, well before a drawing becomes extremely dense.
The key to this manipulation is holding node count, edge count, and the underlying information constant, and changing only the crossing count through re-layout — which is what lets the readability difference be attributed to crossings themselves rather than to the number of relationships or the diagram's overall scale.
Where it stops holding
This finding mainly applies to displays that use lines to show relationships — node-link diagrams, connector lines linking controls in an interface. When the total number of relationships is very small (say, only two or three lines in the whole display), the damage a crossing causes is correspondingly small, and it is not worth sacrificing other layout goals just to remove one or two crossings.
If the lines already carry distinguishable styling (different colors, weights, dashing), judging direction at a crossing becomes considerably easier, and the damage is noticeably lighter than when same-colored, same-weight lines cross — exactly how much lighter depends on how distinct the styles are, and cannot be generalized from a single case.
Applying it
- Reduce crossing count first by re-arranging node positions, switching to orthogonal or curved routing, or merging lines that share a start or end point (edge bundling) — rather than keeping the existing layout fixed and simply expecting users to trace patiently through it.
- When crossings cannot be eliminated entirely, give the lines distinguishable styling (color, weight, dashing) to lower the chance of misjudging direction at each crossing point.
- To verify: pick a specific connected pair of nodes and ask someone unfamiliar with the diagram to point out the line between them, recording time and whether they get it right. Testing several layout versions with different crossing counts this way turns the time and error differences into the actual readability cost that layout is paying.