ROLE

UX/UI Designer, with mentor and peer review.

Project Background

Google Aria is a product that allows people with diabetes to better manage their disease. Aria aggregates information about the users condition through a combination of a wearable patch and third party app data, to help the user make better decisions regarding their health. The mission for this project is to create an app that helps people better manage their diabetes while adhering to Google’s material design principles.

Objectives

1. To create an app that adheres to Android design principles.

2. Following current Google material design guidelines.

3. That makes managing diabetes a seamless experience.

Secondary Research

Starting with Market Research, I spent time familiarizing myself with the state of diabetes in the US. I have a bit of familiarity with the disease as it runs in my family, but I approached my research with some of these questions in mind: what is diabetes? Who does it effect? What is the current market for diabetes management apps? As well as what Google Aria might do to differentiate itself in the marketplace.

Some statistics about diabetes:

1. In 2015, 30.3 million Americans, or 9.4% of the population, had diabetes.

2. Of the 30.3 million adults with diabetes, 23.1 million were diagnosed, and 7.2 million were undiagnosed.

3. 1.5 million Americans are diagnosed with diabetes every year.

4. In 2015, 84.1 million Americans age 18 and older had pre-diabetes.

5. Diabetes remains the 7th leading cause of death in the United States in 2015

Diabetes management:

1. Among adults with diagnosed diabetes, 17.2% take insulin only, 15.1% take both insulin and oral medication, 50.6% take oral medication only, and 17.1% do not take either insulin or oral medication.

2. To survive, people with type 1 diabetes must have insulin delivered by injection or a pump.

3. Many people with type 2 diabetes can control their blood glucose by following a healthy meal plan and exercise program, losing excess weight, and taking oral medication.

4. Medications for each individual with diabetes will often change during the course of the disease.

5. Self-management education or training is a key step in improving health outcomes and quality of life. It focuses on self-care behaviors, such as healthy eating, being active, and monitoring blood sugar.

6. Many people with diabetes also need to take medications to control their cholesterol and blood pressure.

To determine how Aria can compete with current diabetes management apps, I looked into direct and indirect competitors and then conducted a Competitive Analysis on their strengths and weaknesses. This allowed me to gauge the efficacy of these competitors whether they were a wearable device or a mobile app. The main takeaway being to learn which features were expected in these tools and what makes a user chose to use or not use them.

Primary Research

With market and competitive research under my arm, the next step of my research involved conducting 1-on-1 Contextual Inquiry Interviews with potential users.

I was able to speak to 5 diabetics; 2 female and 3 male, between the ages of 19 & 41. These interviews were all conducted remotely. I had to deviate a bit from my initial plan as I thought to interview older diabetics. However, upon further research and conversation I discovered that this demographic does not use technology to manage their diabetes. So, I had to adjust my assumptions and target a younger demographic.

Some things I learned:

1. Most tracked - blood glucose, carbs, sleep, & exercise religiously.

2. Most felt alone in their daily struggles with diabetes.

3. Most were frustrated with how much there was to manage with their diabetes.

View the full Interview findings here

Empathy Map

I took the data I uncovered from user interviews and constructed an Empathy Map in order to identify patterns that emerged between different people. This allowed me to keep a human-centric view of the product as I further examined diabetics.

From the empathy map I was able to distill down my interviews into common patterns categories and then patterns amongst the interviewees, and then further distilled those down into insights and their needs as follows:

INSIGHTS

1. Sleep/Carbs/BG/Exercise tracking is key in management.

2. Diabetics feel alone with their disease.

3. Diabetics are frustrated with how much there is to do with managing their disease.

NEEDS

1. Diabetics need to accurately track their vital information.

2. They need to feel supported in their lives as diabetics.

3. Needs their technology to provide useful data.

User Persona

After identifying those insights and needs, I was able to create a User Persona to represent what the ideal user of Aria would look like look like. Giving the data an identity with context and personality, helped me empathize with the customer as I built features to suit their needs. So, let me introduce you to Martin - a busy photographer in his early 30’s, who is motivated by a life free of worry to himself and those he loves, and who doesn’t want his diabetes to get in the way of that life.

Point of View / How Might We?

To take this a step further, I crafted Point of View (POV) Statements and How Might We? (HMW) Questions to empathize with the problems at hand from Martin’s point of view and create questions that would help ideate solutions to Martin’s most pressing needs.

Project Goals

Before approaching the task of creating solutions for the above persona and addressing their pain points with an app and features, I found it helpful to combine the project goals, by examining the Business and User Goals individually, and then seeing where they overlapped. The shared goals gave me a way to assess what the best features to move forward with are.

