Heart Rate Data Design

Timeline: One week

In January 2015, Fitbit began taking orders for new devices that track the user's heart rate. Previously, Fitbit's products did not measure heart rate. Many of Fitbit's existing customer base and target customers are not familiar with how daily and long-term measures of heart rate reflect health.

The task: Make heart rate screens more interesting and understandable to new users

My first task at my internship was to create some wireframes for the mobile app focusing specifically on making the heart rate visualizations interesting AND informative for new users. (For a user who only put the Fitbit on five minutes ago, there isn't enough data to make the default graphs interesting.) I was also instructed to incorporate goal-setting into my wireframes.

The default screens:

The default day-long view, displaying only five minutes instead of the usual 24-hour timeline along the x-axis. There's not much data to look at, nor is there any education about heart rate zones or the meaning of "resting heart rate." — The default day-long view, displaying only five minutes instead of the usual 24-hour timeline along the x-axis. There's not much data to look at, nor is there any education about heart rate zones or the meaning of "resting heart rate."

The default 30-day Time in Zones graph. For a user who has only worn the Fitbit for five minutes, the chart doesn't have much to show. It also doesn't do much toward our design mandate of motivating users to accomplish cardio workout goals.

I tried different ideas for making the "Today" view as well as the 30-day retrospective views interesting to new users. There are a lot of limits on what claims the app is legally allowed to make when it comes to health recommendations.

The "Today" View - Current Heart Rate

Above, I kept the X-axis at 24 hours, and overlaid sleep on the graph to help the user make sense of the data. (Fitbit devices can track sleep; for a day-one user, sleep could be estimated as midnight to 8 a.m.) To fill out the graph, I considered adding dashed lines for missing data, both from earlier in the day as well as future data.

The 30-day Retrospective View - Time in Heart Rate Zones

When it comes to the 30-day retrospective views, two types of graph are emphasized. One is a recap of the user's total time in heart rate zones, and the other is a line graph of the user's average daily resting heart rate over the past thirty days. (Heart rate zones are segments on the continuum from resting heart rate to a user's maximum heart rate, numbers that are different for users based on age, sex, and other factors).

I plotted a default daily goal on the graph which could be edited or dynamically adjusted for the user's height, age, weight, or other demographic factor. I also considered entering "fake" data with a disclaimer, to explain how the graph may look in the future:

At right: A quick animated wireframe I mocked up using HTML and CSS to show how dummy data could be used with a "mirage"-like animation to educate the user.

The 30-day Retrospective View - Resting Heart Rate

The resting heart rate metric won't change much over time, so it makes sense that it's displayed as a 30-day retrospective view. I tried a couple of tactics for using the graph to explain how the metric works. First, I tried a dashed line, indicating future decreases, with an information box below explaining the concept. I also tried a straight line, indicating past data (which of course is not available on a user's first day) with a box asking, "how can I improve this metric?" in an attempt to interest the user in this metric.

The testing phase

Since the heart rate feature was completely new for Fitbit, we were unable to test the heart rate graphs on anyone outside the office. Since the target user for this project was people who don't understand the heart rate metric, that made these explorations impossible to test, unfortunately.

After my explorations, the project moved into the visual design phase, which continued after my internship ended.