SPREADING INFORMATION,
NOT DISEASE

We designed an app to help the Centers for Disease Control and Prevention inform people how to stay healthy as they travel around the world.

 

Project Type: 4-person student project

Duration: 2 weeks (group), 1 day (solo, visual design)

Skills: user research, competitive analysis, interaction design, interface design, prototyping, wireframing, usability testing, visual design

Tools: Sketch3, InVision, paper, pen, permanent marker

 

 

My Role

We worked as a team for every step of the project. I took a leadership role in three areas:

Team dynamics

I believe in building teams that support all voices, so I often facilitated group debates by translating, summarizing, and playing advocate and devil's advocate.

User and market research

Because of my background in journalism, I conducted 8 of 17 user interviews, coached team members through interviews, and led our competitive analysis.

Visual design

After the group project was over, I added a level of visual design using the CDC's typography and colors.

 

 

The Problem

The CDC wants a way to educate people about how to stay healthy while traveling in order to prevent the spread of disease.

Our team was tasked with combining two of the CDC's existing mobile apps.

We found that travelers don't mind researching many (sometimes unreliable) sources when they're looking for things to see, do, or eat. 

But when it came to health, virtually nobody spent time researching because they didn't know where to go or who they could trust.

TravWell provides information on vaccinations required for a given country.

Can I Eat This? warns what foods and drinks to avoid while abroad.

 

 

The Solution

Eliminate unnecessary choices.

We envisioned a solution that would cut through the noise by providing reliable health information in the most direct way possible, so that travelers could get vaccinated and stay healthy without having to think about it.

We designed a mobile app that:

  1. Offers information about vaccinations, food safety, and travel advisories.
  2. Can be used offline since many travelers don't purchase data plans abroad, and internet connection can be unreliable in developing countries.
  3. Gives infrequent users what they need to know, and heavy users what they want to know.
 

 

The Journey

 

What's wrong with them now?

We researched the CDC's mission and major activities, read user reviews of the two apps, and identified their major pain points.

TravWell’s wayfinding is confusing. 

The visual hierarchy is unclear, the global navigation changes, and most of the information is on the website, not in the app.

Can I Eat This? offers low payoff.

It takes many taps to drill down to the information, which is not very specific.

 

TravWell

Can I Eat This?

 

What's working elsewhere?

From there, we ran a competitive analysis on websites and apps that addressed the CDC’s pain points: content strategy and calls to action.

Medical sites such as WebMD and MayoClinic don't prioritize prevention, unlike the CDC. 

Text-heavy layouts suggest that their users are more motivated to read a lot because they may already be experiencing symptoms.

Travel sites such as Virgin America and Airbnb tend to offer only one task per screen.

This reduces cognitive overload and funnels users into a happy flow. 

MayoClinic

Virgin America

 

Who are we designing for?

Although we've all traveled, we didn't want to bring any personal assumptions to the table.

So, we published an online screener to gather interview participants who had traveled outside of the United States within the last five years or were planning to in the next year. We received more than 100 responses.

From that pool, we interviewed 17 people ages 24 to 70 to understand how they prepare for trips, how they get information about travel health, and what their travel habits are.

I studied abroad in Mexico in college and came back with Hepatitis. I was in bed for three months and lost 33 pounds.
— Paul, 67, Mission Viejo
I take everything with a grain of salt. I find a lot of information on the internet is fluff and isn’t matching.
— Sheena, 26, Los Angeles

Affinity map of our interview responses

 

Who do we focus on first?

We developed two personas from our user research: Andy, who plans ahead, and Charlie, who doesn't. 

We chose Charlie as our primary persona because she is the most at-risk of contracting a disease since she is the least likely to plan ahead. Her lack of motivation also presented the tougher design challenge.

Plus, by designing for Charlie, we would capture some of Andy's needs, too.

Charlie needs a non-stressful way to avoid getting sick in order to travel without interruptions.

user-2 small.png

Behaviors

Charlie travels spontaneously and mostly for pleasure. She'll eat anything you recommend, even though she's had food poisoning before.

 

broken-heart small.png

Pain Points

Planning is really stressful to Charlie and feels like a burden. But she won't come to you for help until she needs you.

light-bulb-1 small.png

Goals

Charlie doesn't want to worry about health or danger. She just wants to have fun, try new things, and escape.

