Indy Judd
Product Designer

Check-in

A web app for families with hospitalized children

Check-in

The Challenge

My team was tasked with finding a web-based solution to better accommodate families with children staying in extended pediatric hospital care.

All of us had personal experiences and connections to this situation which impressed the importance of designing something practical, usable, and simple. Perhaps even more than usual, this project called for an emphasis on well-rounded understanding and problem-solving more than artistry.

Discover

Our users are in a highly emotional scenario
Our users are in a highly emotional scenario

Foundational Research

Who is our user?

We began by exploring our assumptions about the experiences of families in this situation. 

Listing them instilled awareness of the ways we were biased, where we were correct, and more importantly, where we were wrong.

For example, our first reaction was to address sleeping arrangements. After speaking to our users we would end up finding a better approach.

With this improved awareness, we crafted an interview table. We wrote the questions to prompt the interviewees to tell their story in their words. The intention was to get these people to tell us what's important to them allowing us to probe from there.

This approach was especially important considering the extreme emotions the user experiences in their situation, particularly negative emotions. 

Listening to our interviewees recount such difficult experiences was an automatic boost to the empathy and compassion we had for our users. 

The first round of interviews quickly produced a number of distinct trends.

Key insights:

  • The stress means that getting food and sleep is difficult

  • Not being with other children & making sure they are taken care of is a major stressor

  • The financial burden of hospital bills/lost wages can weigh on you

  • Though rare, clear and frequent communication from hospital staff provided a sense of control and security

  • Lack of communication from the hospital staff was greatly frustrating

  • They mentioned that most of the info you need is online, but is difficult to find and comprehend


Refined Interviews

Where do our users need us to step in?

Armed with a list of primary pain points for our users, we conducted a few more interviews with an updated table of questions to gain context around said pain points.

 From there we took all of our findings and created a user journey map with emotional states and thoughts annotated. 

However, even with a more complete mental model of what our users were going through, we still weren’t able to determine the specific problem we should be solving for our users.

Check-in

Define

Analysis of the Problem

Solving which problem provides maximum value with minimum effort?

The design team couldn't agree on a direction, so we chose to send out a survey via social media to parents who have been in this situation. We included a section to rate each of the pain points we identified by importance on a scale of 1–10.

The way our users felt about communication with hospital staff was clearly the most distressing factor besides the state of their child. 

When parents have children in extended hospital stays the hospital staff often communicated conflicting, incorrect, or confusing information, and often did so in a way that was infrequent and lacking compassion.

Addressing this problem would also help alleviate some tertiary problems as well. Our users would repeatedly forgo access to basic amenities (food, shower, sleep, etc.) because they were afraid if they left they might miss an important update. 

With a mobile-friendly place to have access to the most up to date information, we would give a little more freedom to these families to take care of not just their child, but themselves as well.

“We had a couple of instances where we tried to enforce what the doctors recommended and the nurses seemed annoyed/didn’t want to comply with what we knew was best for him given his medical history.”

-Sarah

“We were always getting conflicting information from Drs and nurses, which was frustrating because we would have to ask the same questions 2–3 times.”

-Bobby

Check-in

Cultivating Empathy

Who are we designing for?

We wanted a simple, relatable way of relating to our users without having to be too abstract so I also created a persona.

Being able to recall the behaviors and motivations of our users in such a quick way proved useful when we would get stuck or if the team had a disagreement about a particular design decision.

We needed to keep the sensitivity we'd gained from the research so I put our insights into an empathy map. 

These artifacts provided us with a point of reference which we could return to anytime we needed to remind ourselves who we were designing for.

Check-in
Check-in

Defining the Product & IA

What exactly are we making to address the problem?

Now that we understood our users and narrowed down the specific problem we were going to solve for them we could decide how we would go about it. 

We used a user story map to determine an MVP, avoid scope creep, and ultimately shape the features that would provide the most value to our users.

Teasing out features, we determined the primary functions should be:

  • Feed of information about the status of the child

  • Central place to access important medical records

  • Ability to send questions to hospital staff

Having discerned our top priorities we were able to create a sitemap geared towards simplicity and the experience we wanted the users to have.

We made a point to keep in mind the possibilities of future releases to ensure scalability. We created early paper & pen wireframes in conjunction with the sitemap to answer questions about navigation and the relationships between pages.

Check-in

Design

Ideating Through Wireframing

What are the ways we could solve the problem?

After our Information Architecture was completed, the wireframing began in earnest. We used divergent thinking to find as many alternative setups as quickly as possible through sketching.

Heavy collaboration during this phase was the key to the variety and speed we enjoyed, and through this constant sharing of ideas, we identified the strongest ones. We put the strongest ideas into Balsamiq for testing.

Check-in
Check-in

Iterating to Hi-fi Mockups

How do we give our users a remarkable experience?

After the first round of usability testing, we were at a point where we could find out what this product looks like.

We created a style guide to establish consistency in our mockups from all team members. We focused on creating a soothing, reassuring aesthetic for our users. We hoped he colors, typeface, and simplicity would all reflect this.

The workload was made granular and the team agreed on how to divide it between us. We dove into Sketch and checked in consistently on each others’ work to make sure the visual language was uniform, provide and receive feedback, and supply each other with useful components.

Test

Lo-fi Usability Testing

Did we get it right? Is there a better way?

Conducting usability testing in tandem with our design process allowed us to make essential tweaks on the fly, instead of having to endure the tedious process of a large change at the last minute too often. Once we reached a saturated enough point in our wireframing we created a basic prototype in Marvel.

The testing revealed problems in the microcopy, the nav style, and part of the site structure. We did a card sort to pick new labels and conducted a few quick tests that validated the new labeling and nav systems.

Interaction Design & Validating Changes

Is it ready?

Eventually, we came to a point at which the screens we created were polished enough to shift focus to IxD and hyper-specific usability questions.

I moved into Principle and visualized the most important microinteractions. These experiments combined with another round of usability testing validated our direction, and after some minor tweaks, we were ready for whatever comes next.

Check-in

Reflection

What can I learn?

Coordinating interviews, digging up insights, turning those insights into action, and then making sure we made the right choices. My skill grew significantly from this. Though, if I did it again I may do a few things differently.

We could have saved a lot of time by leveraging our tools more efficiently, I would have liked to interview and perform contextual inquiry with hospital staff, and if we tested even earlier than we did we could have avoided some pain in the redesigns.

But even though these mistakes were sometimes unpleasant to recognize, I’m glad we made them because we don't have to anymore.