| 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 | Use haptic feedback when touch can reinforce direct manipulation, action commitment, selection movement, boundary crossing, snap points, warnings, or successful completion without becoming the only feedback channel. | 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. | Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task. | Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work. | Interrupt users only when the action has a meaningful consequence that cannot be safely recovered afterward. | 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. | Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions. | 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 map can only be zoomed with a two-finger pinch and has no plus, minus, or reset controls. | Five unrelated toasts pile up over the Save and Continue controls. | Tiny transient toast for a blocking failure. | A popup says Are you sure? with OK and Cancel but does not name the project, notes, or irreversible outcome. | A blue bar fills across the top of the page with no label, no percent, and no affected object. |
| 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 pinches a diagram to zoom, sees the scale change, releases outside the threshold without committing a rotate gesture, then uses visible Zoom in and Reset controls with one finger. | 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 cannot tell whether a pulse means success or failure because the same pattern plays for all outcomes. | A user with a head pointer cannot trigger a two-finger gesture and has no single-pointer alternative. | 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. | A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option. |
| 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 feedback is required for comprehension and no visible or audible equivalent exists. | 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. | Progress cannot be measured or would be guessed. |
| Required state | Capability unavailable, unsupported browser, no vibration hardware, or no controller rumble state. | Idle state with visible touch targets, gesture hints when needed, and no reliance on hover. | Idle state with no visible toast and a reachable status or history region when applicable. | Normal expected state before failure. | Pre-action state with an explicit consequential trigger. | Idle state before the operation starts. |
| Accessibility burden | Never rely on haptics alone for success, failure, warning, validation, progress, or confirmation. | Provide a simple single-pointer alternative for multipoint or path-based gestures unless the gesture is essential. | Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement. | 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. | Requiring pinch, rotate, two-finger swipe, or shape gestures with no single-pointer alternative. | 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. |