Haptic feedback

Problem Context

• The product runs on touch, game, wearable, mobile, web, or controller hardware where tactile output may be available.
• Haptic events may reinforce button press, selection movement, snap detent, drag threshold, boundary hit, refresh, success, warning, failed gesture, destructive commit, notification, or game event.
• Users may disable vibration, use assistive technology, hold the device on a table, use desktop hardware, have reduced-motion or sensory preferences, be in quiet contexts, or use unsupported browsers.
• Haptic feedback is adjacent to touch gesture, toast notification, error state, confirmation dialog, progress bar, notification preferences, and sound or motion feedback.

Selection Rules

• Choose haptic feedback when the tactile effect reinforces a visible interaction milestone and improves physical confidence without carrying required information alone.
• Use touch gesture when the main design question is how input is recognized, thresholded, canceled, or made equivalent through controls.
• Use toast notification when a short visible message, undo, or status copy is needed after an action.
• Use error state when users need persistent explanation and recovery; haptics may draw attention but cannot replace visible errors.
• Use confirmation dialog when users must explicitly review and choose before risk; haptics can follow final commit but not replace the decision.
• Use progress bar when duration or percent complete matters; do not use repeated vibration as progress indication.
• Map haptic intensity and pattern to semantic weight: selection and detents should be lighter than warnings or destructive commits.
• Respect system settings and product preferences for vibration, haptics, reduced motion, notification mode, and quiet hours.
• Provide no-hardware and no-permission behavior for web and desktop environments where vibration is unavailable or ignored.
• Avoid haptics for decorative delight, passive page load, hover-only interactions, repeated errors, long waits, or background events users did not initiate.

Required States

• Capability unavailable, unsupported browser, no vibration hardware, or no controller rumble state.
• User haptics disabled, reduced feedback, notification silence, or battery-sensitive state.
• Light press or button down feedback state.
• Selection changed feedback state.
• Drag threshold reached state.
• Snap detent or boundary reached state.
• Invalid gesture, blocked movement, or limit reached state.
• Success or completion feedback state.
• Warning or recoverable-risk feedback state.
• Error reinforcement state paired with visible recovery.
• Destructive commit feedback state after explicit confirmation.
• Repeated-effect suppression or debounce state.
• Cancel current vibration or stop pattern state.
• No-hardware fallback state with visible and audible alternatives.
• Web vibration pattern state with duration and cancellation limits.
• Preference preview and test feedback state.
• Privacy or quiet-context state where vibration is suppressed.

Interaction Contract

• A haptic effect plays only for a user-relevant interaction event and stays synchronized with the visible state change it reinforces.
• Users can complete and understand the task when haptics are unavailable, disabled, delayed, unsupported, or suppressed.
• The same haptic pattern does not mean conflicting outcomes such as success and failure.
• Repeated gestures, loops, long waits, and animation frames do not create continuous or fatiguing vibration unless the user explicitly opted into a game/controller effect.
• Warning, error, destructive, and payment-related haptics are paired with visible copy and controls.
• Settings and platform conventions decide whether haptics are enabled, reduced, previewed, or suppressed.

Implementation Checklist

• Inventory all candidate tactile events and remove decorative, redundant, background, or high-frequency effects.
• Define a semantic vocabulary for light tap, selection, detent, threshold, success, warning, error reinforcement, and destructive commit.
• Check platform support and use platform-predefined effects where available before custom vibration patterns.
• Respect user and system settings for haptics, vibration, reduced motion, notification focus, battery saver, and accessibility preferences.
• Synchronize tactile output with visible state changes, not delayed network responses unless the visible state also changes then.
• Debounce repeated effects during drag, scroll, slider, game loop, and validation states.
• Provide visible text, live status, audio, animation, or control state alternatives for every haptic meaning.
• Test unsupported hardware, disabled haptics, reduced settings, long press, drag thresholds, boundary hits, repeated errors, keyboard use, screen readers, and quiet contexts.

Common Generated-UI Mistakes

• Using haptics as the only error, warning, or success message.
• Playing the same strong vibration for every tap and outcome.
• Looping vibration during progress, loading, or background work.
• Ignoring system haptic or vibration preferences.
• Adding decorative pulses that are not tied to interaction meaning.
• Assuming web vibration works on every browser and desktop device.
• Playing warning haptics before users understand the visible consequence.

Critique Questions

• What exact event does each haptic represent, and is that event visible at the same time?
• Can users distinguish selection, threshold, warning, success, and error effects without overloading memory?
• What happens when hardware, browser support, system settings, battery saver, or preferences suppress haptics?
• Is any required information communicated only through touch?
• Are repeated effects debounced during dragging, scrolling, validation, loading, or game loops?
• Is this really haptic feedback, or does touch gesture, toast notification, error state, confirmation dialog, or progress bar own the main problem?