When a tap seems to do nothing
Miller (1968) and Card et al. (1991) describe responses within about 0.1 s as instant, around 1 s as keeping flow, and over 10 s as losing attention; Nielsen (1993) gives the same limits. If nothing changes within 0.1 s, people tap again, a common cause of double payments and duplicate posts. A small microinteraction that changes state instantly prevents this.
Showing it inside the button
Visible progress makes waits more tolerable (Myers, 1985). For short tasks, show a small spinner and change the label to 'Paying…', keeping the width fixed so the layout does not jump. Tasks over ten seconds belong in a progress indicator (Sherwin, 2014), and whole-screen waits suit skeleton screens. Animation style alone changes perceived duration (Harrison et al., 2010).
Endings and accessibility
On success, briefly show a check or 'Saved', then reset; on failure, re-enable the button and explain. A button spinning forever after failure looks like a frozen app, so add a timeout. Screen-reader users cannot see spinners, so announce 'Processing' and 'Done' via an aria-live region per WCAG 2.2 (W3C, 2023) 4.1.3.
FAQ
- Should the button be disabled while loading?
- Yes, usually, to prevent duplicates, while clearly showing the processing state.
- When use a progress indicator instead?
- For tasks taking more than a few seconds or with measurable progress.
Sources reviewed: 2026-10-27
References
- Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9–11, 1968, Fall Joint Computer Conference, Part I (pp. 267–277). ACM. Classic response-time thresholds.
- Card, S. K., Robertson, G. G., & Mackinlay, J. D. (1991). The information visualizer, an information workspace. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 181–186). ACM. Perceptual time constants of 0.1 s, 1 s and 10 s.
- Nielsen, J. (1993, January 1). Response time limits. Nielsen Norman Group. Three response-time limits.
- Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 11–17). ACM. Progress indicators make waits acceptable.
- Harrison, C., Yeo, Z., & Hudson, S. E. (2010). Faster progress bars: Manipulating perceived duration with visual augmentations. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 1545–1548). ACM. Animation changes perceived duration.
- Sherwin, K. (2014, October 26). Progress indicators make a slow system less insufferable. Nielsen Norman Group. When to use spinners versus progress bars.
- World Wide Web Consortium. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. Criterion 4.1.3 status messages.