For the most part, the secret of successfully implementing a consumer-focused mHealth program includes similar elements of a portal implementation and include actual users into the design process to ensure it is patient-centric. They have more in common with the keys to launching a successful in-person behavioral change program than something radically new, despite the fact that this seems contrary to the mHealth buzz.
In fact, many mHealth programs have failed because lessons learned from other successful consumer-facing implementations were forgotten. Here are some tips about the things that matter when launching a program for consumers – along with a few tips about differences in mHealth. As Section 3 is focused on organizations, additional resources for providers to consider include Selecting a Mobile App: Evaluating the Usability of Medical Applications, 5 FAQ's for App Development, and the HIMSS mHealth Roadmap.
During the inception and design phases of a project, it is important to be absolutely clear about the program goals. Start planning to measure success. It is important to demonstrate to the program team and leadership that the goals are both clear and measurable.
It is also important to be sure the program solves a real problem for the target audience. Far too many apps and systems fail because the problems they’re solving aren’t fundamentally important enough to the target audience. As Judy Mottl said in a Fierce Mobile Healthcare article, “…while a doctor may prescribe a smartphone app for enhanced treatment or efforts such as weight loss, it comes down to the patient's perception of whether such a tool is worth his or her attention and time.”[xxiii]
To create and deploy a usable and useful app, bring actual users into the design process early – in this case, that probably means patients, caregivers and the medical personnel (nurses and doctors and staff) who will coordinate the program and use the data. Some tips for user-centered design in mHealth have been provided by Eirik Arsand, PhD, a research scientist at University Hospital of North Norway. He shared his experiences from designing apps for patients with diabetes over a period of more than 10 years. Specific tips from Dr Arsand include:
- “Recruiting and involving users early;
- Listening to users’ needs and suggestions;
- Having open discussions around the possibilities and techniques available;
- Using quick prototyping through iterations;
- Testing in real settings without the fear of modifying the previous design due to test results; and
- Building on the test results to further improve designs.”[xxiv]
The early design phase is also the time to determine whether to launch mobile health applications or a version of a website that is optimized for mobile devices. Early mHealth applications were primarily mobile versions of web applications, but that is changing as developers take into account the benefits of applications that use capabilities unique to mobile phones, including location sensing, context sensing and photos.
Think through the mHealth application distribution process. Will the program provide the devices used to run the apps as well as the apps themselves? While some programs have had success in packaging apps on tablets or smartphones, there are concerns to be overcome with this strategy. It ensures that everyone in the target population has a device on which to run the application(s), but it also raises the cost of the implementation significantly – and with it, the requirement to show sufficient return on investment to justify the additional cost. With a device-purchase strategy, there is also the question of what do as the devices age, as well as whether they truly become the users’ device or whether it is a device used in isolation for medical purposes. It is important to remember that one of the things that make smartphone applications useful is the way they are ubiquitous: always with the user on a device that they use for a wide variety of tasks. Providing a separate device strictly for mHealth use, reduces the likelihood that the target audience will consider it theirs and bring it into their lives.[xxv]
If the application is not being supplied to the target user then it is important to consider how to identify the app in each of the online stores. Is this the only app the organization will offer? If not, carefully consider how to identify individual apps within a family of applications, and what will happen when another app for the same or a slightly different population comes into play. This branding issue is somewhat different for mHealth applications than for other kinds of programs, which simply direct users to a central site where they can find their way to the capabilities that are attractive to them. With mobile apps, it is important to market individual applications in the online stores using some sort of brand identity that indicates they belong to a family of applications from the organization.
Decide on which operating system(s) the app will be coded early in development. The ideal approach is to will use a set of tools that allows the app to be coded once but deployed across multiple platforms simultaneously. This decision can have a significant impact on the lifetime cost of maintaining an application.
It is always a good idea to pilot any consumer application with a small audience before expanding broadly. A pilot allows an organization to test its procedures and its assumptions. The pilot design should incorporate testing of documentation, support processes, scripts, distribution approach, and marketing and communications materials. Above all, however, the pilot permits testing the assumptions made about the behaviors of both the target audience and staff.
During the pilot phase, it is especially important to gather feedback and review needed changes. In a development cycle where everyone is eager for launch and where the pilot may seem like the ideal phase for “making up” time lost to development delays, it is critical to success to build in time to gain sufficient feedback from the pilot process – and have time to fix the most crucial issues before the launch.
The pilot is also the time to test a support plan. If there is no quick response plan when people encounter issues with the app, it can quickly lose credibility, and the resulting negative “buzz” can kill the launch.
Last, but surely not least, the pilot is a great time to make sure internal staff is comfortable with all of the components of the mHealth application, as their ease with the tool and its capabilities will have a significant impact on the comfort level of the target users.
The success of any mHealth launch hangs on the same issues as the success of a website and many other consumer-facing programs. Key elements to consider include:
Marketing and communications plan
It is crucial that the plan incorporate both communications to internal staff and marketing to the target audience. Take a page from successful web site launches and think through how the messages about the mobile application will be communicated at every appropriate touch point in the organization.
Is this an application that is aimed at everyone in a population or only a specific subgroup of people? If it is a subgroup, it is critical to think through how the staff will identify the people who should hear about the application. If, instead, the app is designed to provide mHealth services for everyone, it is important to have communicated and practiced scripts for every touch point, from appointments to rooming to the doctor’s visit. Each channel may need slightly different – but still coherent – messages.
Test the messages and channels in the pilot stage, as it is important to tweak anything that is unclear before the app is finalized. By tracking the doctors, nurses and clinics that are most successful in gathering users for your mHealth application, it becomes easier to broadly disseminate their effective practices within the organization.
Note that while marketing is a crucial aspect of a successful implementation, there is, as Joanne Rohde, CEO of Axial Exchange, says, “… clear delineation in our data in patient engagement between those institutions where clinicians are driving a program with measurable clinical results than those where marketing or IT is leading the program.”[xxvi]
As noted in the pilot section, a plan is needed to address questions and problems that users report, and it is critical that to respond quickly and get the word out to other users and staff. Unaddressed problems – even if not considered critical – can snowball into a perception that the application is failing and subsequent loss of confidence, both with users and staff. Clear communication about any issues and the plan for fixing them can address those kinds of issues before they cause the launch to fail.
It is important to plan a strategy for measuring success well in advance of the launch. Do not assume it will take a long time to understand the user experience. There are a number of ways to get indications of success early on in the process that will help the organization determine how well the roll-out is going:
- What are the interaction levels?
- How many complaints or questions are there?
- How often is the app being downloaded and used?
- Is the intended audience the audience actually using the app?
- Is there any social media “chatter” about your application or its launch?
There are many potential long-term metrics of success for a mHealth initiative. It may be successful based on clinical outcomes, sustained use, costs saved or loyalty to the institution. Whatever the goals for the application, it is critical to create programs to track and measure indicators of success from the beginning.
Remember to apply the many lessons of successfully launching consumer-facing programs in the context of mHealth, taking into account a few additional features and issues.