Triaging visual-anomaly reports should rule out illusion as a non-defect cause

What it is

When a user reports "these two buttons look different sizes," "these two columns aren't aligned," or "this icon looks crooked," a team's first instinct is usually to check coordinate values, inspect rendering code, and compare against the design spec — assuming it's an implementation defect. But if multiple users independently report the same "something looks off" impression, while the actual measured coordinates, sizes, and colors match the design spec exactly, the report is quite possibly not an implementation error at all — it may be that the interface happens to contain a geometric-illusion-inducing structure that the visual system reliably and repeatably perceives as "wrong." Ruling out illusion as a cause is a step that has to be added to how these reports get triaged.

Why it happens

Geometric illusion is worth treating as a distinct diagnostic hypothesis because it shares two traits with an ordinary implementation defect that look alike on the surface but come from an entirely different cause. First, reproducibility: the same interface configuration will reliably produce a consistently directed perceptual bias in multiple different users — it isn't one user happening to misread something once. Second, stubbornness: even after showing a user the actual coordinate and size numbers, they'll still say "but it just looks different," because the bias occurs at an early stage of visual processing that isn't affected by numeric information delivered after the fact. Together, these two traits are easy to mistake for "a real display bug": reproducibility looks like a bug that reliably recurs, and stubbornness looks like a user "seeing it but refusing to accept the correction." The key to telling them apart is the pattern of the report's content — if the complaints center on a relative judgment (size, alignment, orientation) rather than an absolute numeric error, and the measured values match the design intent exactly, illusion is a candidate explanation that deserves serious consideration, rather than defaulting to "the implementation must be off" just because the user insists something's wrong.

Where it stops holding

• This triage approach only applies when the complaints center on a relative judgment ("the size/alignment/orientation looks wrong") and the measured values match the design intent exactly. If the measured values themselves don't match the design spec, that's a genuine implementation deviation and shouldn't be waved away as illusion.
• Reproducibility on its own isn't unique to illusion — some genuine rendering defects (a rounding error at a particular resolution, say) also recur reliably for every user, so "multiple consistent user reports" alone doesn't prove illusion; the numeric check still has to come first.
• A user insisting "it still looks wrong" and refusing to be persuaded by the numbers can also mean the numbers don't fully capture the dimension the user actually cares about (for example, comparing rendered visual weight rather than geometric size). Don't equate "the user won't accept the explanation" with "the user was misled by an illusion" without first confirming both sides are discussing the same quantity.

Applying it

• When a "this looks wrong" report comes in, first verify that the actually rendered coordinates, sizes, and colors match the design spec exactly. If they do match completely, then check whether the elements involved in the report are surrounded by noticeably size-mismatched elements, dense diagonal lines, or another known illusion-inducing structure, rather than immediately assuming a rendering implementation has drifted.
• If illusion is suspected as the cause of the perceived bias, try temporarily removing or swapping out the suspect surrounding inducing elements and see whether the same users, or you yourself on a fresh look, still perceive "something wrong." If the impression disappears, that's good confirmation of illusion rather than an implementation defect.
• Once an implementation defect has been ruled out and illusion confirmed as the cause, the fix should target the interface composition itself (adjusting the relative size or angle of surrounding elements, or adding numeric reference information), rather than trying to "correct" a coordinate or size value at the numeric level that was already correct.
• Verification: take an isolated screenshot of the disputed interface region, strip away the surrounding context, and have several people independently judge "is the size/alignment off." If the dispute disappears once the context is removed, that shows the problem lies in the inducing structure formed by the context, not in the element's own implementation values.

Related

• Same group: A1.32.1 Geometric illusions show that perception is not a direct mapping of the physical stimulus · A1.32.2 Guides, borders, and shadows in an interface can unintentionally trigger known illusion patterns · A1.32.3 Size and orientation illusions bias users' alignment and comparison judgments · A1.32.4 Known illusion patterns can be deliberately used to produce an intended visual effect
• Nearby: A2 Gestalt Principles
• Search terms: illusion diagnosis · non-defect visual complaint · interface misreading