Bluetooth pairing flow

First experience with high failure rate

Bluetooth pairing for medical-grade hearing aids is not the same as pairing a speaker. Hearing aids have their own connection protocols and physical interaction patterns. Most users have low technology literacy and no prior experience pairing a Bluetooth device.

Support data confirmed it: connection drove more than half of all support calls, the single biggest driver, and the highest abandonment point in the onboarding funnel.

UX designer

Owned the design across all four iterations, working closely with product, engineering, and the audiological team.

Same flow, completely different contexts

The same flow serves two completely different contexts:

What the research showed

We started with support data, then ran research sessions to understand why connection failed so often. The sessions showed the flow itself was sound. The gap was what happened when the hardware did not cooperate.

Findings

• HAWs had no mental model for re-pairing. First-time setup was handled at the clinic, but when the app crashed and they needed to pair again at home, there was no guidance and no recovery path.
• Every HCP participant had developed their own workaround: force-quitting the app, toggling Bluetooth manually, repeating the flow from scratch. None of these were supported by the design.
• When an error occurred, users couldn’t tell whether the problem was the app, the hearing aids, or their phone. No state-specific feedback meant no actionable next step.

A decision tree, not a linear flow

Full connection flow decision tree · Wireframes · Figma · Connection Workflow

A linear pairing flow only works when everything goes right. I structured the flow as a decision tree. At each node the app checks a condition and routes to the next step, so users never hit a dead end.

Two user types, one flow

The flow serves both HAWs and HCPs through the same screens. The design had to be clear and reassuring enough for someone who has never paired a Bluetooth device, while staying concise enough for someone doing it ten times a week.

Design decisions

• Permission context before the OS prompt: A brief explanation before the system dialog reduced refusals and gave less technical users a reason to tap Allow.
• Visible scanning state: A loading indicator confirmed the phone was actively searching. Silence from the app reads as failure.
• Help that stays out of the way: 'Need more help?' opened an inline drawer without leaving the flow.

Hearing aid restart

Users had to manually restart their hearing aids before pairing by opening and closing the battery door, or placing the devices in the charging case for several seconds. Explaining a physical action in a UI required a restarting animation, not just text.

Design implication

The flows couldn’t be identical. The permission model on Android required a denial-count state that iOS didn’t need, and the pairing dialog varies by device manufacturer on Android in a way iOS doesn’t. We maintained separate Figma pages for iOS and Android from iteration 1.

←

1 of 10

Welcome Screen

→

T&C acceptance required before any data is processed, a legal requirement built into the entry point, not retrofitted later.

Six error states

Each error state was mapped with firmware and product: what triggers it, what the app can detect, and what the user needs to do next. The rule throughout: every failure state defines a specific next step.

Built in four iterations

Four iterations. Each added specificity: more error coverage, better platform handling, tighter accessibility.

What shipped

• Decision-tree flow shipped for iOS and Android: Covering HAW and HCP with platform-specific adaptations for permissions, back navigation, and pairing.
• Six error states, six recovery paths: No user path ends in a dead end. Every failure mode has a defined next step and a route back into the flow.
• Accessibility validated on real devices: Focus order, live regions, and screen reader read-order across all screens, run with real hearing aid users and real hearing aids.
• Annotation system adopted team-wide: The VoiceOver and TalkBack approach established here became the WSA design team standard for accessibility handoff across all features.

Real-device accessibility testing (VoiceOver on iOS, TalkBack on Android, both with paired hearing aids) surfaced focus-order and live-region gaps that screen review had missed. The fixes shipped in iteration 3 and the annotation approach became the team’s standard for accessibility handoff. The app has not yet been released, so post-launch engagement data is not available.

The one thing I’d do differently

The accessibility evaluation happened in Iteration 3, after the core flow structure and error states were already built. The rework was significant enough to push the release date. One session with a screenreader user against early wireframes would have surfaced the focus order problems before they were baked into every screen. Accessibility changes what gets built from the start. Treating it as a final review step costs rework.