Next, we drew storyboards, journey maps, and user flows to empathize with Charlie.

Charlie decides to visit Liberia. She knows she could easily get really sick there, but she hates planning ahead. She feels the most comfortable and in control when she's making it up on the fly. In a few quick taps, the CDC's new app tells her what vaccinations she needs and what foods and drinks to avoid, and Charlie gets back to dreaming about her next adventure.

 

What do we include?

We conducted a design studio to generate ideas and focused our main flow into a few key screens. In hindsight, however, we narrowed down too quickly. After that, we had trouble pushing ourselves to be more creative.

Our interviews had produced a long wish list of features, and we got really hung up on trying to include as many as possible. So, we used the MOSCOW Method to prioritize for this sprint:

  • Charlie must get vaccinated.
  • Charlie should learn about what foods and drinks to avoid in Liberia.
  • Charlie could read local travel advisories for Liberia.
  • Charlie won't get recommendations from the CDC about what to see and do.
 

How do we motivate Charlie?

The debate about which features to include was just a symptom of a deeper disagreement about what would keep Charlie invested in the app.

One side of our team (myself included) thought that Charlie would quit at the first sign of friction. The other side had more faith in her. Our designs reflected this disagreement: Camp 1 drew large boxes and not much text. Camp 2 drew text-focused layouts with lots of lists.

As it turned out later in user testing, both approaches were too extreme.

What we were missing was a key component of our storyboard. What motivated Charlie to download our app in the first place? And was that motivation strong enough to propel her through the app?

Because Charlie often relies on recommendations from other people, we reasoned that somebody – a friend, her mom, her doctor – probably convinced her that her health and time were worth it to use this app. That meant we had to determine who Charlie would listen to.

Camp 1

Camp 2

To explore different interpretations, we developed four paper prototypes. Our versions still reflected our earlier disagreements, but at least certain screens overlapped. Using elements from each prototype, we compiled one paper prototype and kept variations in three screens: calendar, country profile, and vaccinations.

Variations of the vaccinations page

 

How do we know what works?

We split up into pairs and conducted usability tests with 12 people. I conducted 8 more tests via email and texting. Testing allowed us to detach from our designs, stop arguing, and make decisions based on research, not opinion.

The payoff was in the quality of the information, not the interactions.

Users were drawn to the designs with big boxes and photos from Camp 1, but preferred the more specific language of Camp 2 because they understood where each button would lead.

But without the actual health information, our testers couldn’t tell us how effective our solution was.

 

How did we iterate?

We split up the wireframing and added a higher level of content fidelity by including real health and food information for Liberia. Three key goals guided our content strategy:

Prompts at the top of each screen

to instruct Charlie what actions were available, and why they were valuable.

Information hierarchy to make the copy more easily scannable.

We repeated the hierarchy of mandatory, recommended, encouraged to help Charlie focus on the minimum tasks, while giving enough context for Andy to keep track of everything.

Removing buttons, features, and content that caused confusion.

We cut everything we could from the interface without sacrificing clarity.

 

The Next Steps

How would we measure success?

We would conduct qualitative research to identify pain points by interviewing users as they plan trips using this app. We would also measure analytics at three key points:

download.png

# of app downloads

This tells us if the app is gaining popularity.

# of times users email the vaccination list

This tells us if that call to action is appropriate, and if the information is useful.

user-1.png

# of users who fill out their profile

This tells us whether users find the app valuable and trustworthy enough to use again.

 

What would we work on next?

Our next sprints would focus on four main areas:

speech-bubble-1 small.png
document-3 small.png

Interviews with health care providers

We might be able to address the most frequently asked health questions from travelers.

Features that provide basic information

Travel advisories and emergency contact information are already available to add in.

phone-book small.png

More calls to action

We could go one step further to connect users with their doctor or a local clinic.

notification small.png

Different ways to motivate users

Fear or gamification could be more effective than an overprotective mother.

 

What did we learn?

Our solution ended up so much simpler than we initially had imagined that we didn’t think we had done enough for Charlie. Some of that came from a lack of confidence, and a bit of ego. We saw our classmates design a variety of innovative features in their projects, and we were a bit disappointed at how straightforward our solution was. 

But that ego was what held us back in the first place when we were debating among ourselves. User testing had validated our ideas, helped us refine them, and taught us one of our most important lessons:

Not every solution needs to be disruptive.
It just needs to solve the problem.