Easing the daily burdens of diabetes

gluCal was a project birthed from my own frustrations using insulin calculators that didn’t work well. Over summer 2024, my partner and I set out to bring a redesigned, better experience for everyone who uses insulin therapy.

Timeline

Timeline

Mar - Apr 2024

Mar - Apr 2024

Role

Role

Sole designer

Developer

Sole designer

Developer

Team

Team

1 designer

1 developer

1 designer

1 developer

skills

skills

Product design

User research

Prototyping

Mobile dev

Product design

User research

Prototyping

Mobile dev

Timeline

Mar - Apr 2024

Role

Sole designer

Developer

Team

1 designer

1 developer

skills

Product design

User research

Prototyping

Mobile dev

The problem

75 million people worldwide inject insulin daily.

This involves counting carbohydrates and calculating personalized doses, every time they eat.

5+ times a day. Every. Single. Day.

Source: National Center for Biotechnology Information

Source: National Center for Biotechnology Information

Despite being a daily task, there’s no straightforward tool that simplifies insulin calculation elegantly.

The process is tedious, monotonous, and complicated. No one wants to do math before each meal! Existing tools are either frustrating to use, or don’t address the specific need.

The Solution

gluCal: The all-in-one calculator and log to simplify insulin dosing

gluCal is a mobile app for users who prefer a simple tool for managing diabetes. It focuses on essential functions only: calculating insulin doses, logging insulin, and tracking food intake.

A quick look at the final product...

The app is split into three main functionalities, each targeting one need.

  1. Insulin Calculator

Users input their current glucose levels and carbohydrate intake then select a carb ratio. gluCal then calculates the recommended insulin dose based on their personalized settings, which can be adjusted at any time. Users can also log specific foods along with the carb count.

  1. Insulin Log

All insulin calculations are automatically stored in the insulin log. Users can also add logs manually from this page for doses taken without using the calculator for more flexibility.

  1. Food Diary

The food diary logs all food items entered through the insulin calculator to help users track their diet alongside their insulin intake. Users can also create a food diary entry directly from this screen.

research

To start, I conducted 3 user interviews with people with Type 1 Diabetes, and identified 2 main pain points.

User Interviews

“The app I use right now [to calculate insulin doses] is janky and frustrating ... I deal with it because I have to”

“I’ve tried a bunch of fancy [diabetes] management apps in the past but I’d always … give up after a week”

Pain points

  1. Poor UX design leads to an unsatisfying and frustrating experience

  1. Overly-complex apps that try to be a comprehensive management tool cause overwhelm and low retention

From this information, I asked:

How might we make calculating insulin doses easier and less frustrating for people with diabetes?

How will we stand out from existing products?

I conducted a competitive analysis and discovered that existing solutions varied along 2 key spectrums: visual design and scope.

A competitive analysis highlighting gluCal’s unique advantage.

Direct Competitors

T1D1: Basic Type 1 diabetes app with insulin calculations and food logging, but lacks visual appeal.

GlucoLog RapidCalc: Advanced insulin calculator with complex inputs, limited to Europe.

MySugr: Comprehensive diabetes management tool with bolus calculator, but not available everywhere.

Indirect Competitors

Glooko: Cross-platform app for syncing and analyzing diabetes data, used by patients and healthcare providers.

Diabetes:M: Multifunctional app for all diabetes types, with treatment tracking and data import from devices.

From this research, I concluded:

Existing diabetes tools excel in various areas but often fall short for users seeking a simple, focused solution.

gluCal aims to fill this gap by providing a straightforward, specialized tool for insulin calculations, catering specifically to those who need simplicity without the complexity of broader management systems.

Design

I started off by exploring different layouts and mapping out the basic app structure on paper.

Initial variations of the insulin calculator screen layout (I ended up going with something very different)

More early lofi wireframes of the insulin log (top) and settings (bottom)

DESIGN DECISION #1

How do we show that logging food is associated with the carb count input?

Users have the option to log the food they’re eating when calculating insulin. If a user logs food, the carbs input field is automatically filled with that information.

The “log food” button needed to appear 1. optional and 2. associated with the carbs input field.

Users have the option to log the food they’re eating when calculating insulin. If a user logs food, the carbs input field is automatically filled with that information.

The “log food” button needed to appear 1. optional and 2. associated with the carbs input field.

