Rules for inserting mental preparation operators determine estimate accuracy
Aliases: mental preparation · M operator · KLM rules · chunking
What it is
In KLM, a mental operator (M) represents a skilled user's brief pause before a method switch, decision, or feedback check. Whether an M is inserted before each operation, merged, or omitted changes the total substantially; insertion rules affect estimates more than the constant itself. This card builds on "estimate by summing time constants for standard operator units": that card explained how to time each of the six operator categories, and this one singles out M specifically because the occurrence count for the other five (keystroke, pointing, movement, dragging, system response) can nearly be read straight off the operation sequence, while M's presence and count have no such directly countable basis — it depends entirely on an insertion rule, which makes it the single easiest part of the whole model to get wrong.
Why it happens
M is hard to pin down because it corresponds to the human phenomenon of chunking: a skilled user does not treat a long string of keystrokes as independent actions each requiring its own decision — they compress a continuous, well-practiced sequence into a single block of action that needs no additional thought, and insert a genuine moment of mental preparation only at the boundary between blocks — switching methods, moving from pointing to typing, or pausing to check whether the system responded correctly. This means where M belongs depends on how many blocks the user has mentally divided the sequence into, not on how many operators the sequence contains. Modeling M mechanically before every single operator amounts to assuming the user re-decides at every step, which systematically overestimates total time; omitting M entirely flattens out the genuinely deliberative moments of method-switching and feedback-checking, underestimating real time. The two errors run in opposite directions but share the same root cause: the insertion rule was never aligned with how the user actually chunks the task.
Where it stops holding
How people chunk a task differs from person to person, and shifts with training and how much automation the interface itself provides: when an interface offers autocomplete or smart defaults for the same task, a moment of mental preparation that once required the user's own judgment may now be handled by the system in advance, and whether to keep that M needs re-evaluating rather than copying the rule used before automation existed. A high-frequency expert may have compressed the entire task into just a few blocks, with almost no visible pause; a skilled-but-not-quite-expert user, who uses the task less often but has still had meaningful training, may retain more brief confirmations between actions than an expert does, and such a user cannot simply inherit an expert's insertion rule. The duration of M itself is not a universal fixed value either — task pressure and familiarity with the interface both push this number up or down, so treating it as a physical constant like keystroke time is inaccurate.
Applying it
- For every M that appears in an analysis, write down the specific reason it was inserted — the start of a method, a switch in operator type, a needed feedback check, or a point where the user must choose among multiple methods. An M with no stated reason should not appear in the decomposition.
- Present three versions of the estimate side by side for comparison — no M inserted at all, M inserted before every operator, and M inserted selectively per the rule — to show plainly how much the insertion rule changes the result.
- Use skilled users' think-aloud or operation logs to identify where their real pauses occur, then adjust the insertion rule accordingly, rather than fixing the rule first and assuming users will pause where it says.
- How to check: whenever reporting an estimate, state which set of M insertion rules was used and which interface version it corresponds to — a KLM number missing both pieces of information gives readers no way to judge whether the estimate rests on a reasonable chunking assumption.