A project in my Entrepreneurship 390 class. I wanted to streamline the process of checking in to an appointment at a hospital.
Final Version
Problem Statement
Patients at a hospital want a platform to check in that gives them the information they need to navigate to the doctor's office so that they can streamline their hospital visit.
I started out with this problem statement, initially intending to provide an application that focuses on the patient, giving them the tools they need to find the offices for the appointment and check in to their appointment, but I quickly realized that this could be a tool to manage appointments as a whole, not just to streamline the time a patient spends in the hospital. With that information in mind, I developed personas that reflected users of the product.
Persona Example
Elena - 45 years old, F, Social Worker based out of Ann Arbor
Elena has lower back pain, and is visiting the hospital for the first time after avoiding it since she broke her arm back in middle school. She needs someone to walk her through the hospital visit since she doesn't know where to go, what she's being told during the appointment, or what she needs to do after the visit. The hospital she's visiting is huge, and she feels like a sheep being herded through. This app should make her feel more attended to, with personalized, step-by-step guides on how she should approach her visit. She has a smartphone, but doesn't use apps on it too much. She needs a step-by-step walkthrough that makes it easy for her to use the application, with big buttons and clear type.
Feature Exploration
Once I had my personas, I wanted to test my hypotheses. So I talked to family members, friends, and acquaintances who have been or are patients and medical professionals to get a better understanding of what the product features should be. By asking potential users of the product what it should look like, I got a better understanding of what information I was allowed to provide and what I was not. For example, I intended to provide an estimate of time, once a patient has checked in, that they would be seen by the doctor – but after talking to an orthopedic surgeon about his patient routine, it became clear that I wouldn't be able to provide an accurate estimate, so to avoid misrepresenting any information that would make a patient lose trust in the doctor or hospital, I cut that feature out. Balancing trust and avoiding any detrimental representation of the hospital itself became two priorities that I focused on throughout the process.
Wireframe
Now that I had a clear idea of what I wanted the product to function as, I developed a mock wireframe that focused on basic layout and function for the user. As the users of the product would range from millennials with intimate experience with a smartphone to seniors who don't usually use applications on phones, I needed to make a simple, robust experience that would be accessible by many types of people. I started with the name and date of birth – the basic information a hospital needs to find patient records. This leads to a menu that clearly lays out what the core features of the product are. I created a flowchart for how the product should function depending on the option a user chooses, taking them through each step of an appointment at the hospital.
Translation to Final
After completing my mockup, I sent it to the same people I had consulted with earlier about the features I should apply to the application, and after a few minor tweaks, I developed the final version. I decided with a more muted color scheme, with pleasant, pastel-like colors that would be pleasing to many people. I didn't want to go with the standard beige-tint that many hospitals choose to deck their walls with, so instead, I chose a soft teal-like color. The blues were inspired by my allegiance to my college, but worked well to contrast with the colors I chose for the background. I chose a simple, clean typeface in Monteserrat, which I set at 20 point in many areas, allowing for easy reading across many generations of eyes. Onboarding decisions were easy, as I used the information that a hospital uses to access patient records, and eliminating any extra explanation of the application, as it has a simple user flow. I designed as if a patient were to open the app as soon as they got to the hospital, leading them to the offices and providing a logical flow using buttons at the bottom of each page to guide them through the application, and in turn, their appointment.
Next Steps
The next logical step would be to flesh out how the application would look from the side of the hospital. From a back-end perspective, I could set up a queuing system that would automatically organize patients as they come in, a feature which could be extended out to other areas of a hospital, such as an ER triage system. The hospital portal would have to be a computer application, as it would be ridiculous to expect secretaries at Hospitals to check in hundreds of patients a day on their phones.
The feedback I got about the patient portal was good, as people said it was easy to understand and walked them through a standard hospital visit. The main concern was that it did not do enough for after a patient has left the hospital, as the application could provide, for example, medication reminders – giving users a reason to use the application when they are not simply going to an appointment. In all, however, I believe the application solves the initial problem statement, walking a patient through an appointment from the moment they step into the hospital to the moment they leave.