As an R&D intern at Digital Infuzion in 2016, I was part of a team developing a smartwatch application which monitors the health of mobility-impaired patients. The product models Fitbit, but for people with irregular walking patterns. The drive behind this is to allow them to take ownership of their own health without frequent doctor visits. The majority of development was done in Android Studio, using agile methodology within the team.
My main task for this project was to design and implement the user interface and data visualizations on the mobile-facing end of this app. I made UX sketches of all pages and the flow between them. Here, we have the home screen, which summarizes four components of a user's health, as well as prompts them to explore further.
Further exploring the first option, we have the 'Walk Test,' which is a period of 60 seconds in which the watch + app will track the user's motion to come up with displayable metrics. This data and the user's history is stored and retrieved from a SQLite database.
To get a more comprehensive breakdown of individual walk tests, we decided to display with a line graph how fast the users' steps were as they progressed through the test. All the tests from a given time period can be accessed chronologically by clicking on an individual day, week, or month from the last screen.
Quantitative comparison is sometimes easier for a user than qualitative - so with that idea, we made mobility and fluidity 'scores' that can be used to compare performance to a personal baseline. These scores were determined through an algorithm which looks at accelerometer and gyroscope data such as translation in the x, y, and z axes.
It also uses machine learning to continually better understand the user's personal baseline and create alerts for unusual health metrics.
At the heart of this user experience design was understanding the people and the diseases we’re making the product for. How is the user's mobility limited? Since most patients exhibited shakiness, we made sure not to make buttons too small and provide easy ways to take back input.
Additionally, a lot of our data consists of change-over-time graphs and scores, so I had to figure out how to represent this accurately without making the users feel upset about their condition if it’s worsening. There was a lot of effort put into picking which kinds of graphs would be most effective for certain metrics.
At the end of my internship, we had a successful first version of the app. On the side, I had also been working on a quicker and more intuitive way for users to record flare ups of pain. This workflow lets you double tap to zoom into any area of the body, press and hold to signify the intensity of pain, tap outside the body to start over, and record when finished. After I made demos for this feature, we decided it was going to be a goal of the beta prototype. Here, I learned about priorities because even though we agreed it was a useful feature, I understood that in terms of development and relative importance, it made sense to wait and implement this on the next version of the app.