Design Stories from a Health-tech Startup
Designing technologies and services within the domain of health and healthcare systems is a tricky endeavor. There are extra rules, extra hierarchies, and many unknowns for the first-time healthcare-area designer. In this article, I provide some practical guidance through stories of four helpful and not-so-helpful actions I took designing my first health-tech product.
I. Find inventive ways to get close to your communities and capture domain expert insight as quickly as possible
For an interface designer, knowing a doctor’s jargon and thought flow is essential in order to create an easy-to-use comprehensive system. To better understand the needs of doctors in the UK, we looked for sustainable ways to create ongoing conversations with physicians. Along the way, we jumpstarted a currently thriving online community called The Doctors’ Digital Collective (DDC).
This group, which recently celebrated its 1,000th member, fit a niche need covered by no other entity. The DDC supports doctors who are developing technologies to improve their practice. These projects run the gamut from better hospital ward documentation, to kidney stone trackers, to case-report apps, and many more. Practitioner community members provide both feature ideas and phenomenal feedback during beta-testing phases. These “techy” doctors enjoy the community support and circulate posts about learning to code, learning to sell tech products, beta-testing requests, doctor-relevant news, hackathon invites, logo feedback requests, and many other topics, all flying by on the central forum “digital stream-of-consciousness.” Additionally, the warm connections generated by this group are fantastic, a valuable situation within the complex National Health Service (NHS).
Other ways to get in touch with relevant communities include inquiring about related non-profit groups. When non-profit members buy into your vision, they can help connect you to the right people with social capital and deep insight into the pressing current issues. They can also let you know what solutions have been attempted successfully and unsuccessfully in the past.
II. Learn from the full breadth of diverse stakeholders
Health-tech often throws a new wrench into the design process: frequently you are designing for multiple stakeholders, whether you realize it or not. The first question posed by Dr. James Kelly, an investor and health technology consultant, regarding every new health technology endeavor is, “who pays?” Using the DDC described above, we were able to customize our technology to the needs of doctors, but, we ultimately aimed for purchase by hospital administration. If, as was the case for my first foray into designing for doctors, the design team plans to have hospital adoption or even the magical purchase, then there is necessary work which must be done to understand the needs and motivations of decision–makers at the hospital. To sell our HR SaaS (software-as-a-service) technology, we had to speak to the CCIO (Chief Clinical Information Officer), DME (Director of Medical Education), head of HR, and finance personnel at each hospital. This was critical in order to put together an “economic argument” for why the hospital should purchase our software.
III. Share the Economic Argument (even if your product is free)
An economic argument shows, in most cases, how much money and time (preferably both) a hospital will save by using your new technology or service. This is the language of decision-makers, so new product developers, sharpen your financial skills! The hospital often wants to know these figures over a 3- to 5-year period. These arguments are particularly effective if you know the specific troubles and goals of the particular organization. Are there important new regulations to follow? Has a chunk of money just been allocated to funding a specific area of concern? What are the priority directions for change over the next time horizon for the hospital? These questions can be addressed through thorough research and conversations with those “in the know” at the hospital.
You may be thinking — “well, that economic argument is important only if you’re trying to sell it, but I’m working on a non-profit/academic project, so I shouldn’t have to worry about that.” Even in these cases, decision-maker goals and buy-in should still be considered. A hospital is a hierarchical environment full of time-poor people. If the use of a product is not actively agreed-upon and encouraged, hospital members are likely to be: 1) not incentivized to use the new technology (which, as we designers should remember, often requires a laborious process of learning how to use the product, trying to fit a new behavior into their busy schedule, and then even harder, adopting it into a daily routine), and also 2) practitioners may be worried to use a technology not sanctioned by the hospital.
IV. Gain Organizational Buy-In
Our major sales and implementation problem centered around a lack of organizational support for our product. We built a mobile safety application compliant with a new government mandate and offered it free of charge to practitioners. People were initially excited to try out the technology, but then did not want to use it at work, worried that they could get into trouble (or at worst, potentially jeopardize their careers) by using our technology. Part of our problem was that we had expected enforcement of the new legislation, but the legislation soon showed it had no “teeth” to enforce action and behavior change. Without that push, hospitals had no external incentive to pay for a new technology or even to recommend its free use within their hospital. Had we prioritized the hospital administration and decision-makers earlier in our design process, we would have realized sooner the importance of pairing our safety app with an e-Rostering system. It became apparent during our early sales attempts that hospitals wanted both of these tools together as a package because rostering was a related and much more important headache for hospital administration.
One can (and I indeed might) spend a career discovering particular nuances that support successful design and implementation within healthcare. This article presents a tiny step toward a more specific design process for healthcare. In summary: identifying ways you can get close to your communities, capture domain expert insight, learn from all relevant stakeholders, build your economic argument, and gain organizational buy-in will support a broader and more informed design process for healthcare technology products in hospital settings.
