Choose haptic feedback when a physical pulse should reinforce a specific interaction event such as press, drag threshold, detent, snap, selection, boundary, success, warning, or destructive confirmation, while the same information remains visible or audible elsewhere.
Choose haptic feedback when a physical pulse should reinforce a specific interaction event such as press, drag threshold, detent, snap, selection, boundary, success, warning, or destructive confirmation, while the same information remains visible or audible elsewhere.
Practice the judgment: Imagine this situation: A long upload uses repeated vibration instead of progress text and cancellation controls. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Haptic feedback | Touch gesture | Toast notification | Error state | Confirmation dialog | Progress bar |
|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Tactile feedback vocabulary for physical interaction events | UI + UX - Touch-first gesture vocabulary and fallback contract for taps, swipes, drags, pinches, and multi-touch interactions | UI + UX - Transient non-modal status message | UI + UX - Recoverable failure surface | UI + UX - Consequential alert decision | UI + UX - Measurable system-operation progress indicator |
| UI guidance | Render haptic feedback as an optional tactile layer attached to visible interaction states, with labels or settings that explain when vibration, impact, selection, warning, or detent effects happen. | Render touch gesture affordances with visible targets, enough spacing, state feedback, and non-gesture controls for the same outcome when a gesture is path-based, multipoint, hidden, or easy to misfire. | Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. | Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. | Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages. |
| UX guidance | Help the person reach a clear task outcome. | Use touch gesture when the product needs direct manipulation on a touchscreen, but treat gestures as part of a larger interaction contract rather than the only way to act. | Escalate to inline, section, dialog, notification center, undo, or error-state treatment when the message requires repair, proof, long reading time, several actions, or reliable recovery. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | Help the person reach a clear task outcome. | Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later. |
| Good UI | A slider gives a light detent when crossing whole-number stops, shows the value visually, and suppresses repeated vibration while the thumb rests on the same stop. | A photo viewer supports pinch to zoom, double tap to zoom, plus and minus buttons, a reset button, zoom percent feedback, and a clear pan boundary after zoom. | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. | A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable. |
| Bad UI | Every button press uses the same heavy vibration regardless of whether the action selected, warned, failed, or succeeded. | A hidden edge swipe deletes a message while the user is trying to scroll the list. | Five unrelated toasts pile up over the Save and Continue controls. | Tiny transient toast for a blocking failure. | The red destructive action is enabled immediately and sits where users expect the routine primary button. | A progress bar reads 100% complete while virus scanning and server acceptance are still pending. |
| Good UX | A user drags a reorder handle and feels one detent at each valid slot while the row preview and insertion marker move visibly. | A user starts swiping a gallery card, sees the next-card preview, changes their mind by moving back under the threshold, and the card snaps back with position unchanged. | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. | A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds. |
| Bad UX | A user in a quiet meeting gets repeated vibration from decorative hover-like effects. | A user tries to scroll a feed but the product interprets a short diagonal movement as a destructive swipe action. | Every autosave tick triggers a toast, training users to ignore real status changes. | Clearing work after save failure. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. | Users leave after 100% transfer even though server processing later rejects the file. |
| Best fit | A tactile pulse reinforces a direct manipulation, boundary, threshold, selection, successful action, recoverable warning, or physical game/control event. | A touchscreen interaction needs deliberate design for gesture vocabulary, thresholds, feedback, target sizing, cancellation, and equivalent controls. | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. | A system or task failure blocks expected content or action. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. | A system operation has a measurable total or bounded progress value. |
| Avoid when | The event is decorative, frequent, passive, delayed, or unrelated to a user action. | The gesture is only an implementation detail inside a more specific pattern such as swipe action, pull to refresh, long press, drag and drop, bottom sheet, carousel, or map view. | The message is the only recovery path for a blocking or high-consequence failure. | Nothing exists yet and the state is expected. | The action is routine and easily reversible. | The wait is short and only needs scoped activity feedback. |
| Required state | User haptics disabled, reduced feedback, notification silence, or battery-sensitive state. | Touch down or gesture start state that identifies the active target. | Stacked state with newest and older messages ordered predictably and capped. | Normal expected state before failure. | Pre-action state with an explicit consequential trigger. | Idle state before the operation starts. |
| Accessibility burden | Respect system haptic, vibration, reduced motion, sensory, notification focus, and accessibility settings. | Provide a simple single-pointer alternative for multipoint or path-based gestures unless the gesture is essential. | Keep close and action controls keyboard reachable, clearly named, and stable while focused. | Use appropriate alert or status semantics for newly appearing critical errors. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. | Provide an accessible name that identifies the operation and affected object. |
| Common misuse | Using haptics as the only error, warning, or success message. | Making a hidden gesture the only way to find navigation, delete, refresh, zoom, or edit controls. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Using a transient toast for critical errors. | Asking users to confirm every routine action until they stop reading. | Fabricating progress values just to make users feel movement. |