Without a clear picture of what the result should look like, a mistake is hard to notice

What it is

Whether a user can notice their own error depends on whether they hold a clear enough sense of "what this was supposed to look like" to compare against. When the task goal is explicit — the transfer amount should be this number, the document should save in this format — any deviation from that baseline gets noticed right away. But when the goal itself is fuzzy — exploring a parameter to see what happens, casually tidying a batch of files, not yet having decided exactly what layout is wanted — the user has no clear baseline to compare against in the first place. Even if the result has already drifted from what was originally intended, it's hard to flag it as an "error," because "correct" was never defined clearly enough to drift from.

Why it happens

Error detection is, cognitively, a matching operation: comparing an observed outcome against an internally held expected representation, with any mismatch registering as "wrong." That match can only happen if the expected representation itself is specific and stable enough — if the expectation is only a fuzzy sense of direction rather than a concrete target state, one side of the comparison is simply empty, and no mismatch can be detected. Exploratory tasks are exactly where this specific expectation is missing: the user starts out in a "let's see what happens" mindset, and almost any outcome, in the moment, can be read as just part of the exploration rather than singled out as a deviation. This isn't a lack of attention on the user's part — the detection mechanism itself has no working input to run on.

Studying it

A typical experiment comparing detection rates between explicit-goal and vague-goal tasks plants the same error at the same point for two groups, gives one group a specific, checkable goal description and the other only a broad directional instruction, then compares how often each group notices or corrects the error on their own. Methodological caveat: an "error" under a vague goal is itself hard to define objectively, since there's no single correct answer. The experiment designer needs to predefine some criterion that counts as a deviation even within an exploratory task — for instance, a result that doesn't match what the participant later recalls their own initial intention to have been — or there's no way to tell whether an undetected deviation is actually an error at all.

Where it stops holding

This doesn't apply to creative tasks that have no single correct answer to begin with — in that setting, a mismatch between expectation and outcome isn't necessarily an error; it may be exactly the kind of valuable surprise worth keeping, and measuring creative exploration through an error-detection lens wrongly treats a beneficial deviation as something to fix. Nor does this flip into "the more specific the goal, the better": an overly specific goal description compresses the space a user has to try alternatives. The real boundary is whether the task has a "correct" state the user recognizes as such at all, not how finely the goal happens to be worded.

Applying it

When designing a task with a well-defined correct outcome, let the user see or confirm a concrete target representation — a preview, a target value, a sample of the expected result — before they start acting, rather than expecting them to hold that goal in memory throughout the operation. The more concrete the target representation, and the easier it is to check against at any point during the operation, the stronger the user's own ability to catch a deviation. For features that are genuinely open-ended and exploratory, don't force an error-detection framing onto them by prompting "this result might not be right" — without a baseline to compare against, that kind of prompt only produces confusion instead of help. Verification: after a user finishes a task, ask them directly to rate whether the final result matches what they expected and to explain why. If they can clearly state what's wrong, the expected representation is concrete enough for the detection mechanism to work. If they can only offer a vague satisfaction rating with no specific difference named, the design hasn't given this task a concrete enough target representation.

Related

• Same group: A10.15.1 self-detected errors cost less to correct than system-flagged ones · A10.15.3 the longer the gap between action and feedback, the lower the odds a user detects their own error · A10.15.4 systems should prioritize supporting self-detection rather than handing detection entirely to system validation
• Nearby: A7.01 the definition and function of mental models · A10.03 omission errors vs. commission errors
• Search terms: error detection · goal clarity · expected outcome