Mobile Device Connection Flow

Users reported consistent difficulty connecting iOS devices. The existing UI was a single modal with two tabs — one for Android, one for iOS — that attempted to handle all device types, technical preconditions, connection options and edge cases simultaneously. The modal could not support the required validations, debugging information and error descriptions — instead redirecting users to an external resource, breaking the flow entirely.

• Direct user access was not available — developer interviews served as the primary research input.
• As an enterprise SaaS product, the tool serves users with varying technical backgrounds, from QA engineers to developers.
• No direct competitor references existed for this specific feature, requiring decisions to be grounded in first principles and platform documentation.
• iOS platform security requirements — Xcode installation, version compatibility, Developer Mode, Apple Dev Team ID — were non-negotiable technical preconditions that the UX had to accommodate, not simplify away.

Without direct user access, research was conducted through informal interviews with engineers who worked closely with the connection process. Additionally, support tickets gathered by the sales team provided real-world user pain points, giving direct insight into where the flow was failing in practice. The goal was to map the full technical process end-to-end — understanding every precondition, failure point and platform difference — in order to decide what complexity to surface in the UI and what to abstract away.

This revealed that iOS and Android connection processes were fundamentally different in nature, and that existing error states were undifferentiated and unhelpful to the end user.

Early exploration focused on the core structural question: should the flow remain a single screen, adopt a stepper, or become a full wizard? Multiple options were considered and tested internally. A single screen was rejected — the variable complexity across platforms made it impossible to present all required information without overwhelming the user. A static stepper was problematic due to the unequal number of steps across different paths — iOS requires more steps than Android by nature of its security requirements. The wizard pattern was chosen as it allowed each path to have its own focused sequence, with the user making one decision at a time. The OS selection step was deliberately excluded from the step count to avoid implying a fixed linear journey before the user had chosen their path.

Close collaboration with the engineering team was essential throughout the process. Technical constraints directly shaped UX decisions — the feasibility of automatic precondition checks was determined together with engineers, as was the scope of in-flow recovery actions. Understanding which error states could be resolved without leaving the flow, and which required external action, required ongoing back-and-forth with the development team. The connection flow improvement remained an ongoing collaboration — edge cases and error states continued to be identified and addressed after initial release.

Accessibility was considered throughout the design process, in collaboration with dedicated A11y experts. The wizard structure naturally supported accessibility by reducing cognitive load — presenting one decision at a time rather than overwhelming the user with all options simultaneously. Focus management across steps, error state announcements and keyboard navigation were reviewed and aligned with WCAG standards.