H8.04.3copy confirmation feedbackdesignresearch

Copy needs confirmation that it worked

Aliases: copied toast · clipboard feedback

What it is

Copy writes into the clipboard and usually leaves the surface unchanged. People cannot see the clipboard; they verify by pasting later. Confirmation means the act itself says “it is in,” and says which slice—link, title, formatted body—rather than a button that springs back and invites another tap. This is not the share payload list, and not whether an export stays editable.

Why it happens

The clipboard is implicit storage. Success and failure look the same: a clicked button. The workaround is repeated taps, or leaving to paste as a test. Extra taps overwrite with empty, with a stub, or with a later failure covering an earlier success. Test-pasting breaks the current job. A brief “copied” turns invisible storage into a perceptible state change; naming the object (“link copied,” not a vague “success”) lets the next act match the expectation. Fade too fast and a blink misses it, prompting another tap; linger on the content and it becomes a new interruption. A failure (permission, browser limit) dressed as success makes the next paste emit old content that people treat as the new send.

Studying it

Copy a link or a passage, then paste at a named place. Compare no feedback, color change only, copy that names the object, and failure styled as success.

Independent variables: whether feedback appears, whether it names the object, duration, whether failure shares success chrome. Dependent variables: repeat-click count, paste matching expectation, leaves from the current page just to verify.

Labs usually already granted clipboard permission, so failure never shows. Re-run in a browser that denies it. On mobile, Copy and Share sit adjacent; log cases where the wrong entry is treated as a completed copy. A hit on the button is not success.

Where it stops holding

The OS already confirms its own copy menu on a text long-press; the app should not stack a second, fighting toast. Copying a password or one-time code still needs confirmation, but the toast must not echo the full secret. Huge selections may be truncated by the system; say “first n characters copied, the rest did not enter the clipboard,” not that the whole piece is there. Assistive tech needs the confirmation spoken; a color flash is not enough.

Applying it

  • On success, show “link copied / title copied / body copied” beside the control for a few seconds, then fade without covering the main content.
  • On failure, name the reason (“the browser blocked clipboard write”). Do not reuse success styling.
  • Briefly change the button to Copied, then restore, so extra taps do not overwrite; if the object can change (a refreshed link), allow another copy after restore.
  • Verify: after Copy, without leaving, ask what is on the clipboard. Repeat with permission denied: failure, not “copied.” Match the paste to the toast copy.

Related

  • Within the group: H8.04.1 Sharing must name what will be exposed · H8.04.2 Export formats need a stated use range
  • Adjacent: H8.08 Sharing Scope and Permission Settings · D1.01 Operation Feedback · I3.01 System Status Visibility
  • Search terms: copy confirmation · clipboard feedback · copied toast

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H8.04.3