Redesigning UCLA's Student Health & Wellness App

Overview

From the get-go, my teammates and I gravitated towards finding solutions to help students at UCLA prioritize their physical and mental health. We related on how easy it was to forget to care for ourselves when there seemed to be so many more urgent things going on in college.

Through our interviews and observations, we found that many students had issues accessing health and wellness resources that they were already paying for through their health insurance, UCSHIP. Our solution was to redesign the existing UCLA Student Health app. Our version aimed to make booking appointments and finding benefits a much smoother and less frustrating experience, so that students can be empowered and encouraged to seek the help that they need.

We were given 8 weeks to complete this project for CS 188, Human-Computer Interaction. In our team of four, my role in this project was lead designer. My teammates contributed to gathering insights and discussions on the product and focused largely on implementation.
Role
Lead designer
Category
Mobile design
Time frame
Fall '18

Needfinding

Interviews & observations

We talked to four UCLA students to understand how they discovered what health and wellness resources are available to them, specifically through the UCLA student health website and UCLA’s Student Health app. Since none of them had used or even heard of the app before, we focused on their experience with the website.

We asked students about how they decided whether they wanted to get UCSHIP, the school’s insurance, or not. We then followed up by asking them about what benefits they knew about as a student with UCSHIP and any resources and benefits they wished were more accessible.

To test the usability of the current student health website, we gave participants four tasks:
  1. How would you find out what benefits you have as someone with/without UCSHIP?
  2. How would you book an appointment with a doctor if you were really sick and wanted to seek immediate medical attention?
  3. Can you find how much it costs to join UCSHIP?
  4. Can you find what dental benefits you have as a UCSHIP holder?

1.

How would you find out what benefits you have as someone with/without UCSHIP?

2.

How would you book an appointment with a doctor if you were really sick and wanted to seek immediate medical attention?

3.

Can you find how much it costs to join UCSHIP?

4.

Can you find what dental benefits you have as a UCSHIP holder?
As we observed our participants, we noted some moments that stood out to us:
Based off our interviews, we listed apparent user needs, as well as our own insights into students’ current patterns of behavior and attitude toward their health and the healthcare resources at UCLA.

The needs included:
From these needs, we interpreted our insights:

User persona

Based off these conversations, we created a user persona that best encompassed UCLA students struggling to find health and wellness resources at UCLA. This user persona helped serve as our point of reference for the rest of the design process.

Defining the problem

Point of view (POV)

Now that we had a better understanding of our target audience, we framed our challenge with a point of view (POV) statement:

User:

UCLA undergraduate students

Need:

accessible healthcare and wellness resources

Insight:

because the lack of clear information about options and benefits prevent them from getting the help they need
From this, we brainstormed ideas to solve our challenge by first coming up with actionable questions. Then my teammates and I chose our top 3 questions and together brainstormed solutions to solve each problem:
To further narrow our focus, we chose our top 3 solutions that we would focus on designing and implementing this quarter:

1.

Directing students to off-campus partners if there is low availability on campus

2.

Comprehensive notification system and calendar integration

3.

Highlighting commonly overlooked benefits/commonly used services

Prototyping

Lo-fi prototyping

We created low-fidelity paper prototypes and tested them with 3 users. For each trial, we gave users three tasks.
  1. You’ve been feeling sick this entire week and don’t seem to be getting much better. You tried to book an appointment at Ashe, but there is no availability for the next 3 weeks. Look for an appointment with an off-campus provider and get a referral from Ashe.
  2. Your glasses are 3 years old and you want some new frames. Find how much you can get new frames at U See LA for.
  3. You're trying to figure out your finances for next year and you want to find out if you want to purchase UCSHIP again. Find out how much going to the Ashe Center would cost per visit with the different types of plans.
This low-cost testing revealed several usability problems in our paper prototypes, such as:
Our participants’ feedback was extremely valuable, as we changed many of our UI components to make them more actionable and have better call-to-actions.

Midpoint check-in

As we met with our teacher’s assistant to discuss the status of our project, we realized that the scope of our project was too ambitious. With only four weeks left in the quarter, we not only had to flesh our high-fidelity designs, but we also had to implement our product. As a result, we decided to focus on our core feature -- connecting students to off-campus providers when there is limited availability at the campus clinic. We felt like this feature was the most critical and would be the most utilized. Furthermore, this feature would already be quite tricky to implement.

While my teammates and I were disappointed to have to further pare down our MVP, we learned that in the future we needed to include ample buffer time for each step of our design process and implementation.

High-fidelity designs

After reducing the scope of our MVP, our final product would support three main tasks:

1.

Helping users to choose what kind of assistance they need

2.

Helping users schedule appointments at Ashe Center

3.

Connecting users to off-campus healthcare providers if there is no availability at Ashe
By allowing students to easily find the options available to them and reducing information, our Student Health and Wellness Portal tackles the issue of inaccessibility surrounding UCLA health and wellness resources.

Below is the user flow for Task 3, connecting students to off-campus providers if there are none available on campus.

1.

This is the home screen for our app. We wanted to make booking appointments as accessible as possible, and to streamline the process to remove any repetitive steps. The banner at the top notifies the user about any upcoming appointments.

Through our research, we’ve found that all the services UCLA and UCSHIP benefits offer can be organized into 4 categories. When users tap on one of these categories, they can begin the appointment booking process.

2.

This screen would be the first step in booking specifically a medical appointment. We indicate how many steps are needed to complete this process at the top so users are reassured that their appointment can be booked promptly. When users choose an option, they will be prompted with the next question.

3.

We also found that students were unhappy with the inability to book urgent appointments in a reasonable time frame. Although our product cannot offer more availability, students can determine the range of dates for the appointment they would like to book. This now gives students control over how long they want to wait for availability before seeking alternative providers.

4.

If there are no available appointments at Ashe Center, students can find off-site providers. Their selections are already filled in depending on which of the four appointment types they chose in the very beginning. The student can then choose specialization and distance.

5.

The results page for off-campus providers displays the various offices around the location the user specified. If a user taps on a doctor, they can call and open up the location of the office.

6.

If there are available appointments at Ashe Center, the on campus hospital, they will be chunked by day. Users can tap on cards to expand and minimize them. Once an appointment is selected, users will be brought to the appointment confirmation page.
My teammates were in charge of implementing the designs and building a rudimentary database. The codebase for our project can be found here.

Reflection

In 8 weeks, my team and I created a product that we believed could benefit many UCLA students, although the product needs much more work before being demonstrated to the UCLA administration. I took away a lot from completing this project, especially the necessity of clearly defining the design problem which comes after thorough research and interviews.

Looking back, our team would have avoided having to re-scope our project if we had a better understanding of a product timeline. We did not factor in midterm weeks, during which it was difficult to talk to our target users and find time to work on our project. I would have also liked to conduct another round of user testing after implementing our high-fidelity prototype...but then finals week struck.

And last but not least, thank you to my teammates Arvind Kumar, Michael Lee, and Elizabeth Muenchlow!