BreatheEasy: From an idea to an app

Building out a digital platform for sharing asthma care information between a child’s primary and secondary caregivers

Childhood asthma in Chicago

As part of an interaction design course at IIT Institute of Design, I worked with classmates Ying-Tong Cai, Hank Garrett, and Yakun Zhou to understand how a technology-based intervention might improve asthma care for young children in Chicago.
A PDF of my full report is available here.

Our process and concept

We started by reviewing the results of classmates' NIH-funded research on childhood asthma conditions in low-income families in Chicago. To this, we added our own secondary research.

Based on this review, we chose to focus on how to improve the sharing of critical asthma care information between a child’s multiple caregivers.

Our concept, BreatheEasy, is a coordinated caregiver platform that uses smartphone and text message interfaces to simplify and support the care handoff experience.

I resumed the project on my own to explore high-fidelity designs

When creating BreatheEasy, we spent most of our time on the early stages of the design process:
  • understanding context via primary and secondary research
  • generating a persona and defining design principles
  • generating a design concept for our user
We only barely touched on bringing our concept into a higher level fidelity.

I decided to take this opportunity to bring BreatheEasy a few steps closer to being a "real" app, and I learned about Google's Material Design in the process.

Returning to our storyline

To redesign the app, I picked up with our existing storyline:

Our user, Sarah, is a single mother with a young child with chronic asthma.

Sarah needs to find someone to care for her daughter while she is at work.

She asks her brother Jim to watch her daughter, but is concerned that he will not know how to handle her daughter's asthma.

The BreatheEasy app makes it possible for Sarah to more seamlessly share asthma care information with Jim, giving her peace of mind during the work day knowing Jim has all her daughter's necessary care information available at his fingertips.
Once a care request is sent, the caregiver might respond to it in a number of ways, and the app would need to be able to support each outcome.

With this in mind, I sketched out flows for a variety of situations, including what would happen if Sarah changed the request after sending it to Jim.

Content structure

I determined that the "final" app would be divided into three main content areas:
  • My Requests – where the user could track and follow up on her care requests
  • Care Team – a detailed list of one's  caregivers, with the option of creating a new care request
  • Health Info – information on the asthmatic child's health, serving as a jumping-off point to share specific, relevant details with the caregiver

Wireframes

In the first row, we can see an early version of the flow to add a new caregiver to one’s care team.

The second row shows an early version of the flow to make a care request.

As the designs progressed, I kept going back and refining the screens and task flows to make sure they remained focused on providing the right content to the user at the right time.

High-fidelity designs

Once my low-fidelity designs were in place and make sense, I created high-fidelity mockups of the task flow for setting up a new care request.

This required a close review of Google's Material Design guidelines – I wanted to make this app look and feel as real as possible, and thus sought to ensure it adhered to existing standards and best practices set forth by Google. I also downloaded a number of apps to understand how existing products in the marketplace present content to users.

While there's no one "right" way to design an app, for a product focusing on a serious topic like healthcare, it's a good idea that it be based on established interaction patterns to help facilitate user adoption and retention.

My learnings

In undertaking this redesign exercise, I learned a few important lessons:
  • Having a device at hand is key to ensuring one's designs are in line with a platform's standards. Even though I had read through the Material Design guidelines online, it wasn't until I purchased an Android phone and played around with a plethora of apps that I really began to understand how content is presented and transitions are enabled in Android.
  • Knowing when to adopt an established UI pattern and when to diverge from it is more art than science – it depends on how familiar a user might be with an existing approach, and the costs/benefits of presenting information differently in one's app
  • Taking a concept from the early idea stage to something more "real" unearths a host of undiscovered nooks and crannies; these, in turn, must be addressed to ensure the concept will be able to handle the complexity of an actual use case
To read more about this redesign, you can find a PDF of my full report available here.