The cost of providing the non-gesture path should be counted in the overall cost of the gesture design

What it is

If selection counts only recognizer, camera, and vocabulary, and treats buttons, remotes, and synchronized state as “we would have had those anyway,” the mid-air scheme is underpriced. The non-gesture path’s cost belongs on the gesture scheme’s ledger: extra UI, extra tests, extra teaching, all paid because you chose gesture. That is not the same comparison as “is gesture a better fit for this task than buttons alone”—that is fit. This is: once you chose gesture, the bill still adds the spare channel; that line must not be quietly booked to “platform infrastructure.”

Why it happens

Visible costs of a gesture scheme are the sensor and the model. Hidden costs include equivalent controls per command, state sync across two paths, discovery and teaching on failure, accessibility acceptance, and one more thing that can break on site. A project that justifies gesture by “we can skip buttons” will add the buttons back later without revisiting the economics, and then pays for both a recognizer and a full touch UI. Once the ledger is honest, some tasks revert to not being gesture-primary, or gesture shrinks to a flourish. A scheme that omits spare-path cost looks light in a demo and heavy in maintenance.

Studying it

Make two cost tables for the same product: gesture pipeline only, versus gesture plus equivalent path, sync, tests, and docs. Compare them to actual hours. Interview the team on whether “the button was added for gesture failure or would have existed anyway,” to see how hidden lines get classified. Trace an early argument that “we will skip touch” against the touch surface that still exists later. This is an observation in design economics, not a recognition-accuracy experiment; the sample is projects, not trials.

Where it stops holding

When the platform already mandates a system-level alternative (an OS switch, a standard remote protocol), incremental cost on the app side drops, but sync and discovery still cost. A research prototype may not build the spare to product grade; the paper should state the scope so it is not read as the cost of a complete scheme. Tooling cost of a hardware button is mostly once; model updates for software gestures are ongoing. The ledger’s time window has to be stated, or capital and operating spend collapse into one number.

Applying it

• In the project brief, write equivalent path, sync, and dual-path tests as mandatory lines of the gesture scheme, not as “if we have spare effort.”
• If the total still exceeds doing the task as buttons only, return to the fit discussion rather than adding more gesture features.
• In a retrospective, list UI that “we thought we would skip, then built.” Each item is uncounted total cost.

Related

• Same group: C4.28.1 Any function carried by a mid-air gesture needs a non-gesture equivalent path · C4.28.2 The non-gesture path serves recognition failure, fatigue, and bodily difference among other failure modes · C4.28.3 The non-gesture path cannot be buried deeper than the gesture path, or it exists only in name
• Adjacent: C4.01 Definition and fit of mid-air gestures · C4.05 Three dimensions of gesture evaluation
• Search: total cost · hidden UI · gesture plus fallback