Case Study: Designing an App to Help Long-Term Patients in the Hospital

Ted Sneed
Ted Sneed
Published in
10 min readJan 10, 2018

Giving you the right resources to take control of your healthcare experience.

Project Overview

In this case study I explore the needs of guardians who have to rearrange their life when their loved one needs them most, and to help them find a solution to the countless hours spent in hospitals. Everyday thousands of people find their lives disrupted by the healthcare system. Parents and guardians of patients often have their needs overlooked in this situation. The outcome is Patient Gateway an app designed to simplify the healthcare system for guardians of repeat patients requiring extended care, both as in and out patients.

Background

The whole idea of creating an app for families with children in the hospital was brought up by the personal experiences of colleagues who had gone through similar experiences. The question that drove the design challenge was “how might we help families that have children in a pediatric hospital staying for extended periods of time?”

My Role

From October 2017 to November 2017 I worked as lead designer for a social design challenge called Patient Gateway. I was responsible for the research, information architecture, interaction design, prototyping, visual design, copywriting, and user testing. The team consisted of myself and Bryan Wells.

Design Process

For this challenge I used a five step process that allowed me to understand the user experience quickly and explore possible solutions that could later be fine tuned through testing.

Step 1: Empathize

  • Assumptions
  • Interview
  • Survey
  • Research

Step 2: Define

  • Analyze the Research Data
  • Create a Persona
  • Produce a Creative Brief

Step 3: Ideate

  • User Story Map, User Flow Diagram & Sitemap
  • 10x10 Sketching
  • Low-Fidelity Mockups and Wireframes

Step 4: Prototype

  • Build Low Fidelity Prototype

Step 5: Test

  • Conduct Usability Testing
  • Hi Fidelity Mockups
  • Ideate, Refine, Test Again

Conclusion

  • Project Impact and Outcomes
  • Design Toolkit

Step 1: Empathize

Assumptions

Assuming that some guardians end up finding a place to stay nearby while their loved one is being treated for serious illness I began researching blogs, hospital resources and hospital lodging deals. Search results did not turn up much in the way of lodging resources or the need for them from support group sites. Wanting to find out more about what kind I resources would be most useful I wrote up a list of questions that might help me better understand user needs.

Interview

To better understand the needs of guardians, I interviewed hospital patrons and staff members at Primary Children’s Hospital in Salt Lake City, UT. The interviews probed at the issues parents and guardians face during prolonged healthcare. I asked parents about how long their child had been in the hospital, if they ever stayed overnight and what they wish the hospital would do differently. When it came to the staff I focused on what kind of resources are available to parents and what kind of changes could have the biggest impact.

Survey

I formulated an online survey based on interview results and assumptions. The survey was distributed via web links and targeted anyone that had been in the role of guardian during a hospital experience.

Research

With a strong base knowledge and direction, I turned to outside studies to expand on the survey data and focused interviews. One of the most helpful studies was “Flip The Clinic”, which gathered a variety of pain points from patients, doctors, nurses and hospital staff using hashtags on twitter. The Twitter based study expanded my data and solutions to incorporate a larger target audiences that dealt with similar issues. The broadened group included spouses and adult children caring for family members in prolonged care. Flip the clinic focuses on qualitative data so I used their research in much the same way I would interview results.

Step 2: Define

Analyze the Research Data

The results showed that most parents and guardians found it difficult to manage outside life during prolonged care. The issue of being able to stay at the hospital overnight was not as far reaching as initially presumed. The data rather pointed out that hospitals were already providing overnight accommodations, but lacked digital resources (see results below). One of the most common pain points the surveys revealed was that parents spent a large percent of their time managing doctors appointments and sitting in waiting rooms. By analyzing survey responses and exploring the resources available to patrons at all the surrounding hospitals, I realized that many resources remained unexplored by patrons.

Create a Persona

To keep me reminded of who I was designing for, I built a persona that embodied my research and original design goals. The need for a persona developed while exploring all the various possible ways to improve the health care experience when reviewing wants and wishes for change. While simple, the persona gave me a realistic and focused path to follow. I wanted to focus on the goals of parents who just want the best for their children. I imagined a mother who has a busy life full of PTA meetings, soccer practices and a child that now needs her to more than ever.

Produce a Creative Brief

I wrote a creative brief to relay key information to stakeholders and set the course of the project in a clear direction. The meat of the brief covered the target audience, key message and primary objectives. Click here to read the creative brief.

Step 3: Ideate

User Story Mapping, User Flows and Sitemap

During brainstorming I started sorting ideas into categories (patient info, scheduling, resources, etc) to get an idea of the project scope. Many of the possible solutions survey data and outside research revealed a rabbit hole of possibilities. Using the the primary person I further sorted the solutions to fit the project goals and developed a Minimal Viable Product (MVP).

A couple of the solutions that were hard to filter out were live updates regarding patient records, a vetted hospital library and a hospital forum. With only 4 weeks to build an initial product and possible complications with HIPPA laws, I chose to revisit the more complex solutions during a later release.

