GlucoGuru

I dived deep into medical research to understand the different types of diabetes. Only once I understood the diabetic types and methods of treatments, I could understand the reasoning behind the existing diabetic care apps in competitor market research. Often, within the same company, they offered multiple tracking apps, each app serving a different purpose. Potentially, a diabetic user could have to utilize several apps, depending on their particular treatments.

Interviews with three participants revealed that users utilized mobile apps to deal with everyday tasks. They liked when it was easy to get things done with apps directly and quickly. They disliked when entering data was tedious or didn't save a record to look back upon. When it became a bigger chore to upkeep than provided value, they dropped the habit.

Many Type 1 diabetics were diabetic since childhood and wore CGM Continuous Glucose Monitoring systems in addition to insulin pumps to maintain their glucose levels at a safe and constant level. Some Type 2 diabetics and pre-diabetics were able to reverse their diagnosis through diligent behavioral changes of testing blood sugar levels, exercising and eating healthy or taking lowering blood sugar medication. Most gestational diabetics were no longer diabetic once they delivered the baby but had to maintain pricking their fingers for glucose level testing and logging their food intake four times a day.

In spite of their differences, their likely common problem?

I explored with a 5 Why's analysis to help get to the root cause of a diabetic’s problem and uncover blindspots, tease out assumptions, and ultimately help solve their problems

With the initial problem of helping diabetics see improvement,  I reversed the problem to focus on blockages that prevent diabetics from managing their illness, as horrible as that sounds! By looking at ways the problem could get worse, I was able to concentrate more on the user and their needs to identify solutions more easily.

I then took the identified solutions and put them on an impact/effort matrix. Imagining impact from the user's perspective, and imagining effort from a developer's and project manager's perspectives. This is also where partnerships and collaborations with other apps and devices would also prove pertinent on GlucoGuru's development.

Even though some features laid out in the high effort with low impact grid, to explore the project scope in an ideal, no-cost, exploratory way, I wanted to see how far the connections could and should go.

Although there were different types of diabetes and different types of treatment, one thing that remained constant was that diabetes needed incessant monitoring. Everyday. Several times a day. Often more than one area of concern. This could lead to a very obtrusive experience.

An end to end application often starts with a tedious onboarding passage. Added to the constant persistant logging on potentially different apps, I imaged a diabetic’s daily routine to moniter their symptoms to be quite tedious. It would be dangerous for their health if they dropped their habit because they got too annoyed with the incessant logging.

Then I built out the user flow thinking about the choices the user would be faced with while chatting with the Bot. Since a lot of the app was seemingly contingent on the amount of partnerships to integrate apps and devices, I needed to make sure I not only gave the user the option to share data, but also manually log data in seamlessly.

I then set up the site map, working off the previous research. I originally had imagined the Bot as a separate icon on the dashboard with a chat history and ask a question feature. But thinking back to the relationship the participants had with their apps from my interviews, I had to face the fact that they wanted to get in and get out. The novelty would quickly wear off and the users wouldn’t want to waste time chatting with a Bot.  I couldn’t have the correspondence with the Bot be the primary focus of the app.

The primary focus of the app should be logging in data for a clear record. To understand triggers, gain insight and predictions. The Bot should helpful and informative but also just be in the background and not a separate entity. Like an app. The Bot was the app.
‍

I wanted to identify our Bot's personality in order to write the copy for the app in a humanistic way and make it more engaging to interact with. I wrote out the Bot’s role and job title, created the job description for the position.

I chose a name, selected the sex and age, sketched a thumbnail biography, visualized, and then I took a Myers-Briggs Type Indicator test from his perspective to finally bring him to life. The results from the indicator test was spot on amazing what I had envisioned for our Bot!

I playacted the interaction between the user and the GuruBot and fleshed out the verbiage on a script. I visualized the GuruBot guiding the user through the onboarding process and also a return sign in visit.

I then built out digital mid fidelity wireframes. I wanted to introduce the app as the chat frame already with the Bot, and not have an additional chat window within the app. Sort of like Apple's Siri. I explored how to display interaction with the Bot after signup and signin. Embedding it into the app background and as popup modules the user could swipe away.

I read up on the most usable "hot spots' for touch phones.  Originally, hot spots were towards the bottom corners of the screens where users thumbs could reach. But with the evolution of phone sizes, it's now closer towards the middle of the phone where the hand gripped the phone. With that in mind, I explored dashboard ideas on how to display GlucoGuru’s many categories.

From the research interviews, nine visual designs of trending apps were shown to the participants and asked which look they preferred for a health tracking app interface. All three selected a neumorphic design.

I updated the digital wireframes with a version of neumorphic effect the participants had liked, while trying to keep it as legible as possible with deeper outlines and shadows since neumorphism has been criticized for readability. It ended up creating more of a skeuomorphic effect instead.

So I went back and softened the UI for a more true neumorphic design, added micro interactions of button presses, and prepared to A/B test the two designs in a high fidelity prototype usability test.

I moderated an animated high fidelity usability test in person and remotely for three participants.

The goal was to determine if users could:

All three participants were able to complete the tasks, but not exactly how I had envisioned it. No one even attempted utilizing the voice control function, preferring to tap on the buttons instead. I had kept the dashboard empty at first entry, wanting to give the options of tap to type and hold to speak a chance to be prioritized and used, but it just wasn't intuitive enough at first sign in. Users also didn’t process that the app could help them through next steps such as adding ingredients of a recipe to their shopping cart, or ordering delivery. While they later appreciated the helpful purpose of the option, they considered logging an entry completing their needs already.

Onboarding- Introduce Mies as the GlucoGuru Bot. Clarify button outline. Add option to skip questions.

Create a dark mode and work on responsive platforms including a watch interface. Test, iterate and repeat.

It takes a lot of deeper research to really understand the landscape and the user's needs on unfamiliar territory. It's tempting to jump right in to design with surface briefings, but knowledge is key. Reading competitor app reviews to see where they had user frustrations, reading personal blogs on a target user's lifestyle really helped immerse me in a diabetic's day to day.

Another learning is that, even with the best intention in feature prioritization, it maybe too much for a user to comprehend and learn all at once. Making sure they have a strong fallback option that they are familiar and comfortable with is important.

Also something to try to avoid is feature creep. I had hoped to connect the dots for the user to have an all in one app platform. Rolling out bit by bit and testing what they needed next would be better for future growth.

A cross functional team would be essential in creating a product of magnitude. Marketing team to test and weigh in on Mie's personality. PM's and upper management to gain the collaborations with integration of other apps and devices. And of course, Developers to implement the design.