Users have the option to log the food they’re eating when calculating insulin. If a user logs food, the carbs input field is automatically filled with that information.

The “log food” button needed to appear 1. optional and 2. associated with the carbs input field.

  1. Attached, outline

  1. Attached, solid

  1. Separate, outline

  1. Separate, solid

  1. Attached, outline

  1. Attached, solid

  1. Separate, outline

  1. Separate, solid

Perceived optionality

Association to carb input

Iteration 1

Attached, outline

The outlined version and unique shape creates a lower visual hierarchy, signaling optionality

Positioning makes it appear related to the carbs input, but the connection is unclear

Iteration 2

Attached, solid

Positioning behind the carbs button sets it apart, but unclear optionality without the “optional” label

Positioning makes it appear related to the carbs input, but the connection is unclear

Iteration 3

Separate, outline

Outline differentiates it from mandatory fields, but the shape is the same

Positioned separately from the carbs input field, no evident relation

Iteration 4

Separate, solid

Lacks clarity as an optional field without the “optional” label

Positioned separately from the carbs input field, no evident relation

However, during interviews, users still expressed that the relationship between the carbs and food log were not clear - it still seemed like a separate process from inputting carbs.

One user suggested to nest the button within the carb input field. When the button is nested within the field, it visually indicates that the log food action is part of the carbs input process, rather than a separate action that is simply associated with carbs.

Final design:

Log food nested button iteration - the one I ended up choosing!

Iteration 5

Nested button

Perceived optionality

Outlined button creates lower visual hierarchy, signaling optionality

Association to carb input

Nesting conveys the button’s exact relationship to carbs: logging food is an optional way to input carbs

Perfect! This was a great solution that I would not have come up with without the help of user feedback!

Final design:

Log food nested button iteration - the one I ended up choosing!

Iteration 5

Nested button

Outlined button creates lower visual hierarchy, signaling optionality

Perceived optionality

Nesting conveys the button’s exact relationship to carbs: logging food is an optional way to input carbs

Association to carb input

Perfect! This was a great solution that I would not have come up with without the help of user feedback!

DESIGN DECISION #2

What would it look like to log multiple food items at once?

When logging food from the calculator, an intermediate screen appears that stores all the food the user is logging. I explored two different approaches for the food input form that appears after they click “Add Item”.

A modal with the food input form

Iteration 1: A modal that overlays the list of logged foods

Elevation

One level above previously-logged items

Clearly separates the current food item from the list

Might be confusing to track multiple layers since the previously-logged items is already an overlay

Exiting from the form

Two ways to exit the modal without adding food:

  1. X button at top left

  2. Clicking outside the modal (aligns with exiting modal design)

Alignment with existing mental models

Modals are a common UI pattern, making this interaction highly intuitive for users.

Content overflow

Since the modal is fixed, content is accessible without scrolling

Visual experience

The design is standard and unremarkable

Iteration 2: A slide-down panel that reveals the food input form

Elevation

Same level as previously-logged items

Easier to manage with fewer layers

Less clear separation between the new and previously-logged food items, which might cause confusion

Exiting from the form

No clear option to exit the food input form without adding an item. Clicking outside the form is not intuitive

Alignment with existing mental models

This approach deviates from standard UI conventions which could lead to confusion, particularly for users who aren’t as tech-savvy

Content overflow

Once the food list gets longer, users will need to scroll to access the food input form

Visual experience

The smooth animations and unique design make the app more engaging and add delight

A slide-down panel with the food input form

Iteration 1: A modal that overlays the list of logged foods

A modal with the food input form

Elevation

One level above previously-logged items

Clearly separates the current food item from the list

Might be confusing to track multiple layers since the previously-logged items is already an overlay

Exiting from the form

Two ways to exit the modal without adding food:

  1. X button at top left

  2. Clicking outside the modal (aligns with exiting modal design)

Alignment with existing mental models

Modals are a common UI pattern, making this interaction highly intuitive for users.

Content overflow

Since the modal is fixed, content is accessible without scrolling

Visual experience

The design is standard and unremarkable

Iteration 2: A slide-down panel that reveals the food input form

A slide-down panel with the food input form

Elevation

Same level as previously-logged items

Easier to manage with fewer layers

Less clear separation between the new and previously-logged food items, which might cause confusion

Exiting from the form

