SFGH Project Overview
My Role: research, design, and test a solution for a single user’s problem.
Duration: 3 days.
Client: Chris Nunez
Tools: Sketch, Omnigraffle
Deliverables: user flow, storyboard, paper wireframe, and paper prototype.
The Project
This was a student project at General Assembly. In three days, I researched, sketched, and created a prototype to address a problem for a single user.
Meet Chris!
Chris is a rebel chef and LGBT activist turned UX designer. Chris was diagnosed with HIV three years ago, and has been a vocal advocate for reducing the stigma around HIV and AIDS. He has given me permission to discuss his health issues on this website.
As part of his personal regimen, Chris has to test multiple medications and update his doctor, social worker, and psychiatrist as to how they are working. Often, he has no reaction to his medication and simply has to reassure his healthcare providers that he is in tip top shape. Currently, however, a simple reassurance involves a lengthy appointment setting process and an in-person assessment every few months at San Francisco General Hospital.
The Problem
Chris wanted a way to communicate with his doctor that his medications are working just fine, without having to set up an in-person appointment. I needed to create a messaging system that was both easily accessible for Chris and was private since it included health information.
My Process
Interviewing Chris
When I first interviewed Chris about how I could help, he had just come from a fruitless doctor’s visit. The staff at the front desk of San Francisco General initially scheduled him with the wrong doctor. This meant, that when he showed up for his scheduled appointment, he couldn’t see any healthcare provider! This also meant that he had to make a new appointment and wait another three months.
Chris was infuriated with the internal communication of the hospital staff, the amount of time it takes to schedule an appointment, and his doctor’s tight schedule, just to name a few things. This frustration actually led me to about a few problem statements and attempts to create a solution for each:
How can the hospital communicate internally so that there are no more mixups?
How can Chris communicate with his healthcare providers quickly, instead of making in-person appointments?
How can Chris communicate any insurance changes?
How can Chris learn more about his own health?
Site mapping
I began a quick sitemap to determine how to address all the problems Chris was facing in his interaction with his hospital. However, because this was only a three day project, I had to focus on just one main flow for Chris.
At this point, I interviewed Chris again, targeting my questions to narrow a problem statement. Chris wanted a more efficient means of communicating with his healthcare providers regarding his reactions to medication.
User Flow
By narrowing down the problem statements to just one problem statement, I was able to create a user flow for just one of the many issues Chris was facing with his healthcare providers. I focused on a user flow that allowed Chris to communicate with his healthcare providers quickly, instead of setting up an in-person appointment.
Paper Prototypes
Based on the user flow above, I created an internal email system that would (1) allow Chris to message his multiple healthcare providers; and (2) alert Chris through his personal email to any new messages from his doctor.
Prototype Testing
Initially, I tested my paper prototypes with Chris and Chris only. Because we were in constant contact, we began to experience a bit of group think. For example – the first paper prototype allowed Chris to click on a name to message one of the doctors.
After testing with other users who did not have the same insight into my process, I realized that I didn’t need to re-invent the wheel – a simple email-like messaging system sufficed.
I also allowed the internal messaging system to send notifications through email. However, since medical communications are confidential, the user needed to go through the internal communication system to read the actual message
Reflections and Conclusion
Since this was a 3-day project, I was only able to create paper sketches. The first thing I would do to continue this project is increase the fidelity and test out an interactive prototype.
I need to test it out with other users, not just Chris, to prevent that group think we had originally.
I would love to explore how this messaging system would work in mobile - should I explore simply a website or invest in a native app? To test mobile design, I’d have to learn how users currently contact their healthcare providers.
Another topic I need to take on is the user flow on the healthcare practitioner’s side. My hypothesis is that this system will help free up appointment slots for doctors and other healthcare providers, and make things run more smoothly for the hospital. I would need to observe how a healthcare provider might use this product to create a viable MVP.