Developers, especially those new to mobile and internet of things (IoT) application development often choose technology which is of most interest to them or that they are most comfortable with. This approach might enable a faster ramp up, but it means that the app could be running on the wrong devices, requires more support, have security challenges, etc. While most of these issues can be resolved with little tweaks and adjustments such as adding an extra library or tunneling into some native code, eventually the resulting app is based on workarounds and is a nightmare to support.
The end goal is a tech stack that makes sense, both for the targeted users and the development team. In addition it must be something that can be supported throughout the lifetime of the application. Before choosing a platform or technology, consider the following questions:
Which platform do your target users use?
- Are you trying to deploy to multiple platforms?
- What is the competitive landscape?
- What skill sets does the development team have?
- Who will be supporting the application once it is built?
- How does the technology ensure security?
- How will the application deployment be handled?
Once the functionality of the app is known and the above- mentioned questions have been answered, review the various technology options available: Native, Web, Angular, Kendo, Knockout.js, PhoneGap, Bootstrap, Xamarin, etc. There are pros and cons associated with every approach, and ways of mixing them together to get a tech stack that supports the application now and into the future. It may not be what you know right now, but using the best tool will save you plenty of time in the future.
High Value — Low Effort is Key
People will resist (or even worse ignore) ‘technology’ if it has a low value to effort ratio. Numerous examples of failed applications clearly demonstrate this. Still, many technology driven organizations succumb to the mistaken belief that “if we build it, they will come.”
As well, the success and popularity of Lean philosophies has led many to develop and launch a minimal viable product as quickly as possible. The key consideration to remember is that if there is no perceived value by the end user (e.g., is it worth my time downloading and using this), then it doesn’t matter how well- designed or “cool” your app is, it will ultimately fail.
Ensuring that there is a mechanism to allow users to perform a task either more efficiently or, alternatively, enabling users to do something they have never been able to do before is essential to success.
Let’s consider the consumer app market as an example. Today, there are financial institutions that allow their customers to deposit a check by simply taking a picture with their mobile phone. How could this be applied to the healthcare application market? For example, health insurance users submit their medical and drug related receipts via their insurance provider web portal. They are still required, however, to manually enter details online or mail them in order to get reimbursed.
One option to consider is to allow users to take a picture of their invoice and submit it directly for reimbursement. Would this alternative option make a mobile app worth downloading?
Users would no longer have to take a copy of the bill, go online, sign-in, and finish form completion. And the best part is that the experience on the desktop is not ported to the mobile. The scenario above increases user efficiency, value, and more importantly customer loyalty.
The bottom line is that engagement is contingent upon providing customers with something they value, simplifies a task, and / or allows them to do something they couldn’t do before.
Designing for Mobile
Based on our experience, attempts to transfer an existing experience to a mobile environment can become an exercise in feature—yoga, where a large feature—set is bent out of shape to fit on a mobile device screen. Although a product team might desire the mobile experience to be complete, cramming all the features in a mobile application is rarely the right answer.
When crafting a mobile experience, the limitations of the device (screen size, touch keyboard, and spotty network) force application design to focus more intently on the user’s context. The term mobile context is often fraught with misconception in terms of conveying the notion of one eye, one thumb, and distracted users. While this may be true sometimes, it is important to remember that a user in a mobile context is usually trying to accomplish a task. Further, more often than not, this is the one task that they focus on in the moment.
Thankfully, the mobile device is often more aware of the user’s context than a desktop. This awareness provided by sensors for location, ambient light, motion, or proximity can be used to counter the limitations of the mobile experience and fill-in gaps in the interaction that would otherwise have to be provided by the user. For example, knowing which room you are physically located in would allow a mobile conferencing application to easily transfer a call to an in-room speakerphone.
When thinking about the mobile context, take into account tools such as cameras, microphone/headset, SMS, email, or push notifications that are part of this environment. These tools shape the interaction with the application in a way that is much more natural for a mobile context. For example, if entering a lot of data with the touch keyboard is difficult, why not rely on the camera or the microphone to perform data input.
Consider a scenario where a physician who is performing rounds does not want to carry a laptop and may not have time to stop at a fixed workstation between every patient. A mobile experience that is aware of the physician’s context would “know” which patient is in each room on the schedule. The mobile app could notify of any critical information needed as the physician enters the room, allow the taking of photos for added information, record voice notes, and then let the rest of the patient care team and the EHR information system do the hard work of connecting all the patient data parts together and attach them to a single patient record.
A truly differentiated mobile strategy is one that considers the user’s context, the mobile devices’ inherent capabilities, and the context and environment in which the user is using it. It all comes down to delivering value and aligning with the target user’s goal. Done well, this results in the user feeling as though the mHealth app has made their life easier, more efficient, and even satisfying.
TIP: Understand Your User
If you’ve not done so already, take the time to review our user section. Thinking about things like putting your application into context and asking yourself who your end user really is are critically important to being able to answer basic questions on how your app will be used.
TIP: Interruption Storyboard
Review our section on storyboarding for an example of a physician’s day. How could this research help you?
Download The Complete Guide to Engaging Digital Health Software