A haptic design system

Start with five meanings

A haptic design system can begin with a table. Take the interactions your app already has and name the information each one conveys: selection changed, object snapped into place, operation completed, warning, failure. You do not need a bespoke vibration for every component.

The useful unit is a meaning. A save button and an upload button can share an outcome cue if both mean “your work is safely stored.” A press on either button is a separate event: it acknowledges input, before the operation has succeeded.

Apple asks apps to keep system haptics consistent with their established meanings. Start there, then design custom feedback for the gaps. Apple’s haptic guidance

Write the contract before the waveform

Here is an example for a document app. These are suggested names and responsibilities, not a universal vocabulary.

Give each token an owner, a trigger and an exclusion. The exclusions prevent most accidental overuse. They also give engineering something precise to implement and QA something observable to check.

For a delayed operation, specify what happens if the person leaves the screen. A late vibration with no visible context is hard to interpret. Decide whether the cue still belongs, rather than letting a completion callback make that decision by accident.

Map the meaning to each platform

Keep a semantic token separate from its implementation. On iPhone, a selection token can use a system selection haptic. A custom collision might use an AHAP pattern. On a Mac, a dragged object reaching a guide can use the trackpad’s alignment feedback. Those implementations serve the same interaction without promising an identical sensation.

A Mac trackpad exposes fixed feedback patterns rather than arbitrary AHAP playback. For controller output, query the controller’s supported haptic localities. An iPad’s lack of built-in Core Haptics output does not tell you whether a connected controller supports it. Trackpad feedback, controller capabilities

Write “visual status remains available” in the fallback column. Do not silently translate a complex haptic into a long generic buzz simply because the destination cannot reproduce it.

Keep custom patterns small and named

Suppose your app has a custom “latch closed” interaction. Start with one impact. If the mechanism needs a settling tail, add one. Compare the single tap and click and hum as editing exercises; neither is a replacement for Apple’s success haptic.

Store the chosen pattern as one reviewed file. Give it a semantic name such as latch-closed.ahap, and keep a short record of its intended context, revision and test devices. AHAP’s top-level Version is the format version, not your product’s revision number. AHAP format

Avoid publishing an intensity scale as though it were a physical measurement. A value of 0.5 is an authoring parameter, not a promise that every device will feel half as strong as one set to 1. Review a small set of candidate strengths in the actual interaction and record the values you choose.

Review changes as a set

When someone proposes a new token, ask them to play it next to the nearest existing one. Can they explain the difference in meaning? Can they explain why reusing an existing token would be misleading?

Then run the whole flow. An isolated cue can be pleasant while ten repetitions in a minute are distracting. Include the shortest path through the app, the busiest path, and a failed operation followed by a retry.

Keep this review record with the pattern:

• Trigger and meaning, including when the cue is suppressed.
• Pattern file or system feedback type, and revision.
• Visual feedback, accessible status and any sound.
• Behaviour with haptics disabled or unavailable.
• Devices tested, findings and reviewer.

A shared file is only half the system. A shared rule for when to play it is the other half. Haptic anti-patterns gives you a review checklist; haptics as an accessibility channel covers the fallback in more detail.