Wellsmith, Smart devices pairing

Remote on-boarding, Internet of Things, Packaging

Wellsmith is a digital healthcare platform to engage participants with chronic diseases in their health, focusing in Type II diabetes. The care team prescribes n specific care plan to participants in terms of glucose check in, weight check in, medication and steps. The compliance of the care plan monitored through smart devices: Glucometer, Weight scale and an activity tracker on the app side.  

Based in learnings from the previous WS product (from trials) we knew that the pairing process was one of the biggest pain-points in the experience, we also knew that the success rate was low due to the complexity of the process and that user's felt deeply frustrated by the lack of guidance. 
One of the biggest challenges at Wellsmith has been to design a remote on-boarding experience that allows the business to scale while providing an intuitive experience of device pairing and syncing process. Considering that the target group tends to be low-tech savvy it was essential to be guiding and clear in each step of the process. We worked through multiple iterations of the remote on boarding experience, starting with low fidelity prototyping until reaching the full developed app, including also package design and printed instructions design. 
The problem 
Wellsmith provide to their participants a glucometer, weight scale and activity tracker of random brands, what means that there is not an standard procedure of pairing or consistent branding, each device works rather different. 

To pair a smart device successfully the device must to be looking for the phone and the phone for the device at the same time what makes it a very time-sensitive process due to smart devices short searching process. The user requires to be aware of the phone and the device at the same time in a very specific moment to accept the phone prompt to pair, this is very challenging because participants tend to focus in either the device or the app. 
Final design
After multiple iteration loops and testing sessions this is the final workflow for the glucometer case. According to the device the instructions screens change. The workflow includes sound and vibration when the device is found to call participants attention back to the phone. Also it comes back to instructions if the pairing fails, since we found that the main reason for it to fail is the device not been actively looking. Finally, we use big buttons to make it a more guiding experience as well as some illustration for a friendlier feeling. . 

Methods and tools 
Low fidelity wireframing and prototyping: 
The basic functionality of the connection process for any device was defined in the wireframing, representing an holistic perspective of the flow's goal. The most relevant UX feature in this flow is the "auto-discovery", where the phone is looking for the smart device even when the app is a different screen (e.g.instructions) this way we could extend the time the phone looks for the device and therefore maximize the success rate of the pairing. I linked the screens in sketch to socialize and iterate couple of times with the product and development team. 
Medium fidelity wireframing and prototyping: 
This iteration considered the design of specific instructions per device, along with a different behavior for iOS and Android due to how bluetooth works on each one. In iOS the phone continues searching for the smart device even if it had already found one, so there is a case where multiple devices of the same type could be found. On the other hand, Android only recognizes one device and prompts the user with that one to be paired. 
Also this medium fidelity considered different use cased for error or success dialogs, and the integration of the connection process in the on-boarding experience and the more menu of the app low navigation.  
High fidelity prototyping 
The next iteration integrated a new UI visual style, UI transitions, copy editions. Covering also some differences betwen iOS and Android. Screens done in sketch, prototype in inVision. 
User testing: 
Test structure
To validate the design of the device pairing in the context of migrating participants from the old app to the new one we carry out user testing sessions with 9 participants. The recruitment was done by a local marketing agency based in user's demographics. 

Considering that the full app was not ready for the testing we complemented some part of the real app with a prototype. The test also considered  paper instructions to support the participant to success in steps not considered in the app (e.g. remove Accu-Chek from the phone). The instructions considered additional steps for iOS users dictated by development limitations. 

Due to be a startup we planned the test to include a phase of user research as well as input for future features and also an evaluation of an raw design in paper prototyping. 

Data analysis: 
The qualitative data collected during the test was analyzed through an affinity map and triangulated with the qualitative data. The latter specifically measured easy of use and clearness of the instructions. 

Insights: 
Through the testing we learnt that: 
- Users who have been living with Type 2 Diabetes for a long time rely on intuition and personal experiences for lows and highs management. While recently diagnosed users are still getting familiar with management techniques. 
“When I was first diagnosed, I would eat something and then check it two hours later.” User 4
“I didn’t know total carbs is what I am watching” User 7
- Users familiar with Bluetooth pairing were confident about going through the process, while low tech savvy users felt out of their comfort zone. The lack of familiarity with technical jargon contributed to the confusion. 
“It looks like every other manual, very straightforward” User 5
“I just quick start and go” User 7
“I am thinking this is a pretty lot of information” User 4
“I think I don’t have the Bluetooth” User 3
In terms of usability issues the first pattern to appear were inconsistencies between the paper instructions and the phone instruction that caused confusion about the pairing process. We iterated the design on the go what improved user's perception on the clearness of the instructions. What is clearly showed in the box plot on the right.
Additionally we found out that: 
- Users struggled connecting the Garmin to the charger. Also Users had difficulty identifying whether the Garmin screen was charging or active. The screen is small and the instructions were not clear about the feedback change. 
“I am not sure if it is connected” User 7
“You guys should put an image on the instructions that let me know when it is on.This was not clear to me.” User 7

- Some users were unaware or forgot that they needed to use the phone to finalize the pairing process when their full attention was on the devices.
“I think there should be a reminder to use your phone” User 8
“I only figured it out because I know what to do.” User 7
- No user friendly time picker for Android

We also had some positive findings like: 
- Users appreciate the step by step instructions. All users relied on the printed instructions until they downloaded the app.Once the app was downloaded, they transitioned to the mobile instructions. 

- There was a high success rate. All iOS users were able to remove the Accu-Chek from the phone and the phone from theAccu-Chek. Low tech savvy* user struggled with deleting and downloading and app (left graph)

- The overall process was perceived as medium to easy process, considering the complex nature of the test it is a good indicator (right graph)
More wireframing, prototyping and testing.... 

You may also like

Back to Top