01
Understand
Hypothesis
Within their busy school schedules, college students are not prioritizing their health as much as they should.

This hypothesis is rooted from my personal experiences of sacrificing my health when I have too much on my plate. To identify if this was a real issue, I conducted interviews with college students to understand their health-related concerns.
One-on-one interviews with college students provided insight into their habits and pain points surrounding taking care of their health. These findings solidified the problem that this project was going to solve and the target audience for which the solution was going to be designed.
02
Define
Target Users
I took note of common pain points that the interviewees shared and was able to categorize them into two distinct groups. The first user type is students who are too busy to seek medical support and maintain healthy habits. The second type is students who are unfamiliar with on-campus resources or are hesitant to find help. I created a persona for each user type, naming them "The Busy Scholar" and "The Lost Seeker," and imagined how they would use the product through journey maps.
03
Ideate

Use case diagram

Proposal
Go Health is a mobile application that offers college students easy access to resources for non-urgent medical needs. Users will be able to choose an option from several methods of receiving medical assistance that best fulfills their needs.
User Flow
To determine the best user flow, I conducted A/B testing between two different navigation systems.
Type A lists the possible options upfront on the home screen, allowing the user to choose which option they want to proceed with. The different options are divided clearly, with a navigation menu at the bottom that allows the user to navigate between features freely.
Type B requires the user to submit their conditions, then offers them options after. This interface has a more guided navigation, where the app suggests possible remedies before offering options of getting additional assistance.

I created physical prototypes for each flow and prompted participants to achieve certain tasks to the best of their abilities, and asked which version they preferred.
Users who preferred Type A liked the bottom navigation menu, as it allowed them to go to any feature from any screen. Type B, in comparison, required the user to keep pressing the back button until they reached the selection screen. However, some users didn’t use the navigation bar at all and instead tapped on the home icon to return to the home screen, suggesting the iconography was hard to understand.
Users who preferred Type B liked how the app asked them their conditions first, then gave them options based on the given symptoms. It can automatically send information to medical professionals about what the user needs and provides the sense that the user is getting taken care of. Type A gives the user a lot of freedom in terms of navigation, but if the user doesn’t know what exactly they need, Type B could be beneficial in guiding the user toward their needed treatment.

Based on the results of the test, I concluded that the final user flow should have smooth navigation like the one in Type A but still give the sense that the user is getting guided and treated like Type B. 
04
Prototype
↑Back to Top