The iHeart Internal Age, a fingertip device and mobile application developed by Vital Sines, determines user’s Internal Age in 30-seconds by measuring a scientifically proven heart health metric - Aortic Stiffness.
Aortic Stiffness has been proven to be a marker of heart health, cognitive decline and dementia and risk of death from all causes. Most existing products in the health and fitness monitoring space simply focus on heart rate and activity monitoring, iHeart measures Aortic Pulse Wave Velocity and algorithmically converts the real-time data to Internal Age.
In this project, my team and I redesigned the current iHeart Internal Age app to improve its usability and increase user retention.
World's first mobile application that calculates a user's Internal Age based on the iHeart device reading.
Currently, users purchase the iHeart device in order to monitor their health.
But they are not consistent with checking their internal age readings. Since they are not being regular, the results of their readings are varying greatly, therefore, seem to be inaccurate which contributes to a low retention rate.
One of the iHeart’s mission is to promote a healthy lifestyle through regular monitoring so user’s "stickiness" was our biggest concern and the problem we aim to solve.
To support Vital Sines mission to improve people's
health with a mobile application that provides
the user with an immediate bio-feedback based
on the Aortic Stiffness reading.
Below you can see the steps in the process I was directly working on.
You can click any of the steps and go directly to that part of the process or simply continue reading the whole story in full.
As I mentioned before, iHeart is a fingertip device that measures a person’s Internal Age, through measuring aortic pulse wave velocity and comparing it to an average for an age range.
The current app can record and save reports of Internal Age and is only offered in landscape mode.
It allows users to create multiple user profiles to track family members, friends, and others.
It also encourages the users to create two profiles for each person to measure
the “Baseline” reading — a reading done first thing in the morning, and serve as a benchmark
for user’s Internal Age while the “Experimental” reading — is meant to be taken after activities,
such as exercising, eating, smoking, etcetera to see how such activities affect the Internal Age.
The product currently targets 45–60-year-olds who have had a health scare or are concerned about their health.
As mentioned before one of the main goals was to improve the retention rates of the iHeart Internal Age users. To gather insights into the causes of the low retention we took the survey data of active users that the Vital Sines had deployed earlier and plotted it with an affinity diagram to see trends in what users of iHeart were saying about their experience.
What it boiled down was the users:
Are unsure of device connection and status.
Can’t find information about how Internal Age is calculated in the app.
Are unsure of why Internal Age readings vary so greatly.
And lastly confirming our findings from the competitive/ comparative analysis — landscape mode is difficult to use.
Below you can see the affinity diagram that helped us gather users' comments captured in survey.
google play store reviews
We also looked at the iHeart Internal Age app reviews to gauge how the app is perceived there, the findings from that research matched the survey conclusion.
After polling the reviews and survey data we decided we needed to dig at the unease that current users felt by testing the existing iHeart Internal Age app.
We have conducted 10 tests with users (some tests extended into a few days) and we found the exact pain points when using the app which were:
The overall difficulty of use (ie. input-fields covered by the keyboard, very small text,
Lack of clear instructions.
Trust issues (users were unsure why the App needs access to their Location, Bluetooth and Media)
Lack of knowledge and the next steps.
It’s become obvious that when tackling the obvious usability issues we also needed to make sure that the users get clear instructions and assurance in order for them to trust the app more as the knowledge gap left all of them doubtful (no matter whether the results were good or bad).
Each tester was subsequently interviewed to help us pinpoint when exactly users needed the most support.
Things we needed to implement with our design were:
Priming the user before the system prompts to build their trust.
Encouragement and the next steps after the reading.
Finally, clear instructions and more information throughout the process.
Some of the most insightful interviewees' quotes are shown below.
After discovering the above issues it was time to compare how the iHearth Internal Age app compares to similar products. The market is saturated with health and wellness apps so we had a lot to choose from when looking preparing out competitive/comparative analysis.
We chose to focus on a few that were the most popular. We compared wellness apps focusing on habit building (ie. Headspace, Fabulous, Clue, Gyroscope) as well as fitness apps (ie. Fitbit, Seven).
Looking into the specific features of these apps, we noticed immediately that
all of the apps we compared were built in a portrait mode - a feature that the current
iHeart Internal Age app didn't have.
When we looked deeper into the functionality we found that most of the apps provide progress tracking and dashboarding we also noticed that while most of the apps have some sort of onboarding majority lacked contextual hints.
Thanks to that useful research we found current trends, discovered what users are already familiar with and also found a niche that the iHeart app could potentially fit into.
user journey map
The extensive testing resulted in us mapping out how current users experience the iHeart app. By creating this journey map we could better empathize with how our users felt in each stage of their journey. We can target the bad feelings of those stages by noting friction points and matching those with a possible resolution to what the users are feeling.
In order to further our connection with our users and to make sure we make empathetic design decisions, we summarized all the research findings and created a user persona.
Bill is the always curious type, he’s always looking for information. Ever since his wife died, Bill’s been passionate about keeping healthy to see his grandchildren grow up.
"I like to know what I need to do next in anything"
"Why does everyone try to keep me in the dark?"
"Technology refuses to cooperate with me"
Prevent age-related health concerns
To help track of his diet and exercise patterns
To help keep track of his heart while he is playing with his grandchildren
“After my beloved wife passed I want to
take care of my health better for
my children and grandchildren."
So imagine that Bill has just bought the iHeart app after his grandson saw it on Dragon’s Den on TV. Excited, Bill has found what he needs to start staying healthy. Bill downloads and fires up the iHeart app…
Bill has a hard time signing up and making a profile, due to the landscape only display for the iHeart Internal Age app making it hard to type. After getting his first report done, Bill is confused by how his Internal Age is calculated and what he can do to lower it.
Frustrated that he can’t find any information in the app, Bill doesn’t use the iHeart device again and leaves it in his nightstand drawer.
Next, we created a chart of Bill’s goals, needs and pain points to make sure all of them will be met within our design:
prevent age-related health concerns
to help track of his diet and exercise patterns
to help keep track of his heart while he is playing with his grandchildren
to find an easy way to read and understand the technical results from the reports
to be able to easily find the information he needs
"I like to know what I need to do next in anything"
"Why does everyone try to keep me in the dark?"
"Technology refuses to cooperate with me"
It was now time to take all the research findings and everything we knew about Bill's needs and formulate a feature set. We first established features that will address Bill's concerns and reinforced them with a proposal that would tie in resolution to Bill's needs.
Bill wants to know what he needs to do next =
we provide onboarding to testing and reporting and what he can do with the iHeart app
Bill wonders why people keep him in the dark =
we make sure to give contextual hints and leave information available to him in the app
Bill thinks technology is out to get him =
we design error and empty states to inform Bill of what and why is happening
Streamline the first time use of iHeart by giving the user a guided experience.
Onboard users to using the iHeart device and how to interpret results.
Include a new method of visual reporting and tracking.
Add reminders to iHeart to improve retention and encourage frequent usage.
With the proposal in mind, we started out mapping how Bill might travel through the app.
The user flow is a diagram of how a specific user would navigate through the app, on our end, it helped us understand where and how we should inject the proposed improvements.
It also helped us understand better when and how to approach the device integration/connection issues.
Below you can see the full user flow of the heart app for both first time user and a returning user.
From the start, we can see the onboarding process, which will only take place the first time a user registers.
Contextual walkthrough helps with understanding the metrics, builds trust and improves retention by injecting information, assurance and helpful hints.
Keeping in mind that we were working with an external device we had to take into consideration how the app would "talk" to the device in the backend and how would that chatter be presented to the user.
When conducting usability testing we observed users who didn't understand when to put the device on, take it off, users didn't know what was happening at all times and encountered connection errors and reading errors. That's why it was crucial to list all the possibilities and put affordances in place to prevent errors and communicate with the user if they did happen. Below you can see the part of the pre-reading/reading part of the user flow in which we injected said communications.
design studio whiteboarding
Upon completion of the research and planning stages of the project, we began to sketch out the designs on paper.
We began by running a whiteboard design studio to understand the high-level volume of information we needed to include on specific pages.
After that brainstorming session, we were able to compile all of the pages needed and finally start designing on a physical plane.
This is a loose representation of our idea. It’s a quick way to get our ideas down to test and gather feedback to know what works and doesn’t work about the designs before we begin to digitizing them.
usability testing tasks
The tasks that we gave to the users when testing included:
Create an account
Take a successful first time reading
“Come back to the app” to check the progress after a period of time
usability testing changes
After testing we made the following changes to my wireframes:
Removed the “remember me” checkbox from the sign-up screen
Split the account creation pages into steps
Removed “add a photo” section from the sign-up process
Relocated Bluetooth and Location prompts
Removed the Baseline/Experimental toggle from the chart
Change the placement of elements on the Dashboard
The image below demonstrates how design transformed thanks to the feedback above.
Here you can see the Dashboard screen design.
In the paper prototype, the hint of the day is placed at the top of the screen the feedback we received helped us with the decision to move it below the chart as the chart was the thing our users wanted to see first.
In our paper prototype, we included a toggle to switch from one type of reading to the other that toggle proved to be an unnecessary feature so we removed it from the mid-fidelity prototypes.
mid-fidelity prototype & testing
Taking the findings from the paper prototype testing further, we created mid-fidelity wireframes. We chose to use colour and graphic elements in order to measure correctly how readable and clear the design is.
With a whole set of mid-fidelity, we were ready to test the full usability of the app and focus on elements that are difficult to demonstrate with simply pen an paper, like the data visualization elements.
As an example:
The average range bar , seen below, was first built with a gradient that proved confusing as users weren’t sure where a good range starts and ends.
We then decided to introduce color-blocking, when tested again the users were happy with that direction, but still were unsure where they stand as it required further reading.
The best solution was to combine both of them and design a block of colors with an indicator and simplified labeling.
retention through continuous support
Below you can see how the app guides and supports the user. The recommended rest period before the reading is filled with useful hints to make the waiting more interesting, it is also skippable in case the user has rested already. The instructions are clear and supported by visuals. The device-app internal processes are communicated to the user to sustain their feeling of control and trust.
retention through knowledge and trust
Knowledge is power and we want our users to feel empowered. Below you can see a snippet of the contextual onboarding that would educate users on how and when to make recordings, what they mean and what are the ways to lower the Internal Age. As many people tend to skip through the onboarding we had to make sure that the information would be available for the returning users as well.
Here you can see more examples of how we thought about increasing retention with encouraging messaging in blank states, guest recording to increase users' engagement and encourage interest in others and a reminder prompt in onboarding
messaging and language
After hearing the users' feedback from the mid-fidelity testing and taking into consideration previous research we decided to conduct a content audit and remove misleading information or information that required citation, in particular, statements that that could be interpreted as professional medical advice.
Due to time constrictions, we were not able to include all the features we wanted to. Our testing and research, however, suggests that the following should be implemented in the future.
Social media integration in the app — to allow users to share their progress
Categorized habits for experimental tracking — prebuilt categories for users to select from instead of writing full notes for themselves
Tracking of additional metrics (height, weight, etc) — We would need to research how useful these metrics are to track in relation to a user’s internal age