The higher the takeover threshold, the more people settle for a result they dislike

What it is

A typo is visible at a glance. To change it: “convert to document,” agree to a notice, wait to load, then find a toolbar. People copy the typo’d version out. The higher the takeover threshold, the more the default response to a disliked result is not edit but settling. Settling is not liking; it is that the path of change costs more than the error itself.

That editing a generated artefact requires understanding it first is a skill problem. Here the skill is enough; the path is too expensive.

Why it happens

Action cost is compared with degree of dislike. Small errors (one character, one form of address) have a ceiling on dislike; if takeover means changing mode, losing formatting, risking overwrite on regenerate, the comparison says send it. The system then receives an “adopted” signal and treats settling as quality pass.

The threshold is the sum of frictions: read-only must convert, mobile cannot edit, selection-regenerate refreshes the whole, no clear save after edit. Any one link that exceeds the pain of a small error produces settling. Only large errors push people over the threshold, so the product collects extreme dislike and silently ships moderate errors.

Studying it

Plant small and large errors; manipulate takeover steps (one-tap edit vs. three-step convert). Dependent variables: actual edit rate, rate of sending with a known error, post-hoc satisfaction (settlers often still rate “fine”). Independent variables: step count, overwrite-risk warning, device.

Split settling from true satisfaction. Ask “did you see that error” — seen and still sent is threshold, not missed detection.

Where it stops holding

On a viewer-framed finished accept, settling can be the right behaviour (a checked number should not be edited). In high-stakes documents a low threshold lets people alter slots they should not; pair with locks. Users who cannot edit at all will not edit no matter how low the threshold — skill, not friction. This entry does not treat the cognitive load of understanding existing text.

Applying it

• Make the path of a small edit shorter than the pain of a small error: one tap to change that character, not a convert of the whole.
• Give mobile a path as short as desktop; do not offer only copy.
• Do not treat “adopt” as a quality pass. Count sends that carry a known unedited error.
• Check: plant a visible typo; count how many people see it and still send. That share is settling manufactured by the threshold. Shrink edit to one tap; the share should drop.

Related

• Same group: L3.12.1 Whether a generated artefact is framed as a draft or a finished piece decides whether the UI should lean editor or viewer · L3.12.2 Regenerating after the user has taken over will overwrite human edits unless a merge rule is explicit · L3.12.3 Human edits should be marked, or afterwards no one can tell which stretch came from whom · L3.12.5 Editing a generated artefact can take more skill than writing from scratch, because the existing text must be understood first
• Nearby: L3.13 User Feedback Loops on Generation Quality · L2.12 Iterative Edits and Local Regeneration
• Search terms: takeover threshold · satisficing generated output · editing friction