Tuesday, June 22, 2010

Why patient empathy is challenging for manufacturers of medical devices


A hot topic in the design world recently has been the importance of building empathy between businesses and their customers, a concept well documented in the book Wired to Care, by Dev Patnaik and Peter Mortensen. The basic case for empathy is actually pretty intuitive-by spending time with customers a business can better understand their needs and therefore deliver better products and services that more effectively meet the needs of customers. Formal efforts to build empathy with customers have been underway for quite some time with consumer electronics products (a classic example might be Jan Chipchase's globetrotting research conducted for Nokia), but one area where there remain structural challenges to building and capitalizing on empathy is between medical device manufacturers and the patients who use their products.

A fundamental dynamic of the medical device industry is the disjointed relationship between the patient, doctor, healthcare administrator, and the medical device manufacturer. This relationship is especially complex in the case of sophisticated devices that are not sold directly to patients and which are instead sold first to doctors or hospital administrators and then resold (via a prescription) to patients. The following diagrams illustrate (in a simplified manner) how the sales channels are structured for a typical sophisticated medical device versus a typical consumer electronic product.


While there are some similarities between the two models (for example both have "middlemen," the Doctor and the Retailer), there are two important differences between the two models: (1) the medical device model contains an "Administrator" component, and (2) the sales flow to the patient in the medical device model is a PUSH flow, whereas in the consumer electronics model it is a PULL flow. While the presence of the Administrator component is indeed an important part of the medical device sales model, this analysis is concerned with the effect that PUSH vs. PULL relationships have on how much weight is given to empathy for the end user at the manufacturer during product development.

In the above models, a PUSH flow represents a decision made by the giver/seller, whereas a PULL flow represents a decision made by the receiver/buyer. For consumer electronics, the sales flow model is straightforward. Consumers own the purchasing decision, and—simplifying greatly—if they value a product, they buy it. if they don't value a product, they don't buy it. Whether from a Retailer or directly from the Manufacturer, the flow is always PULL in nature. As such, the Manufacturer has a natural incentive to build empathy with Consumers. After all, by better understanding their Consumers, Manufacturers can better meet their needs and ultimately sell more products.

For sophisticated medical devices, however, there is a structural challenge that puts Patients one step removed from Manufacturers. For medical devices, the flow starts with Doctors and/or Administrators choosing (via a PULL flow) which devices to stock, a decision which Patients-who can only get a device through a Doctor's prescription-are essentially stuck with regardless of their individual preferences. In other words, Doctors/Administrators (I'll refer to them simply as "Doctors" for the remainder of this post) PULL devices from the Manufacturer and then PUSH those devices onto patients.

As a result, for medical devices Doctors emerge as the primary customers and Patients become secondary customers. As decision holders, Doctors hold a tremendous amount of very concentrated power. Naturally, this results in Doctors having a rather strong voice with the Manufacturer, who from a first-order economic incentive standpoint has every reason to bend over backwards to please the Doctors. So employees at the Manufacturer spend time with Doctors at conferences, training sessions, or advisory boards collecting quantitative and qualitative information and all-the-while forming empathic bonds with Doctors. Patients, however, end up getting short shrift, something that's easy to justify when Patients account for approximately zero direct revenues. As marketing personnel tally their annual market research budgets, it's easy to conclude that the benefits associated with building empathy with Patients do not outweigh the costs, which makes the decision easy. After all, why spend time learning about and building empathy with Patients when they never buy anything?

So does this mean that Patients are forever destined to miss out on the benefits that arise from building empathy? In my next post, I will discuss some possible solutions for helping empathy become a vital part of the medical device development process.


Image from here.

Disclaimer: I work for a large medical device manufacturer (not the one that made the device pictured above.)

Saturday, June 19, 2010

Android vs. iPhone: Which is more open?

