| name | timing-feedback |
| description | Response timing, acknowledgment, and making the interface feel alive. Every action deserves a response at the right speed. Use when designing interactions, evaluating responsiveness, or diagnosing why a product feels sluggish or dead. |
Timing & Feedback
Every user action deserves acknowledgment. The question is what kind and how fast.
How to use
/timing-feedback Apply timing and feedback constraints to interaction design in this conversation.
Constraints
Timing Scale
- Instant (< 100ms): Direct manipulation. Button presses, toggles, drags. Any delay here feels broken.
- Fast (100-300ms): Page changes, panel opens, filter applications. Most UI animation lives here.
- Deliberate (300ms-1s): Complex operations. Loading a view, running a search. User accepts the wait because the action feels significant.
- Patient (> 1s): Needs explicit feedback. Progress indicator, skeleton, status message. Silence here feels like failure.
Feedback Types
- Visual: Color change, animation, state shift. Minimum viable feedback.
- Spatial: Element movement, expansion, collapse. Communicates where something went.
- Informational: Text confirmation, count update, status change. Communicates what happened.
- MUST provide at least one feedback type for every user action
- SHOULD mute the device and verify: can you still tell what's happening?
Anti-Patterns
- Identical response timing for all actions regardless of significance
- No feedback for destructive actions (delete, remove, disconnect)
- Spinners where skeletons would preserve spatial context
- Feedback animations that outlast the actual operation