With a MVP in place, I created a sitemap to clarify design and build a road map to each feature of the app.

Sketching

That moment when all those imaginative ideas start to take on a physical form is really exciting. I opted for 10X10 sketching in the initial stages of the project to try and get out as many ideas as possible, as quickly as possible.

Low Fidelity Mockups and Wireframes

To keep the design process simple and allow for future developments I recreated the best design solutions in SketchApp using low fidelity mockups. This process was both time consuming and rewarding. I realized while creating the planned screens for prototyping, that many of transition screens required, like form fields and notification screen were missing. Not wanting to miss any steps I worked all the new screens into the process, essentially doubling my projected workload. The reward here was that I learned a valuable lesson in projected user flows and got a lot of practice in Sketch.

Step 4: Prototype

Prototype

Once I had all the necessary screens to accomplish the main goals of the app I built a prototype in InVision. I found that InVision is a the fasted way to build a basic prototype and can be changed for rapid testing.

Step 5: Test

Conduct Usability Testing

I created two blind user scripts to test the user flow of the prototype with Usertesting.com. The first kept the Usertesting.com script with only minor changes to represent the product name. The script essentially asked testers to click around and explore what was on the screen. The assumption was that a common script used on Usertesting.com would be familiar enough to testers to get the ball rolling and get some quick feedback. The results of the first script were disastrously hilarious and were changed immediately. The first user surprised us by failing to understand she could click out of the first screen. It was the most painful five minutes of user testing I’ve ever studied.

The second script was completely rewritten and yielded more successful results. After analyzing user behavior and comments, I re-worded several features to clarify purpose and moved some features in the site mapping to reflect user assumptions. Most of the rewording revolved around the landing page with four main feature buttons.

Here’s a breakdown of those assumptions from the users:

My Doctor:

  • Well what if I have more than one doctor, does this mean the app can only handle one doctor per user?
  • Why am I seeing a button that only doctors can use?
  • Is that where I search for a new doctor?

Appointments:

  • Why is there an “Appointment” button, did I make an appointment?
  • If I click here does that mean it will schedule an appoint for me, with just one click?

Waiting Room:

  • No idea what could mean.
  • Maybe that’s where I can find articles and activities for kids?
  • Why am I seeing the waiting room? I haven’t checked in or done anything yet.

Resources

  • Is that where I find my personal information?
  • Not sure what this is, but I feel safe to click it.

The changes made were simple but effective.

  • “My Doctor” to “My Doctor(s)”
  • “Appointments” to “Schedule Appointments”
  • “Waiting Room” to “Estimated Wait Times”
  • “Resources” to Hospital Resources”

Follow up user testing, showed a success rate was 4 out of 5 users making the right assumptions of what each button lead them to and what to expect next. With the app not being fully functional some confusion still came up, but was mostly related to the limited functionality of form fields that could not actually be typed in.

High Fidelity Mockups

After determining the blind spots of the project designs, I began designing high fidelity mockups with clearly defined artifacts, color pallets, style guides, symbols, and pictures. Initial designs were later iterated and refined into to a high fidelity prototype.

Ideate, Refine, Test Again

Satisfied with the MVP, I created a high fidelity prototype to test the product again. In this iteration I choose to use an informal focus group methodology. Hoping to gather qualitative data after presenting the app to stakeholders and observers we opened the floor for feedback. The feedback we received was mostly positive in relation to the information architecture of the app with minimal confusion. The top critiques voiced were minor design elements that were not shared by large groups and appeared to be based on personal preference. All concerns were examined and addressed after the presentation.

Try it out for yourself, the link will take you to the InVision.com

Conclusion

Lessons Learned

Think it through: By not planning out all the notification and form field states during the user story mapping I didn’t have sketches of them ready to build in sketch. The work was not hard, but it was time consuming and required me to ideate with sketch prior to moving on to the next step in the process. If I had thoroughly planned out every step it might have saved me some time or at least made for a more fluid workflow.

Don’t assume users know what you mean: Using concise wording is what ultimately lead to a better user experience from the landing page. Seeing the various interpretations was a real eye opener to designing for other. In this case I think Antoine de Saint-Exupéry said it best, “Perfection is achieved when there is nothing left to take away”.

Nothing worth doing is easy: The project got off to a great start, but some idea are harder to create without a lawyer present. Some of the feature ideas that might have large impacts like seeing patient records, got convoluted by HIPPA laws and were set aside due to the amount of research time being devoted to understanding limitations. Other ideas required integration with hospital systems and staff training. Ultimately the app is a gateway to big changes that would require ongoing integrations for the most impact.

The final result of Patient Gateway is this case study and the associated prototype with the proposed deliverables.

Deliverables

  1. Research data
  2. Personas
  3. Site map
  4. Wireframes
  5. High Fidelity Mockups
  6. Prototype

Design Toolkit

Trello, Sketch, Invision, Real Time Board, Google Forms, DropBox, Lucid Charts, Slack, Pen and Paper, and Material Design.

Contact Info

For further interest in Patient Gateway or if you need a new UX Designer, feel free to contact me here.

--

--