Roughly 10% of the US population or about 3.5 million people have diabetes. Majority of them struggle with managing their diabetes care as it requires a constant reminder to check your glucose levels, manage food intake and take your insulin shots as needed. And keeping track of all your care when you are discussing it with your Primary Care Physician can be quite a daunting task. Bigfoot's Unity iOS X app resolves those issues by providing the complete solution for your diabetes self-care.
I was the Principal Designer on the Bigfoot Unity iOS App. Roles & responsibilities included:
Another aspect of this was learning to design for the 510k FDA submission process. All designs and iterations had to be tracked throughout the entire process and testing of each critical task had to be documented as well. The 510k submittal process is like providing tax documentation for medical devices/apps to the FDA and includes the following:
Additionally there were challenges with technical feasibility. Our app was integrated with four devices (Long-acting Cap, Rapid-acting Cap, Blood Glucose Monitor and CGM Sensor) that were manufactured externally and had their own restrictions based on their UI frameworks. So while I collaborated with iOS Engineers to build out the app, I also had to be in sync with Hardware Engineers so I could design the flows/UI for those devices within the framework guidelines. Things like pairing devices (via Bluetooth) with the iOS app required users to go back and forth in the setup experience.
Our app was divided into 2 primary sections/flows, (1) Onboarding Use and (2) Ongoing Use. The Onboarding Use flow started off with the basic account setup and verification. With the addition of the tasks to pair the devices and inteject introduction videos, device videos and knowledge checks) as required per our medical SMEs, it quickly ballooned into a ~15-20 minute waterfall setup process. And to make things worse, engineering was unable to save states so if you stopped halfway through the setup process and exited the app, you would have to start all over again!
Usability findings confirmed that this setup was too lengthy with a >60% failure to complete rate. Our older candidates became flustered with the amount of information required and time needed to complete it. They kept asking if it was possible to stop halfway and come back and complete the sections at a later time when they had more information or if they could skip certain sections until later.
Before image shows the existing Onboarding flow architecture. Unless the user completed each phase, they were unable to advance to the next step. After image shows the redesigned Onboarding flow which was updated after few lengthy discussions with Engineering and Medical SMEs. We pushed back on the waterfall approach and hard requirements from Medical SMEs to make "Learnings" mandatory. Also, Engineering was able to provide a venue for saved states (cloud) with some additional effort. Instead, the compromise was that the "Learn about Bigfoot Unity" section became optional but available on the main menu. Furthermore, users could save their progress and come back to it at a later date.
After making the changes, our failure-to-complete rate dropped to less than 10% and the reasons were not related to the length of the onboarding process.
One of our most prominent, most used sections and at the same time the most difficult-to-design was the History section. This is where users could see all of their information under one roof:
As I mentioned we were integrating 3rd party devices with their own limitations. One of the challenges in designing this data visualization was that devices provided data at different intervals. Also, some of the devices were for active monitoring (CGM), providing data to the app every 15 minutes and some devices such as the BGM, LCAP, and RCAP required user interaction to provide data.
After spending many hours discussing, brainstorming and whiteboarding with feedback from Product and Engineering, I came up with the initial concepts of the History graph view. Below is a design journey of the History graph which was tested and refined over several months to get it perfected.
For the 510k submittal process, one of the requirements is around risk assessment of critical tasks. You have to provide data showing at least 95% success rate with 10-12 participants for critical tasks. One of Bigfoot Unity app's critical task involved allowing users to be able to review their alerts (iOS Notifications), understand the request to act, launch the BF App and complete their task at hand.
It took approximately 2 months and multiple iterations along with rounds of user testing to get to this 100% success rate flow (below). We mostly had issues with users not knowing what to do when they got to the History screen. I tried to design several different layouts, flipping the order of the devices to below and graph on top but people still missed it. It wasn't apparent until we had to implement an error version of the screen highlighting in red which particular device needed their attention. By clicking on that device, they would go to the list view showing when they were suppose to take the dose (according to their plan) and act upon it (take the shot or mark it as done).
For each feature/release cycle, one of the last things I did before submitting it for internal reviews to all key stakeholders was to verify all the content/terminology with our Medical SMEs and fix any feedback.
Along with the final screens, I put together finalized Sketch Artboards which included the interaction details, various states + associated content and flows to Engineering. There would a formal review by key stakeholders (Product, Engineering, Medical, Compliance, QA, Content) and the final Sketch Artboards would be circulated via our wiki for formal approval. Once all the stakeholders approved, it would be submitted to our internal portal where all artboards were stored along with their previous versions. For each iteration of the artboard, we had implemented a revision history and highlight of what changed in each iteration.
There were 2 sets of prototypes which I maintained and updated depending on what we were testing for. The Invision prototype was used to validate ideas internally or for the dev teams to understand the flows. The full mobile app was built in the high-fidelity Axure prototype and was used specifically for user testing.
Most of my designs were put together with standard components from the most current version of the iOS UI Kit for iPhone X. Once we had finalized the layouts and visuals, I created a separate artboard of custom components. Additionally, there was a general style guide created with defined colors and basic styles.
