Haptic anti-patterns

Review the interaction, not the buzz

A pattern can sound sensible in a design review and still be irritating in a real task. Walk the flow on a supported iPhone, including errors and repeated actions. These eight checks help locate the problem before you start adjusting intensity.

Buzzing for the whole wait

A loading operation begins and the phone vibrates until it finishes. A slow network now creates a long physical interruption, with duration determined by infrastructure rather than design.

Let the progress indicator carry the wait. If completion deserves a tactile cue, give it a bounded one at the actual outcome. Save sustained feedback for interactions where its changing character conveys something useful, such as controlling a game’s engine. Apple distinguishes short feedback for discrete events from longer gameplay effects. Haptic design guidance

A haptic on every touch

A row vibrates on touch-down, selection, navigation and the destination’s appearance. One gesture has become four unrelated sensations.

Choose the meaningful transition and give one component responsibility for it. For a picker, that might be a changed value. For a drag, it might be crossing a snap point. Instrument the calls during development: a surprising double pulse can be two handlers firing, not a badly authored pattern.

Success and failure feel alike

A generic “finished” callback plays the same pattern whether a save succeeds or fails. The haptic cannot tell the person anything reliable.

Make the outcome part of the feedback decision. A notification generator offers distinct success, warning and error types. Trigger success only after success is known, and leave the error message and recovery action available onscreen. Notification feedback

The cue lands after the collision

An object snaps into position, then the haptic arrives. Increasing strength makes the delay more noticeable.

Check where the work happens. Engine creation, file loading or a cold start in the interaction callback can delay playback. Prepare resources before the critical moment. With a feedback generator, prepare() needs some lead time; calling it immediately before triggering does not improve latency. Preparing feedback

Use Syncing haptics with audio and animation to separate resource preparation from scheduling.

Adding layers to fix an unclear effect

The cue is hard to identify, so you duplicate an event at the same time. Now the timeline is busier, but the meaning is no clearer.

Solo the parts. Give each a job: an initial impact, a sustained texture, an ending. Remove anything you cannot identify in context. Two coincident taps are a poor way to communicate two separate events; separate them in time if the distinction matters. Apple’s design sample discusses the limits of distinguishing simultaneous events of the same type. Playing custom haptic patterns

Ignoring the rest of the device

A tactile cue fires during recording or a precision interaction, where a physical vibration can become unwanted input.

Include camera, microphone and motion-based flows in your test plan. Decide which cues should be suppressed in those contexts. Do not assume a pattern that works in a menu is appropriate while the same device is recording sound. Apple’s interaction cautions

Making touch the only explanation

A vibration means an entry was rejected, but nothing changes onscreen. A person who cannot feel it has no explanation and no recovery path.

Display the error, preserve it long enough to read, and expose it to assistive technology. Make haptics optional. Repeat the task with them disabled: if you cannot complete it confidently, the fallback is incomplete. Accessible feedback

Signing off from a waveform

The picture looks right, so the pattern is marked done. A graph can reveal timing and parameter mistakes; it cannot tell you how the device feels in someone’s hand.

Use the Simulator for interface checks and a physical device for sensation. Record the hardware and test the cue inside the task, not just in an editor. Core Haptics’ file-playback sample explicitly requires real hardware for tactile output. Playing a pattern from a file

A checklist for your next review

• Does one state change trigger one intentional cue?
• Does its meaning agree with the visible result?
• Are the cue and the interaction aligned in time?
• Does repeated use still feel appropriate?
• Does the whole task work with haptics disabled?
• Has someone tested it on supported physical hardware?

If the same issues appear across several screens, turn the decisions into a haptic design system so each team does not have to rediscover them.