Product Roadmap

With the product goals defined, I was able to create a Product Roadmap that listed all of the different features that would satisfy the business and customer needs - ranked in order of priority based on development time and cost.

App Map

Everything I learned from the product goals and product roadmap went into creating the Sitemap for Spotify. I included the various proposed web pages and structured them in such a way that helped me visualize what the eventual app would look like and how the basic navigation would be.

User Flow

With the site map charted out I moved on to the initial stages of prototyping by creating a User flow & Task flow.

USER FLOW

The user flows I devised took a look a look at Martin’s journey through the app from 3 different points of entry.

1. Setting up his Aria device for the first time.

2. Filling out his profile after setting up his device.

3. Moving on to the dashboard to get a glimpse of his heart rate for the week.

Note: While the profile can be edited on it’s own as a feature, you can initially set it up during on-boarding.

Task Flow

For Martin’s task flow, I expanded on the above scenarios and took a look at what they might look like given Martin’s own decision making process. This let me get a more empathetic view into how the app might be used.

UI Requirements

Using these flows and the and the features roadmap from earlier, I created a UI Requirements document that listed out the exact screens that I would need to build and all the elements to include on them

View the full UI requirements document here

Low-Fidelity/Sketches

Next. I moved onto designing the page. I created low fidelity sketches of potential layouts as a way to visualize different design directions before committing to the ones to use based on Spotify patterns.

Mid-Fidelity

WIREFRAMES

After sketches were done and I had a better idea of what screens to create, I started to build mid-fidelity wireframes based on the main screens that the app needed to have.

PROTOTYPE

Using InVision, I them used these wireframes to build the prototype on which I was to test my tasks and see if the usability of the app and it’s features were up to par before building out high-fidelity wireframes.

View the full Prototype here

Style Tile

Before implementing the feature recommendations into a high-fidelity wireframe, I set out to create the UI design and visualization of the elements on the Aria app. Using the inspiration I collected on a mood board, I put together a Style Tile that defined the final colors, fonts, and other elements that would make up the visual look of the final app.

I based these UI decisions following Googles current branding guidelines, and following their material design guidelines.

High-Fidelity

Then I built a high-fidelity wireframe & prototype based on the recommendations I uncovered in testing and on the affinity map.

Some of the main revisions I made to my high-fidelity screens are below:

And some other high-fidelity screens:

Prototype

I then built a High-fidelity Prototype using the high-fidelity wireframes and the testing I conducted on them. I used InVision to create the prototype taking into account changes in UI and functionality that were implemented.

View the high-fidelity prototype here

UI Kit

Finally, I prepared a UI Kit using the elements I included on the high-fidelity prototype. This guide includes all colors, font sizes, icons, and other graphic elements that the Aria app is built out of.

User Testing

Using the mid-fidelity prototype of the Aria app, I set out to test the features I came up with the product roadmap. However, I first outlined the objectives, goals, and procedures in a usability testing plan, which served as a guide during testing sessions.

View Testing Plan here

I tested the prototype with four people - 3 diabetics and 1 non-diabetic individual - where they were asked to complete the following tasks within the prototype:

TASKS

1. You’ve just purchase an Aria device and have downloaded the app. You need to set it up.

2. Find the heart rate widget on your dashboard, and find out what your heart rate for the week was like.

3. Find the checklist page and mark the first four tasks.

4. Go to the medication page and check off that you took your morning medicine.

For the most part, users completed the tasks easily and weren’t overly confused with aspects of the app. Most of the concern revolved around the simplicity of the tasks - testers were eager to see something more complete.

Affinity Map

Using the notes taken during testing, I created an Affinity Map composed of individual user thoughts and observations - one to a card. I looked for patterns between the testers, and distilled them down into key insights and finally recommendations of revisions to make based on user testing.

Key Takeaways

1. Be wary of feature-creep

   Being an app that served a specific demographic (while also integrating with a lot of tools that demographic uses) it became very easy to want to build everything I could possibly thing of. It became important to keep things simple and consider cost, time, and importance when making decision. I need to remember to trust the research and stick to what I learned from users.

2. User testing is critical

   It was a bit of a challenge to find diabetics when it came to user testing, but even with so few participants - so much was uncovered. It because very apparent that what was uncovered in research and initial user interviews; speed and convenience being crucial, was in fact crucial. In a lot of ways Aria’s competition isn’t other apps or devices, it’s the user themselves. People who’s entire lives are consumed by managing this disease and who have a lot to lose if they’re not diligent and precise. So empathy and putting the human mind at ease is critical for Aria’s success.