Guest-writing at Megan McArdle's blog, Timothy B. Lee riffs on the growing frustration that developers have with the closed nature of the iPhone platform versus the relative freedom offered by the open Android platform. I agree with Tim that this is a big weakness of the iPhone and that--if Android ever gets its act together--this could be the Achilles' heel of the iPhone. In thinking-out-loud about how Android could get its act together, I realized that there is one area in which the iPhone is more open than Android: the user interaction paradigm.

One of the main differences between the iPhone and Android respective user interaction paradigms is that Android has two off-screen buttons--one for moving Back within or between applications and one for accessing a Menu of actions available within each application. The iPhone puts this functionality in the screen, which whether by design or by chance ultimately leaves the decision of how to implement this functionality to the designer of each application. The net result is more user interface (UI) freedom on the iPhone. This may seem trivial at first glance, but upon further inspection I think that there's actually something significant there.

Granted, app developers still have to concern themselves with Apple's Human Interface Guidelines (and straying too far from these could--based on Apple's ambiguous approval rules--result in an app getting rejected), but in practice there is actually considerable diversity between iPhone apps. The downside to such freedom is a lack of consistency, but the upside is that market forces within the iPhone App Store can function to separate the apps with bad UIs from the apps with good UIs.

In contrast, Android's interaction paradigm (with the two off-screen buttons) is somewhat constraining from a UI perspective. Granted, there is probably a lot of diversity between Android apps, but they all suffer from the usability handicap created by being forced to use off-screen buttons. This handicap makes it all the more difficult for Android apps to truly break away from the pack in terms of user experience. A mobile platform is only as good as its apps, and one of the main things that makes an app good is a good user experience.

So I would argue that neither the iPhone platform nor the Android platform is as free and open as a mobile platform could be. The best solution would be a platform that has no constraints on how applications are coded (like Android) and gives UI designers maximum latitude for creating compelling interactions (like the iPhone).

Image from here.

Android Gingerbread should get rid of the dedicated "back" and "menu" buttons

According to this TechCrunch post, Google is going to be improving the user experience of its Android mobile operating system. This is great news, and I'm sure their improvements will go further than simply making the graphics "prettier." In my experience using Android on the HTC Hero and the Google Nexus One, the thing that hurt the user experience more than anything else was Android's poor usability, particularly with respect to navigation. The two big usability flaws were: (1) the use of a dedicated hardware Back button for navigating within and/or between applications and (2) the chameleon-like Menu button that, when pressed, opens a popup menu of actions the user can take within the specific application being used.

First, the Back button, which is the leftmost bottom below the screen on the Nexus One, pictured to the right. My main beef with the way it's used is that it's really easy to get cognitively lost, especially when you start shuffling between applications. My recommendation for the Android user experience (aside from hiring me!) would be to scrap the whole idea of stacking. For in-application navigation, put the "Back" button on the screen, since that's where the user's attention is, anyway. It's how the iPhone does it and it works great. And for between-application navigation (i.e. multitasking), adopt the "deck of cards" metaphor employed by Palm's WebOS. TweetDeck's iPhone client also uses the deck of cards metaphor and it's not only easy-to-grasp, but also sort of fun to use.

Now, the Menu button, which is the second-to-left button below the screen on the Nexus One. From my experience this was even worst than the Back button. The reason the dedicated Menu button is so frustrating is that it's highly unpredictable. I'm actually pretty surprised that Android ever even went with such a confusing feature, as it violates one of Jakob Nielsen's heuristics--Consistency. (Nielsen's heuristics are fundamental to the field of usability.) Since each application will almost certainly have its own set of commonly used actions, access to those actions should not be forced into one single button. The iPhone handles this quite well by letting each application define for itself how to give users access to common actions; usually applications put four or five buttons along the bottom of the screen, each representing common actions. And then maybe the last of those buttons is a "More" option, which brings up a little popup menu.

For both the Back and Menu buttons, from my perspective the key to improving usability is to move functionality away from dedicated off-screen buttons and onto the screen (where the user's attention is). These changes would put Android approximately on par with the iPhone for usability.