Touch, voice, and gesture lack agreed-upon constants and must be measured before use

What it is

Classic KLM constants target desktop keyboard and mouse. Touch's taps, swipes, pinches, and soft keyboard; voice's wake, recognition, and correction; gesture interaction's posture, latency, and fatigue all lack universal time constants. These inputs must have their constants measured before being used in a model. This card is where the previous four in the group land: the unit taxonomy, mental-preparation rules, blocking judgment, and constant reliability they discuss all rest on the precondition that "a reference set of constants exists" — this card's point is that, for new input methods, that precondition itself does not hold yet, and the calibration work has to start from zero rather than pretending it is already there.

Why it happens

New input methods' duration depends on degrees of freedom a desktop scenario never touches at all: touch operation has to account for the finger's own occlusion of the target, the change in usable visual area once a soft keyboard pops up, and the algorithmic correction the system applies to compensate for mis-taps — all of which make the same "swipe" gesture follow completely different timing patterns in a list, a canvas, and a map, impossible to cover with one uniform constant. Voice input's efficiency depends heavily on recognition accuracy and how the user chooses to correct a recognition error once noticed, and recognition accuracy itself swings sharply with ambient noise, accent, and microphone quality — meaning voice input's duration is not even well suited to a single constant, and is better split into two entirely separate paths, "normal recognition" and "correction after a recognition failure," modeled independently. Gesture interaction adds physical fatigue as an extra variable that barely exists in a desktop scenario — the same gesture, performed many times in a row, changes in both duration and accuracy, a dimension keyboard-and-mouse constants never considered at all. Since these factors have no place in the desktop constant system to begin with, the right approach is not to pick a seemingly similar number off the old constant table and make do, but to treat these new actions as entirely unmeasured operators and measure them from scratch.

Where it stops holding

Measuring constants yourself does not mean a large-scale experiment is required before the model can be used at all — measuring the median and rough distribution of the dominant actions with a small number of users matching the target profile is usually enough for most design decisions; rigorous calibration is genuinely needed only for scenarios meant to support an absolute time commitment. For a relative comparison between alternatives, the most important thing is keeping the measurement conditions identical across both, not chasing absolute precision on every constant — the same logic as "error should act evenly on both alternatives" from the card on constant reliability. Recognition error rate marks another boundary that deserves separate emphasis: voice and gesture input error rates should not be quietly averaged into one mean duration, because averaging makes an input method that is "usually fast, occasionally very slow due to a recognition error" look identical, on paper, to one that is "consistently a bit slow but stable" — yet the two produce completely different real experiences for the user. Recognition error needs to be modeled as its own separate path, not folded into the average.

Applying it

• First list the new input actions the target task will use, and measure the ones that genuinely dominate with five to ten users matching the target profile.
• Record duration separately for four outcomes — success, needing correction, user-initiated cancellation, and timeout — and for voice input, log recognition accuracy separately as well.
• Run sensitivity tests across different target sizes, body postures, and ambient noise levels to confirm how stable the constants are under these variations.
• How to check: whenever publishing an estimate based on these new constants, disclose the device model, system version, task content, sample size, and error range used in measurement, so readers can judge whether these constants apply to their own scenario, rather than treating a number measured under one specific condition as a universally applicable truth.

Related

• Same group: B4.12.1 Tasks are split into standard units such as keystroke, point, home, draw, mental preparation, and system response · B4.12.2 The placement of the mental preparation unit is governed by heuristic rules and is the main source of estimation error · B4.12.3 System response time counts toward the total only when it blocks the user · B4.12.4 Absolute constant values are questionable, but the differences between alternatives are relatively reliable
• Nearby: C1 Input Channels and Interaction Primitives · K1 Platforms and Device Forms
• Search terms: touch input time · voice input · gesture constants · recognition error rate