Formulation of an effortless user 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.
... as simple as talking to a friend.
What if I designed a platform that was as easy as talking to a friend? A companion that cheered the user on as they logged about their mundane routine? A smart AI chatbot that coached with intelligent feedback fed by user data? That connected the dots to take actionable steps and complete tasks on demand? I started formulating a minimal effort app that could support, provide insight and evolve with its user.
I mapped a taskflow showing a Bot guiding a new user through onboarding, then requesting permission to pull and share data from other apps and devices, which in turn could reveal enough data for the Bot to interpret and assist in tasks.
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.
Building an identifiable Bot personality
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!
Intelligent and warm, full of passion, genuine and caring. Motivates with infectious enthusiasm.
The app would be as it’s GuruBot. Helpful, dependable, cheerful and encouraging.
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.
Once I had the scripts in place, I designed into them, exploring how best to display the data and actions available to the users. I wanted to optimize functions of the phone, like speaking to Mies through the phone’s microphone. Swiping to minimize dashboard and screens that the user didn’t want to read. Utilizing the camera to take a snapshot record of food intake. Accessing their location to find closest grocery stores and restaurants to help place an order. Connecting the user and all their diabetic utilities in one app.
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.
I originally liked the arc design idea as it gave the most visual impact but unfortunately was not effective in relaying necessary text. The double stacks of icons seemed user friendly but was also so static and potentially hard to scan. The long row of icons were simple but impactful, and prioritizing the four main categories- glucose, diet, meds, and activity would be easy to create a hierarchy from top down.