Haptic Feedback Design

The full lesson

Touch screens removed the physical click of a key. Haptic feedback gives some of that physicality back. When designed deliberately, it does more than simulate a button press.

A well-timed vibration can confirm that a payment went through, warn that a swipe has reached its limit, or guide a user who cannot look at the screen. A poorly designed one — or a missing one — leaves users tapping harder, wondering if anything happened, or flinching at an unexpected buzz.

Haptic design is not a finishing touch. It is a core feedback channel with its own vocabulary, constraints, and failure modes.

What Haptic Feedback Actually Is

Haptic feedback is tactile output from a hardware actuator — a motor or piezoelectric element that produces controlled vibration through the device. Consumer devices use three main actuator types:

The gap between an ERM and a modern Taptic Engine is enormous. Designs that assume “haptic” just means a generic buzz will feel wildly different across devices. This is the first thing every haptic designer must internalize: haptics are a hardware-dependent medium. The same API call feels completely different on a Galaxy S24 versus a five-year-old budget phone.

The Haptic Feedback Vocabulary

Before designing individual patterns, build a shared vocabulary with your engineering team. Platform frameworks publish named feedback types that map to actuator behavior. Using these named constants is faster to implement and more consistent than specifying raw millisecond values.

iOS (UIFeedbackGenerator)

Apple’s API organizes haptics into three semantic generators:

• UIImpactFeedbackGenerator — simulates a physical collision. Three weights: light, medium, heavy. Use it to confirm a discrete action like a button press or item drop.
• UINotificationFeedbackGenerator — communicates an outcome type: success (two quick taps), warning (tap-pause-tap), or error (three emphatic taps in quick succession).
• UISelectionFeedbackGenerator — a light tap as the user scrolls through picker values, signaling a position change without adding semantic weight.

Android (HapticFeedbackConstants + VibrationEffect)

Android exposes both semantic constants and raw waveform control:

• VIRTUAL_KEY / KEYBOARD_TAP — for confirmable press targets
• LONG_PRESS — for context menus and hold gestures
• CONFIRM / REJECT (Android 13+) — semantic success/failure equivalents
• VibrationEffect.createWaveform() — for custom patterns when no semantic constant fits

Start with semantic constants. Reserve raw waveforms for novel interaction patterns where no platform constant applies.

Designing Haptic Patterns for Common Interactions

Confirmations

A confirmation haptic fires after an action completes successfully. It answers “did that work?” without requiring the user to look at the screen. The classic example is the double-tap vibration on iOS after a payment goes through in Apple Pay — distinct enough to recognize, but not intrusive.

Key properties of a good confirmation:

• Fires after the operation completes, not speculatively when the user taps
• Short and crisp — typically under 100ms total
• Uses a semantically positive pattern (iOS success, Android CONFIRM)

Firing a success vibration before an async operation resolves is like optimistic UI without error recovery. If the server returns a failure, the user already felt “success.” For high-stakes operations — payments, deletions, authentication — always wait for the resolved state before firing.

Error Haptics

Error haptics should feel wrong. Not punishing, but clearly distinct from success. Apple’s notification error pattern (three emphatic taps) and Android’s REJECT constant both achieve this. The physical sensation of emphasis or resistance encodes meaning that does not depend on color or sound.

An error haptic must always be paired with a visual error state. Haptics alone fail accessibility requirements — users with motor or sensory differences may miss them, and screen readers need a text-based error path regardless.

Boundary and Edge Feedback

Drag interactions benefit from a light haptic at the boundary — the moment a list cannot scroll further, or a swipe has reached its limit. iOS calls this a “snap” effect; it is the same physical metaphor as a door hitting a stopper. This is one of the most effective uses of haptics because it communicates spatial information that is otherwise invisible.

A haptic “detent” (a brief pulse as a draggable element crosses a snap point, like a sheet, a slider tick mark, or a sort handle) gives users subconscious position feedback. It reduces the need to look at the screen.

Notification Haptics

Incoming alerts use haptics to interrupt attention. This is the most intrusive category and the most likely to erode user trust if overused. Two principles:

1. Match platform interrupt level — iOS and Android both have notification importance tiers (iOS Critical/Time-Sensitive/Active/Passive; Android IMPORTANCE_HIGH through IMPORTANCE_MIN). Use the appropriate tier and honor the user’s focus mode settings.
2. Never buzz for promotional or low-urgency content — a marketing push notification that wakes someone’s wrist destroys trust far faster than any bad UX buried in a settings screen.

Accessibility Considerations

Haptics are often called an accessibility win because they provide non-visual feedback. That is true, but incomplete. Haptic design has its own accessibility obligations.

