App and device developers are racing to create tools to passively and continually monitor our bodies. Basis, Fitbit, or Fitband are already too common to draw notice. However, as these products become more sophisticated and collect more body metrics with increasing accuracy, they are blurring the lines between medical and wellness devices. Alivecor, for example, is now shipping home-use ECG machines that display readings on your cell phone “comparable to readings from Lead 1 of gold-standard ECG machines, but at a fraction of the cost.” Scanadu’s Scout personal health “tricorder” promises to measure a number of vital signs and will even pair with its Scanaflo home urine testing kit. And SpO2 technology, pairing pulse-oximetry with a smartphone, uses the same technology as that in FDA-regulated medical devices. The difference: the smartphone product targets mountain climbers and airplane pilots, not patients.
This convergence of medical and wellness devices means health care providers and mHealth companies now face issues that those in the medical device arena have been grappling with for some time. Strategizing how or if the product will be regulated by the FDA is one such issue. Data sharing is another, leading to complications around ownership and confidentiality of electronic record systems, not to mention access and workflow for an ever increasing variety of health professionals and institutions. And if one of the big promises of health-related devices and apps is that they’ll provide hugely valuable “big data,” then it’s all the more critical that people actually use those devices. Devices that throw too much data at users, presenting it in ways that are far from easy to understand, can ultimately dissuade or downright scare a user.
If you are developing or customizing an mHealth application, or exploring your company’s digital strategy, savvy navigation of the 7 pitfalls outlined below can increase your odds of designing a more engaging, medically useful, and commercially successful mobile product.
Expecting Eager Adoption
Perhaps this happened to you: ablaze with good intentions on New Year’s Day, you pulled out your shiny new sensor and hit the road for the first jog of a 5-days-a-week personal fitness program. Tracking your route and mileage was very satisfying — at least for a few weeks. But as time went on, an inner voice kept saying: “I know I should do this run, but I don’t want to…” Before long, a guilt-ridden mantra replaced it: “I don’t want to look at my records on the website because I know I’ve been bad!”
Minus the initial enthusiasm, resistance to using a mobile monitoring device is very similar for those with chronic disease. Patients who must incorporate medical technology into their lives represent the most extreme example of a reluctant customer — someone who would rather never have to use your product in the first place. For example, someone with diabetes may know that a device to help dose mealtime insulin is critical for his or her health, but unlike a slick new cell phone, they’re not so eager to pull it out and show it off every time they sit down to a restaurant dinner. Routine and social implications can soon overshadow novelty — whether users have a chronic disease or not.
And resistance can be compounded by the emotional wallop of getting bad news. “I’ve been doing everything right, but my weight, heart rate, and blood pressure are still just as bad as before!” When people don’t feel able to control important health measures, they often just don’t want to know.
Increasing the odds of your product being used requires recognizing that human nature comes with innate obstacles to new habits and behaviors, especially health habits. Using the app becomes the first habit to encourage and support. To do that, it’s key to remove obstacles wherever possible. Aim for the most “passive” data upload approach, and certainly avoid docks and wires, software installation, and assembly. Think about “pushing” data intelligently, so that users receive it when and where it’s most likely to get attention and be useful. For example, instead of relying on users making time to sit down at a PC to review their data in a web app, what about sending pithy, actionable text messages when a user gets to the gym, the supermarket, or the doctor’s office?
And since humans are notorious for not sticking to a program when results are incremental or far in the future, find ways to reward use in the short-term — without patronizing users. Be cautious about assuming “gamification” is the answer to turning anything from a chore to fun. Instead, determine whether and just what challenges and rewards truly keep your users engaged beyond any initial novelty. And always strive for the highest level of beauty and usability to make every interaction with the product pleasing and frustration-free.
Healthcare professionals — still new to incorporating patient-provided data and other new data streams into their practices — may also represent “reluctant users,” as may family partners and other caregivers. If you want your data to be used by HCPs, be sure to think through who exactly will interact with the data — and how. Before even thinking about data content and presentation, you need to understand workflow and how that data will be delivered. Will receptionists or technicians pull data off devices or websites to bring to an HCP’s attention? Will the practice need to import your data into their medical record system? Are you asking HCPs to log onto the web to see data, or to install an application on their computer or smartphone or tablet, or to look directly at a patient’s device? Are you expecting a family caregiver and patient to share passwords? Do you need permissions and privacy settings? Start by understanding it inside and out, and be sure your design choices respect — and ideally improve — user workflow.
Greater possibilities lie at the evolving frontier of integrating big data into healthcare systems. How will you help clinicians not only manage, but welcome, the potential flood of information coming their way? This may mean developing new workflows that fit comfortably into medical practices and clinician mindset. For example, data might potentially be sent or shared by patients during a visit or call. Or it might simply be available around-the-clock on demand to a physician via a website. Most radically, it might be flagged with decision-making software and pushed via email or text to a doctor’s attention when triggered (see pitfalls #6 and #7 below for related cautions). What works best may depend on the specifics of your product’s function and on rapidly changing protocols of the medical practices that you hope will use it. Decisions and implementation around these questions will have a significant impact on the design — and successful uptake — of your product.
Letting Feature Creep Engulf Usability
Product designers and marketing teams get excited about features and options, but when it comes down to usability, more doesn’t always mean better. This holds true particularly in medical design, where usability can literally be a matter of life and death. For example, a pump programmed to deliver medication might kill a patient from a use error. Device makers must focus on designing to reduce confusion for safety. This may mean conscious, diligent editing: to limit and channel operator safety-related choices as much as possible; to provide extremely simple, single-decision screens at key points in the interface when choice is necessary; and to shift more complex tasks to areas where they can be accessed by advanced users as needed without impacting critical workflow. Achieving error-free simplicity means evaluating every single demand on a user’s attention.
While the consequences may be milder, consumer software and devices must walk the same tightrope in selecting and culling their features if they want to succeed with users. More features means more to learn, more momentary choices, more settings, more places to get lost when users try to do the basics. In fact, any outgrowths of complex functionality are potential places to lose users who might otherwise have loved your core functionality. While it can be painful to edit out ideas that took a lot of effort to generate, examine every proposed feature to be sure it’s worth the complexity it adds — nothing comes completely free.
And even products that seem stupidly simple can be fantastically effective and successful. Think of the supremely minimal functionality of the Flip video camera; of the brevity and simplicity of Twitter; most recently, of the apparently absurd reductionism of the successful “Yo” app, which does nothing more than allow a user to send text that says “Yo” to a lucky recipient.
Adding to the challenge of balancing usability and features, any consumer device aspiring to find a place in the professional healthcare environment will need to be designed with multiple user types in mind. This might mean the interface has to work for patients, nurses, or specialist doctors, all of whom may have widely different priorities. And the software must allow for identifying user types and accommodating each type’s workflow, without one user’s needs compromising another’s. Tailored user-type interactions might be accomplished via carefully structured interface organization, login types and permissions, selectable use modes, or customized individual setups.
This preference handling also applies on a larger system setup level. Different physicians within one practice may need to individually customize how they analyze or view patient data whereas another practice may want to streamline clinicians’ software interactions by creating a fixed practice-wide setup. Don’t underestimate the importance of making this type of practice-level setup easy for the administrators — it is one of the first experiences a clinical user will have with your product.
Of course, navigating the line between too much and too little functionality in your product is a balancing act. Your most enthusiastic, loyal users may well be the ones clamoring for the deepest functionality. Which leads us to the importance of avoiding Pitfall #3 …
Relying on Too Many “Expert” Opinions
Including Your Own
Device designers often consult with their “stable” of KOLs, key opinion leaders who are viewed as expert clinicians in their field. While KOLs are great at advancing best practices, their background and the usually resource-rich environment in which they work may give them a perspective that does not represent your target market. The majority of clinicians often have less experience with various devices or tools; limited time to spend learning a product or teaching its use; less access to computers or tablets and lack of permission to install apps; or fewer patients who are comfortable with electronic tools.
Similarly, “patient experts” who may be designers or engineers working on a product development team for a chronic disease from which they suffer pose the same risk: while they can prove fantastic contributors for an insider perspective on what it is like to live with a condition, they represent a rarefied type of user. Over-reliance on their input can lead to products with too many features and a complexity level that often does not work well for most users.
Likewise, it’s not advisable to assume that a designer, engineer, project manager, entrepreneur, or expert consultant from the field represents the skills, mindset, or desires of your target market. For teams developing health and wellness tools — often in the startup environment — members may have a passion for staying fit and healthy. However, the market for those products could be people for whom fitness is less of a passion, and more a begrudged chore. Such target users may also be unfamiliar with concepts that are at the core of what the new app or device offers. They might need to be trained not just in how the product works, but in the very principles of health or exercise that it is trying to support. And finally, the immersion experience involved in designing a product can turn any team member into something of an expert — in both the field it is designed for, and in the specifics of operating that product. Those intimately familiar with the evolving design can’t be relied on to judge its usability.
When you want users to evaluate your developing product, whether formally or informally, think through the range of demographics within your market and actively seek subjects who span those categories. This might mean selecting for varied education levels, age, years in practice for clinicians or years since diagnosis for a patient, experience with similar products, inner city vs. rural habitation. Key to remember: define target users up front, and then include them in the most comprehensive way possible in all testing to avoid building a product that simply doesn’t work for your real target market.
Assuming You Know Users
And How They Will Behave
For more than a decade, a large medical device company’s flagship infusion pump had been in widespread use. It was high time for a hardware and software redesign.
The pumps were programmed individually by nurses for safe drug delivery to each patient, and the company envisioned a full redesign of the user interactions required to do this most common task. However, in fear of alienating an existing “expert” trained customer base, the device maker was reluctant to touch the numerous, less frequently used settings. Instead, they planned to leave that part of the UI in the old format, and let users switch back and forth between two significantly different modes.
The UI designers approached the challenge by sharing simple prototypes with groups of hospital nurses very early in the redesign. The feedback including both the “split personality” concept and a full redesign. To the team’s surprise, users were ready to break completely from the old interface in favor of the new — despite the burden of having to relearn the pump. Once the company decided it no longer had to accommodate the legacy interface, a dramatically simpler and consistent UI could be created, allowing the new product to increase its market share.
It’s risky for project teams to overestimate their ability to anticipate user interpretations or behaviors. Research efforts with real potential users reliably yield surprises, often ones that prove critical to the success of the project. Certainly, non-regulated devices, including apps, can allow for changes more easily late in the design process, or even once products are on the market. However, even for these kinds of products, getting it right out of the gate can smooth a product’s sometimes make-or-break market introduction — and save cost over the long term.
It’s important not to confuse user testing and market research. Companies sometimes ask users to evaluate idealized descriptions and images of the products. That may be useful as a starting point to determine what’s worth further development, and how to position the product, but it doesn’t give you the “where the rubber meets the road” feedback that you really need to drive the right and usable features into your product.
Instead, aim to take meaningfully differentiated alternatives out to users at key decision points during development, particularly early on during product definition and feature selection. First design concepts might take a very broad range of approaches and configurations, even including features you’re not sure you can build or that you think most users would dismiss. The goal: inspire conversations with users that bring out their needs and priorities. Once you are in the field, the cost of showing additional broad ideas at this stage is low, and the payoff in “eurekas” that guide your project can be high.
Later in user testing, as you move forward with features, continue to test multiple, slowly narrowing ranges of concepts, and build in the real tradeoffs that design decisions entail. The idea is to give users something concrete to help them figure out what they really want and hence what you should deliver. For example, if a fashion-oriented interchangeable decorative cover makes a smartwatch thicker and heavier, make models people can put on and compare with and without it. If the screen can be customized with a photo, don’t just show the user how pretty it can look. Instead, give them an idea of the steps it will take to do it, even if it’s just with simple storyboards.
The dialogue you are looking for is open and exploratory, yielding comparisons like: “Yes, that looks great, but it’s most important that it’s thin.” Or, “That’s so easy! I’d do it every day.” Probe for the “whys,” for the specifics that might help you get new ideas: “Which would you want to have at home? Carry daily? Take on your trips? Use in a restaurant? Why did you make a face when you saw this? Did it remind you of something? Show me again how you’d hold that if you had to put it on yourself.” And always look for what people do — not just what they say — as they actually interact with your prototype.
Finally, be wary of relying too heavily on user “personas” to drive design decisions. Product design teams sometimes develop a set of fictional people representing expected user types, with their individual priorities, mindsets, abilities, and environments. Then they vet the design against those personas: “Shirley would find this feature much too complicated! She needs to just get the basics done and go!”
Experienced medical product designers know all too well that these constructs are no substitute for testing with real users. As part of obtaining FDA clearance, they must prove usability and design out use errors. This means always going back out to users, not personas, to evaluate what is being created. Personas simply can’t replace committed, ongoing user-testing of features and their execution during a project; they are prone to reinforcing predetermined stereotypes held by the team generating them. Personas may serve as good reminders of who you want to please, but they can only, by definition, tell you what you already know.
Stymying – Or Even Scaring – Users
Imagine a day in the likely near future when sensors in your clothing can keep tabs not just on your workout effort, but on the health of your various organs. This sensor gives you a 24/7 numerical data stream. On the web, you can view a bunch of detailed body-system reports. One day, you get a text alert about an impending heart attack.
Your experience of the product might move through: “What am I supposed to do with so much information? Am I supposed to make sense of this chart? And if all this data is basically telling me I’ve got a good chance of dying soon, I don’t even want to see it!”
Poor design around how data is delivered and presented to lay users could well drive them away. Typical data collected by a “smart device,” and portrayed in an app, might be a set of data points collecting body process measurements over time. Meticulous and thoughtful graphic design can make the difference between instant, intuitive comprehension and utter befuddlement when users confront data. Don’t underestimate the design and user testing effort it will take to create data reporting that users can make sense of, interact with, and draw conclusions from without a frustrating learning curve.
Beyond the basics of data presentation, tools to help users make sense of their data might include flagging a trend or meaningful event, illustrating target ranges, showing progress indicators, using color-coded alerts, or even building in the ability to compare a user’s numbers to those of populations of users. These features can greatly increase the informative and communicative power of your product, but bear in mind that they might have significant regulatory consequences (as discussed below in pitfall #7).
In the case of self-monitoring products that have the potential to deliver potentially jarring news, thoughtful presentation of data acknowledging emotions and behavior can be key to getting and keeping those users. This is another frontier in medical and biotech product design with as yet no clear solution. As a start, some companies such as genetic testing startup 23andMe, have turned to collaborating with genetic counselors to guide customers through their testing results.
A further consideration in the design of data reporting is to what degree that data will be brought to users pro-actively, versus requiring them to seek it out. For example, should a monitoring app alert a user when a metric starts to be of concern? Should HCPs be alerted when a patient’s metrics veer out of target zones? These questions bring up contiguous concerns around privacy and ownership, which are explored further in Pitfall #6.
Perhaps the biggest challenge in making a health and wellness tool truly welcomed by users is whether that product brings a user closer to actually changing behavior, or to receiving a medical intervention. Designers need to ask themselves questions like: “How can this app or device help a user take the information they receive from a graph, and then turn that graph around, towards better health?”
This is where systems and tools beyond just the design of the device and data presentation may become the crucial components of a product’s — and its user’s — success. For example, a sensor might analyze data to make a home diagnosis, and the maker of that sensor might partner with clinics who can opt-in to receive texts or emails when patients are diagnosed by the device. A new health monitor might integrate with a targeted social network, bringing users who opt in together around various shared goals or conditions and allowing them to share problems, approaches, progress, and experiences. A device may need to talk to a user’s cloud-based aggregated healthcare data to start providing truly meaningful feedback, integrated with information from other sources. And perhaps the product itself is envisioned as a tool for habit change, using its sensor-gathered data about a user’s lifestyle to build targeted coaching right into the way it presents data.
Ignoring Complexities of Sharing,
Privacy & Ownership
Scanadu’ Scout promises to be “your doctor’s new best friend,” and suggests: “Dislike the long wait and out-of-date magazines at the doctor’s office? Now you can share data with your doctor from the comfort of your own home.”
“Wellness” data, like the vital signs captured by the Scanadu product, is by nature personal, and essentially medical. As consumer devices offer an increasingly accurate and predictive window into your health, the data they collect is becoming more sensitive and more valuable to a number of potential parties, including health care institutions, insurers, and employers, among others. And as that information moves to networked computers, cell phones, and the cloud, app creators will need to up their efforts in exploring not only how to reap the benefits of all this data, but also how to manage design that takes into account the accompanying risks and concerns around sharing.
Patient-generated health data is a potentially powerful tool for medicine. But how should this data be made available to a medical practice? Imagine an anomalous, worrying heart event captured by a patient-worn health monitor. Is this flagged for the patient? Is the information available to a doctor in the cloud? Is it sent to the doctor, passively by the app, or actively by the patient? What are the implications if a doctor doesn’t look at it, and how is it handled if they do? How does potentially critical information from non-FDA approved device get treated by an HCP? If use of data by HCPs is part of a product’s value proposition, the app maker must explore its relationship with medical practices, and how HCPs really feel about getting this information and the responsibility that might come with it.
Complicating matters further — and mirroring ownership of personal photos in the social media landscape — medical companies and eventually health and wellness companies will increasingly face issues about data ownership. They will also have to grapple with whether the data can be taken away from one party — device company, partnered web-app development company, or patient — by the other. Can it be shared indiscriminately with competitors or peers? What are the attendant medical, legal, and investment risks to the patient, the data service provider, the device company, and the medical practitioner?
Drifting into Uncharted Regulatory Seas
Many don’t think of a smartphone app intended for consumer use as a “medical device” — but the FDA might beg to differ. Their definition of a medical device is based simply on intended function, and risk. A flat wooden stick sold as a popsicle stick is not a medical device. The very same item sold to physicians as a tongue depressor is viewed as just such a device by the FDA, albeit a low-risk Class 1 device.
One of the earliest tasks for any designer of a new health and wellness tool is determining whether a product will require FDA approval before going to market. The FDA offers guidelines that continue to evolve. At the same time, they stipulate that many products fall into a category labeled “enforcement discretion,” in which the FDA will decide on a case-by-case basis whether and how the product needs to be regulated.
Below are examples of products that might meet the “enforcement discretion” category:
- Products marketed to healthcare professionals to support clinical
decision making or diagnosis: A heart rate monitor worn during exercise and marketed as helping users increase their fitness may not require regulation, while the same device marketed to physicians for use during stress testing in the clinic might be considered regulated.
- Products interpreting data or doing “more complex” calculation decisions around that data — as opposed to merely displaying raw data: An asthma app graphing daily peak flows over time is likely unregulated. A version that features data graphs indicating bronchial restriction with a color coded “call your doctor” panic button may require FDA clearance.
- Products “commercializing” existing treatment protocols: Diabetes educators have taught patients how to use standard formulas to calculate their insulin dose for decades. But an electronic insulin calculator using those same algorithms to determine doses is seen as commercializing the algorithm, and hence takes on risk requiring regulation.
- Products employing ever-more-sophisticated technology pushing closer
to putting treatment and diagnosis directly in patients hands: A smartphone medication reminder app, or a post-heart-surgery biofeedback recovery tool might fall into enforcement discretion. As “medical grade” components become commodities, classification comes down to “what are you going to do with that sensor?”
- Products that leverage “big data”: How the FDA will evaluate products that leverage “big data” is a big unknown. Companies working on products in this area will have to navigate uncharted waters, collaborating with regulatory expertise and making regular FDA check-ins.
- Products that incorporate hardware and software: Systems incorporating hardware and software represent a knotty frontier in regulation. For example, a company that creates a regulated iPhone EKG app is considered the final “device manufacturer,” by the FDA. As such, it is held responsible for verifying the safety of all of the device’s components. However, if the phone itself is a component, what responsibilities does the manufacturer have to ensure only proven configurations of smartphone hardware and software revision levels are used?
Those developing an unregulated product should be proactive and determine whether certain features will trigger regulation. Plan your approach with the help of an mHealth-savvy regulatory expert, and contact the FDA early to verify. In the process of talking with the FDA, developers can shape how their product is positioned and classified. For example, if a product won’t be marketed to HCPs, make that clear. Specify that the product is not trying to replace an interaction with clinicians or affect treatment decisions. The FDA’s recent Medical Apps Roadshow offered the analogy of “tax planning vs. tax evasion”: conscientious alignment of your intended use and marketing message may remove the need for regulation.
Strategizing of FDA approval for a regulated product is beyond the scope of this article, but once again, calling on savvy regulatory experts and contacting the FDA early is advised. As a starting outline for planning, make sure sure to get input from regulatory experts at key milestones throughout the project. Those should include:
- Determination of submission type
- Development of risk analysis — and hence your mitigation strategy
- Rounds of formative and later final summative testing (per requirements of HE75)
- Maintenance of ongoing documentation of the design process, which will be part of any FDA submission
- Development of a quality system for production
For companies used to making purely non-medical consumer products, it’s easy to underestimate the design and strategic challenges involved in creating new mobile health apps or systems. Given goals of reducing healthcare costs, improving ongoing user wellness, and fitting into a complex continuum of care, even a well-defined product will likely kick up plentiful, meaty design problems for which there aren’t yet guiding precedents. Build time and flexibility into the project plan, allowing an interdisciplinary team to iterate, test, and evolve the design as understanding grows. We have yet to see any project turn out to be easier than expected.