Gained in Translation

Ours is not the only startup that begins with a “walked into a bar” anecdote. A software engineer was riding the White Rim Trail in Utah and got dehydrated from heat exhaustion. His friend, an emergency physician, rehydrated her cycling companion using a technique called oral rehydration therapy. Once rehydrated, the engineer realized that oral rehydration therapy--with a branching algorithm and timed actions--would make a great self-care mHealth app for a common, acute condition, and could potentially avoid many emergency department visits, as well as a few back-country medical rescues. But translating a medical technique like oral rehydration therapy from medicalese to UI/UX...well, there’s no app for that!

Here are some of the challenges we faced and the lessons we learned.

Translating bedside reassurance into remote “trust”

Medical guidance is not just about knowledge transfer. In person, information communication needs to be reassuring and easy to understand--but in app format, this translates into concepts not considered routinely in healthcare, like button placement, colors, and flow. Having patients talk us through their emotional experience as they used the app was as important as watching them navigate. Improving both the form and function of UI/UX features built patient trust in the medical reliability of the app.

A sharp UX makes oral rehydration seem more like a real medical treatment. In using early prototypes, the user sometimes would feel uneasy about the face validity of the recommended treatment--they would say things like “I downloaded this app and it just reminds me to give small sips of fluid? Couldn’t I have done that without an app?” After our biggest design overhaul, we started hearing more responses like “I feel like it’s a real medical thing!” Switching to a more appealing design--without content change--made parents suddenly feel like they’ve done something real. We had narrowed the trust gap by switching from the primary colors leftover from our wireframes to our UI/UX expert’s palette of teal and navy. As an aside, the fact that our color makeover engendered greater patient trust was rather unnerving as a physician and explains why some non-scientific practices like avoiding vaccinations and charcoal cleanses seem legitimate when presented in professional-appearing web-design templates.

Users are nervous about privacy and security--and so are regulatory agencies

With the consolidation of physicians into every-larger healthcare systems and the ubiquity of electronic health records, patients are more accustomed to the idea that their most personal health secrets are stored online--and are also more wary of the risks of a data breach. Hearing these concerns, we considered the business case for collecting user identifiers against users’ fears about cybersecurity. We elected to collect no patient identifiers--but that was only half the battle. The other half involved communicating effectively with users that we were not collecting their personal data.

Laws also protect patients’ personal health information. As a mHealth app geared towards a US market, our app’s data collection, storage and sharing functionalities needed to comply with the Health Insurance Portability and Accountability Act (HIPAA). Although we collected no personal identifiers, we still needed to consult with an attorney to ensure that we had developed the app in compliance with HIPAA rules.

For a mHealth app about home care, users want it to be truly do-it-yourself-at-home

An app designed to support self-care for an acute condition cannot require trips to two different stores. Traditionally, oral rehydration therapy involves metric measurements (milliliters) of an approved oral rehydration solution--available either as a liquid or a powder. App users--who are mostly parents of children with dehydration from vomiting and diarrhea--did not want to leave the home to buy without a metric volume measurement device and oral rehydration solution. So we had to figure out how to translate oral rehydration therapy instructions into non-metric measuring devices (teaspoons) and provided a recipe for home-made oral rehydration solution.

Sometimes users want a high-five

Sometimes trouble-shooting is not all that users want to report. We had a “my child vomited” emoji button. We had a “my child yucked at the Pedialyte” emoji button. But we did not anticipate needing a “my child is now better enough to do flips on the bed--do I keep rehydrating?” button. Remember to include an “it worked!” button to avoid unnecessary symptom relief measures.

Adjusting expectations for key performance indicators

If 70% of emergency department patients vanished after the first few lines of conversation with the physician, we would have a big problem. Initially, this is how many users stopped before their second dose of oral rehydration fluid--in an app that coaches users through 5-10 doses. We had to learn to adjust for ghosting in our performance indicators. In a mobile health app--a free one, especially--lots look at the first few screens and leave without trying a single fluid dose. We had to readjust our expectations...and our denominator.

The most valuable teachers are still the patients

The most powerful experience in app development required no translation. As mHealth app developers, our best teachers, by far, are our app-users, our patients. This is true for in-person healthcare delivery, too. If you listen actively to the words and the accompanying music and have a growth mindset, your patients will teach you more than any mHealth app development manual or any medical text. This is the sacred part of medicine: patients entrusting physicians with their stories and with what matters most to them. We were humbled by the generous spirit with which so many of the app users approached sharing their experience with us to help make the app better for the next user.