Never use haptics as the sole channel for critical information. A user wearing gloves, holding the device at an edge, or mounting it in a stand may not feel the vibration. Every haptic message needs a visual equivalent, and an audible one where appropriate.

Respect system-level haptic preferences. iOS has a “Vibration” toggle under Accessibility > Touch. Android has a “Vibration and haptics” setting. Many users with chronic pain or sensory sensitivities turn system haptics off entirely. Apps must check whether haptics are enabled before firing them, and must work fully without them.

Motor accessibility and gesture interactions. Custom haptic patterns for complex gestures — multi-finger holds, directional swipes — can unintentionally exclude users with limited dexterity if the gesture itself is inaccessible. If a haptic-rich interaction is only reachable via gesture, provide an alternative activation path. This aligns with WCAG 2.2 criterion 2.5.1 (Pointer Gestures).

Cognitive load. Too much haptic feedback in a task-heavy context — like a stock trading app that buzzes on every price tick — creates cognitive overload. It becomes harder to identify which events actually matter. Keep your haptic vocabulary as small as the task allows.

Haptics in Wearables

Wearable haptics work in a fundamentally different context. The device is always touching skin, uses smaller actuators, and competes with ambient vibration from walking or commuting. Apple Watch uses a dedicated Taptic Engine with its own watchOS API (WKHapticType), which includes named patterns: click, directionUp, directionDown, success, failure, retry, start, stop, and notification.

Wearable haptic design diverges from phone design in two important ways:

• Glanceability replaces legibility — a wrist interaction lasts roughly 2 seconds. Haptics must communicate the outcome immediately, without the user needing to look at the screen.
• Sequence and rhythm are primary — wearable actuators have less dynamic range than phone motors. The temporal pattern (tap-pause-tap-tap) carries most of the meaning. A consistent haptic grammar across your wearable app matters as much as a consistent color language in a visual design system.

Haptics as a Design Token

Modern design systems treat motion and timing as first-class tokens stored in a W3C DTCG-compatible format. Haptic feedback deserves the same treatment. A haptic token vocabulary might look like:

haptic.confirm        →  platform: iOS=.success / Android=CONFIRM
haptic.error          →  platform: iOS=.error   / Android=REJECT
haptic.selection      →  platform: iOS=.light   / Android=KEYBOARD_TAP
haptic.boundary       →  platform: iOS=.rigid   / Android=VIRTUAL_KEY
haptic.notification   →  platform: iOS=.warning / Android=LONG_PRESS

These tokens live in your design system documentation alongside motion tokens. Engineers implement them through a platform abstraction layer — a single triggerHaptic('confirm') call that resolves to the correct native API per platform. This eliminates the “specify 80ms on iOS and 60ms on Android” fragility that appears when haptics are specified ad hoc.

Common Mistakes and How to Fix Them

Haptic overload. Adding a vibration to every tap, every scroll tick, and every animation frame creates noise that desensitizes users and drains battery. The fix: audit every haptic in your app against one question — does this vibration tell the user something they could not learn from looking at the screen? If not, remove it.

Symmetric patterns for asymmetric outcomes. Using the same buzz for “task completed” and “task failed” because both feel “important” destroys the semantic value of haptics entirely. Success and failure must feel different — this is the entire point of named semantic constants.

Ignoring the silent/vibrate distinction. Many users switch to silent because they do not want interruptions. Non-notification haptics — button presses, scroll boundaries — should still fire in silent mode. They are tactile UI, not alerts. True notification-class haptics (incoming calls, urgent alerts) should respect Focus and Do Not Disturb modes.

Treating haptics as an afterthought in design deliverables. If haptics appear in a Figma prototype as a small annotation saying “add haptic here,” they will be implemented inconsistently. The right approach is to include haptic tokens in your design system and make haptic behavior a reviewable part of your interaction spec — just like animation duration and easing.

Haptics in the Design Process

Haptic design decisions should be made alongside visual and motion decisions — not after them. The practical workflow:

1. Identify all interaction moments that produce state changes or outcomes. Use your microinteraction inventory or state machine as the source of truth.
2. Categorize each by semantic type: confirmation, error, boundary/position, notification, or ambient scroll.
3. Assign a haptic token from your vocabulary, or mark it as “no haptic” with an explicit reason (cosmetic event, web-only context, user preference disabled).
4. Prototype on device — use TestFlight or internal distribution to test real patterns on real hardware before finalizing.
5. Define fallbacks — specify the visual-only experience for users who have haptics disabled or are on hardware that cannot reproduce the pattern faithfully.
6. Include in handoff as a named token reference, not a raw duration spec.