No clear option to exit the food input form without adding an item. Clicking outside the form is not intuitive

Alignment with existing mental models

This approach deviates from standard UI conventions which could lead to confusion, particularly for users who aren’t as tech-savvy

Content overflow

Once the food list gets longer, users will need to scroll to access the food input form

Visual experience

The smooth animations and unique design make the app more engaging and add delight

Based on the comparison of these metrics, iteration 1 is the clear top choice.

DESIGN DECISION #3

How should we structure the data synchronization of the insulin log and food diary?

When a user logs food with their insulin calculation, two logs are created: one in the insulin log and one in the food diary. These logs are connected by carb count data.

But what if the carb count is changed later in one log? Does the change sync with the other log? And if it does, does the associated insulin dose update too?

To inform this major structural decision, I considered two core values I wanted to maintain for gluCal:

Simplicity

The user interviews informed us that the app should be intuitive and easy to use. Managing diabetes is hard enough — the point of gluCal is to help its users do LESS thinking, not more.

Flexibility

Real life is messy and things don’t always happen how we plan them to. Sometimes people eat without taking insulin, even when they’re supposed to! Thus, gluCal should be as flexible as possible.

Separate carb counts across the insulin log and food diary keep gluCal straightforward. Users can manage their entries without the app trying to auto-sync data.

Separate carb counts allow users to update each log independently, which accommodates for unexpected changes. This approach gives users more control.

A note on technical constraints

For this decision, we also had to consider technical constraints. gluCal uses a single database with two separate tables for insulin logs and food logs. Syncing the carb count between these logs and updating other information would be technically complex.

For these reasons, we opted to keep the carb counts separate across logs.

To inform this major structural decision, I considered two core values I wanted to maintain for gluCal:

Simplicity

The user interviews informed us that the app should be intuitive and easy to use. Managing diabetes is hard enough — the point of gluCal is to help its users do LESS thinking, not more.

Separate carb counts across the insulin log and food diary keep gluCal straightforward. Users can manage their entries without the app trying to auto-sync data.

Flexibility

Real life is messy and things don’t always happen how we plan them to. Sometimes people eat without taking insulin, even when they’re supposed to! Thus, gluCal should be as flexible as possible.

Separate carb counts allow users to update each log independently, which accommodates for unexpected changes. This approach gives users more control.

The Final Product

Lo and behold… gluCal, the all-in-one insulin calculator and food log

  1. Insulin Calculator

Users input their current glucose levels and carbohydrate intake then select a carb ratio. gluCal then calculates the recommended insulin dose based on their personalized settings, which can be adjusted at any time. Users can also log specific foods along with the carb count.

  1. Insulin Log

All insulin calculations are automatically stored in the insulin log. Users can also add logs manually from this page for doses taken without using the calculator for more flexibility.

  1. Food Diary

The food diary logs all food items entered through the insulin calculator to help users track their diet alongside their insulin intake. Users can also create a food diary entry directly from this screen.

  1. Insulin Calculator

Users input their current glucose levels and carbohydrate intake then select a carb ratio. gluCal then calculates the recommended insulin dose based on their personalized settings, which can be adjusted at any time. Users can also log specific foods along with the carb count.

  1. Insulin Log

All insulin calculations are automatically stored in the insulin log. Users can also add logs manually from this page for doses taken without using the calculator for more flexibility.

  1. Food Diary

The food diary logs all food items entered through the insulin calculator to help users track their diet alongside their insulin intake. Users can also create a food diary entry directly from this screen.

Next Steps?

Now that the design of gluCal is done, my project partner and I are building the app in our free time! We aim to release it in the app store and share it within Type 1 Diabetes communities at my school and online. I’m super proud of this product — it’s something I would use myself, and something I wish existed when I was first diagnosed back in 2020.

I hope that gluCal can bring a modicum of simplicity to the complex, confusing, and often frustrating journey of living with diabetes, and make managing it just a little easier.

User Interview

“The app I use right now [to calculate insulin doses] is janky and frustrating ... I deal with it because I have to”

Pain point

  1. Poor UX design leads to an unsatisfying and frustrating experience

User Interview

“I’ve tried a bunch of fancy [diabetes] management apps in the past but I’d always … give up after a week”

Pain point

  1. Overly-complex apps that try to be a comprehensive management tool cause overwhelm and low retention