A drop shadow or bevel with no real meaning still adds edges the eye has to sort through

What it is

Perspective, bevel, and drop shadow interfere with reading a control's state when they carry no real control or spatial meaning: these effects generate extra edges and luminance variation on the graphic, and that edge-and-luminance information is easily misread as state information — the same button can appear to be in a different state simply because it sits on a different background color.

Why it happens

Shadow, highlight, and simulated depth occupy the same visual channel that state color relies on — perceived area, edge sharpness, light-and-dark layering — a channel that could otherwise be reserved exclusively for whether an object is pressed, enabled, or occluded by something else. Once decorative depth effects use the same visual cues, an operator cannot tell by sight alone which light-and-dark pattern is a real state and which is just art direction. A typical conflict: a shadow is routinely read by the visual system as "this object sits above its surroundings" or "this object has been pushed down." If that shadow is only the interface's default style and does not correspond to an actual pressed/released state, the operator mistakes the decorative default for a real state change. Making everything flat is not the goal here; the actual requirement is that every visible difference maps to exactly one meaning — no single visual effect should be doing double duty as "looks nice" and "this is a real state" at once.

Where it stops holding

In scenarios with a genuine spatial relationship — showing the mechanical assembly position between pieces of equipment, or whether an operator can physically reach a given layer — depth cues carry task-relevant information and are not purely decorative; they should not be removed along with everything else. Stripping out decorative shadow must also avoid erasing a control's legitimate boundary line and keyboard focus indicator, since these depend on the same outline and contrast; flattening every boundary in pursuit of a flat look can leave operators unable to tell which region is actually clickable. The test for whether a depth effect should stay is whether it maps to a task meaning, not whether it looks modern or polished.

Applying it

List every existing three-dimensional, shadow, or gradient effect in the interface and note what state or spatial relation each one is meant to represent; drop any that map to nothing, or that conflict with another state code such as color or blinking, and replace them with an outline, a text label, or an explicit on/off icon instead. After replacing them, test the same control on both a light and a dark background, and on an older display with reduced brightness or contrast, to confirm the operator can still reliably read its current state without being thrown off by the background change.

Related

• Same group: Y3.12.1 Low-saturation background for anomaly salience · Y3.12.2 Reserve high contrast for action · Y3.12.3 Salience saturation
• Nearby: Y3.03 Color and coding conventions · Y3.04 Information density of the display
• Search terms: skeuomorphism · flat design · state coding · visual clutter