Technology has a way of evolving and forcing change, even without user, consumer or even developer consent. Nowhere is this more evident than in mobile applications. According to the Pew Research Center, smartphone penetration has not only surpassed half of all mobile subscribers, but has gone well beyond 50 percent of all adult Americans.
The continuous stream of hardware and software features enabled on these devices continually pressures IT professionals to identify innovative mobile-use cases and deliver enhanced customer experiences. For insurers already viewed as late to the technology game, many challenges stand in the way of delivering a fully functional mobile product, and a few even demand new ways of thinking about how we develop software.
Unfortunately for insurers, designing a mobile app is quite different from other kinds of applications. An app can't just be an extension of prior work on the desktop or Web. Consumers are more tech-savvy and well-informed than ever before, and devices have more inherent intelligence via sensors, portability and connectivity. Unlike prior generations, generation X and generation Y consumers can tell the difference between an app that is view-only and one that is truly transactional. And nearly-surreal user-experience (UX) expectations make each interaction important. Every glance, every tap and every gesture is expected to bring something useful and even, dare I say it, fun. That said, insurers are in the business of insurance, so developing mobile apps and functionality is far from intuitive.
One trend that's helping insurers is that we've transitioned to a time when "less is more" in the user interface. Not long ago, Web developers constantly pushed for a larger default screen so that more content could be crammed in front of the user. However, developers now are expected to know what content is relevant so that it can be placed within a thumb's easy reach. With two major operating systems, iOS and Android, designers also must account for platform differences. For best results, separate, specific apps must be created for each operating system. Most often, an app is developed for either iOS or Android and then ported to the other system, rather than creating a new app for each, which typically results in poor ratings. This is because the two operating systems are different and require different coding for the functions to perform as the creator intended.
On the back end, few, if any, core administration systems are ready to deliver data to these new minimalist designs. Counting on a service-oriented architecture (SOA) already in place is risky and naïve, and while you want to avoid getting mired in the nitty-gritty details up front, the project specification and ideation process must also consider development of a new mobile/Web API; native clients for Android, iOS and HTML5; phone and tablet support for mobile and HTML5; questions about usability vs. functionality; integration with back-end systems; and authentication of policyholder information within the app itself. Fortunately, ACORD's XML standards provide a way to transfer large amounts of data between systems cooperating in a transaction. But, mobile apps think in such terms as "experience API," where tiny amounts of JSON-formatted data are exchanged to support a given user intent.
Combining those considerations with the large number of users that you hope your app will be used by, it's easy to see why out-of-the-box SOA isn't mobile-ready.
Even if you can write a great mobile app, chances are you can't fully test it. Initially, testing strategies in mobility are the same as for any other kind of software. However once all test cases pass on a single reference device, the fun really begins.
Now you have a whole new set of worries. How does the app work when not connected, partially connected or, worse, when interrupted by a phone call? How does the app look on devices with different screen sizes, such as an iPhone 4, iPad Mini or iPad with retina display? Does it work the same on iOS6 and iOS7, or when location services are disabled? Will it have landscape and portrait viewing capability? And, finally, will you only focus on iOS and Android phones? These are only a few of the many concerns that must be addressed and become part of a solid test matrix and regression test plan. In the end you have to pick your battles and settle on a target subset of platforms, devices and features that make sense for the app's most-likely users.
Mobile app development may sound harder than you thought, but not all is doom and gloom. Clearly, there are thousands of high-quality apps available today, so there must be sound software development methodologies that address mobility's unique complexities. Mostly, they are agile methods with three embedded caveats: create clean, purposeful designs; connect with lightweight, experience-driven APIs; and target testing for the intended user base on a subset of devices. Remember that with the accelerating rate of change in mobility, an app is never really done.
Douglas Moore is the chief technology officer for ISCS.
