MY CONTRIBUTION 

As the lead UX designer on the project I:

- Led design of the UX flow, created scenarios and user flows for all possible paths including solutions to edge cases.
- Collaborated across the Google Maps and Fitbit engineering and design teams.
-  Presented flows, issues found and possible solutions across three teams. 
- Raised issues I found through iterations, not originally addressed and facilitated team meetings to find solutions.
- Led cross team meetings to increase understanding of requirements and technological constraints of each product.
- Kept the project ahead of schedule despite management changes and team reorgs.

Background

Unlike other smartwatches, Fitbits receive information through its phone app via Bluetooth. This requires both the Google Maps and Fitbit apps to be active to receive navigation instructions on a watch. Fitbit approached us to design the Google Maps side of their onboarding flow which would allow users to activate this bluetooth connection.

This is the flow we received from Fitbit, showing what the user will see on their side before coming to Google Maps. Clicking 'OK' on the second screen will force open Google Maps and begin our flow.

INITIAL CONCEPT: A STREAMLINED INTEGRATION

At the outset of this project, the Fitbit-Google Maps integration for iPhone users seemed straightforward. Initial consultations with my manager and the Fitbit team led us to envision a simple two-screen flow: users would click "Allow" on a pop-up and be seamlessly redirected back to the Fitbit app setup. This streamlined process promised a frictionless user experience during device setup, aligning with our goal of simplicity.

UNCOVERING COMPLEXITIES

A subsequent review with the Google Engineering team revealed an unexpected challenge: the integration was far more complex than anticipated. Despite Fitbit's acquisition by Google, we discovered that the apps might not share the same Google Developer profile on iOS at launch, complicating the connection process. 

The setup process now required Fitbit to initiate a series of technical actions, including passing security keys, requesting permissions, and verifying app safety. This new understanding necessitated a complete redesign of our UX approach. I returned to the drawing board, tasked with creating comprehensive flows that could elegantly handle multiple conditions and edge cases. This approach aimed to not only facilitate these technical requirements but also maintain user confidence and satisfaction throughout the process.

I started by creating a document that outlined all of the technical actions needed and went through each possible scenario the user could experience.

Reimagined UX Flows 

Given these complexities, we identified three key scenarios that would cover both the ideal user journey and potential edge cases, assuming Fitbit and Google Maps could share the same developer profile by launch.

SCENARIO 1: FIRST-TIME BLUETOOTH REQUEST 

This scenario occurs when Google Maps requests Bluetooth permissions for the first time on an iOS device. Apple's iOS will display a permission dialog, allowing the user to accept and then would be redirected back to the Fitbit app.

SCENARIO 2: BLUETOOTH PERMISSIONS PREVIOUSLY DENIED

This scenario occurs when Google Maps has previously requested Bluetooth access but was denied or  subsequently disabled. Users must manually enable Bluetooth for Google Maps in iOS settings and return to the app to finish Fitbit setup. However, this process presents a potential challenge: iOS may terminate Google Maps in the background, potentially disrupting the setup process if users don't directly reopen Google Maps after adjusting their settings.

SCENARIO 3: EDGE CASE

This scenario occurs when a user initiates Fitbit onboarding while an active navigation is in progress. In this edge case, when Fitbit attempts to open Google Maps, no action will be taken due to driver distraction laws. We cannot disrupt active navigation and must prioritize user safety. Users will only be able to enable the connection once navigation ends, ensuring a seamless integration without compromising safety or functionality.

If Google Maps and Fitbit are unable to share the same developer group on iOS, these three adjusted scenarios encompass both the ideal user journey and potential edge cases. These scenarios mimic the ones above but incorporate the additional step and time required for Apple server attestation, adding complexity to the integration process. 

SCENARIO 1:  FIRST-TIME BLUETOOTH REQUEST WITH SERVER ATTESTATION 

This scenario mirrors the previous one, but requires server attestation due to the apps being in separate developer groups. The process duration is unpredictable and contingent on connection stability on both ends and engineering feedback revealed iOS has an aggressive background app termination policy which poses another risk. To mitigate this, I strategically placed a server attestation loader before the Bluetooth permission request, ensuring both apps remain active throughout this critical phase.

SCENARIO 2: RE-ENABLING BLUETOOTH WITH SERVER ATTESTATION

This scenario also mirrors the previous one, but includes the server attestation step before requesting Bluetooth access. This multi-step process extends setup time and increases user error potential. To address this, I implemented a clear user prompt after attestation, emphasizing the importance of returning to Google Maps to complete the Fitbit connection.

SCENARIO 3: EDGE CASE 

This scenario occurs when Google Maps already has Bluetooth access, but server attestation is still required. Upon switching to Google Maps, a loading screen manages the attest duration, ensuring a smooth user experience regardless of connection speed or server response time.

Final Solutions

A production delay at Fitbit unexpectedly resolved our integration challenges, allowing both apps to join the same developer group before launch. This simplified the setup process, eliminating the complex scenarios previously described. We leveraged this opportunity to optimize our final two user flows, focusing on core experience enhancements. This development underscores the value of adaptability in UX design.

SCENARIO 1 - HAPPY PATH

The final happy path scenario is streamlined and user-friendly. It occurs when Google Maps requests Bluetooth access for the first time on iOS. With both apps now in the same developer group, users are prompted to enable Bluetooth directly within the app, eliminating the need for server attestation or manual settings adjustments. This seamless flow ensures a quick and efficient setup, enhancing the overall user experience.

SCENARIO 2 - ALTERNATE PATH 

This alternate path occurs when Google Maps has previously requested Bluetooth access, but it was either denied or subsequently disabled. In this case, users need to manually enable Bluetooth permissions through the iOS Settings app. While this process requires an extra step compared to the happy path, it's significantly streamlined from earlier versions. 

IMPACT

The streamlined UX, made possible by merging app groups, launched successfully in September 2023. This cross-platform collaboration between Fitbit and Google Maps not only met both teams' objectives but also exceeded user expectations. The feature's immediate popularity was evident in user feedback, with one user stating:

“Having turn-by-turn directions on my wrist was the next best thing to having a human navigator.” 

Post-launch tracking revealed an impressive 95% success rate, with minimal crashes reported on iPhones and new Fitbits using turn-by-turn navigation. This outcome underscores the project's success in delivering a seamless, user-friendly integration with Google Maps.

TEAM

Google Maps Driving  Team
Matt Hunter  UX Program Manager - Maps
Joe Chehock  UX Project Manager - Maps
April DiMartile  UX Design - Maps
Michael McDaniel  Engineering Manager - Maps
Ian Dimayuga  UX Engineering - Maps 
Christine Nguyen  UX Writing - Maps
Sarah Kiner  UX Design - Fitbit