Healthcare Customer Experience Improvement with Low-code
Jan 2, 2023
Our recent blog post on low-code use cases in the healthcare sector identified speed of change as a crucial factor when sourcing software solutions. This post aims to delve deeper and show why CX improvement and low-code form such a strong partnership.
Customers often don’t know what they want
It has been said that “The trouble with customers is they don’t know what they want.” But assuming you know what’s best for your customers can be the most dangerous thing.
This is why digital customer experience improvement is best achieved using a “test and learn” approach.
As Eric Ries advocates in “The Lean Startup,” test and learn is about making vastly better and faster business decisions—bringing lean manufacturing and agile development principles to the process of innovation.
Test and Learn in a Digital Context
The idea behind test and learn is to provide users/customers with the earliest opportunity to provide feedback and improvement suggestions for the product or digital user experience you’re proposing to provide.
Instead of sinking months of development into a full-featured deluxe product, you use prototypes or minimum-viable products that can be delivered in a matter of days. You learn what works much more quickly and definitively in demonstrations or controlled experiments. You discard features and ideas that don’t work, and you double down on the features that do.
In the case of digital customer experiences, the question of what works is—like beauty— in the eye of the beholder. Until you show the intended user experience to customers, high-quality feature requirements and feedback are extremely hard to achieve.
Which brings us back to the notion that people don’t know what they want. Endless rounds of requirements gathering are ineffective, time-consuming, and often wasteful.
They lead to assumptions, which are often quickly disproven when users and products come face-to-face.
Where to Apply Test and Learn?
Although a test-and-learn approach is much better for capturing requirements, you cannot use it for all development projects. The IT industry has long understood that different kinds of systems deserve different development and governance regimes.
Gartner, an IT industry analyst firm, borrowed some facility management principles first described by Stewart Brand in his book “How Buildings Learn.” He proposed that buildings’ fabric should be categorized according to their pace of change.
Furniture and carpets wear out quickly. Wiring and plumbing have a slower pace of change. The building’s structural steelwork changes minimally, if at all.
Gartner repurposed these principles from physical architecture to IT architecture, coining the phrase “Pace-Layered Application Strategy,” which they described as a methodology for categorizing, selecting, managing, and governing applications to support business change, differentiation, and innovation. The following diagram illustrates the concept.
Pace layering envisages three categories of software applications. As indicated on the left, those that change with the greatest pace are at the top. Those that tend to require the most stringent governance are at the bottom. The following adds more detail to the concept.
|Systems of innovation||These represent new and potentially disruptive ideas. These are typically in response to competitive threats or opportunities. Time to market is a critical concern. Such ideas benefit from experimentation—rapid iteration and, if necessary, the disposal of failed ideas.|
|Systems of differentiation||These represent business processes for which off-the-shelf solutions are a poor fit. They can also be areas of competitive advantage—representing the unique propositions or capabilities of the business. These tend to be established processes subject to continuous improvement.|
|Systems of record||These are common ideas where businesses can follow industry-standard ways of working. Financial accounting is a good example. Such systems are often subject to heavy regulation. There are dire consequences if a business fails to maintain compliant financial accounts, so changes must be carefully controlled.|
From the above descriptions, it’s evident that the sweet spot for a test-and-learn approach is innovation and differentiation rather than systems of record.
Why Embrace Low-code for Systems of Differentiation and Innovation?
Several characteristics of low-code application development make it the ideal partner for innovation. Most obviously, four to ten times faster delivery. When development is in response to competitive threats or opportunities, speed of delivery is of utmost importance.
Deploying a solution in days or weeks rather than months or years can mean the difference between survival and business failure.
Equally, if you’re at the sharp end of disruptive innovation, you need permission to experiment, i.e., to fail fast, repeatedly, and cheaply. If you can build a prototype or minimum viable product in a few days, embracing risk is much easier. By comparison, you’re unlikely to be granted the same freedom to experiment with traditional hand coding. No one welcomes throwing away weeks or months of coded development.
Another advantage of low-code application development is reducing IT administration overhead. Traditional development involves a lot of repetitive heavy lifting to provision development, testing, and production infrastructure. At CDR, we use the OutSystems low-code platform. Virtually no time is wasted managing IT or Cloud architecture, as all the required DevOps tools are included in OutSystems. Deployment becomes a one-click exercise with dependency checking and roll-back built-in.
Looking at Healthcare CX Improvement Through a Pace-Layered Lens
Digital customer experiences such as enrollment, claims, and various e-health scenarios represent systems of differentiation and innovation. Those experiences may require access to systems of record such as customer/patient master data, but the specific experiences you want to provide are unlikely to be satisfied by off-the-shelf, highly governed, and slow-to-change systems of record.
Take enrollment, for example. Like any other customer onboarding process in numerous industries, the team responsible for enrolment should constantly iterate to maximize conversions. Using web analytics, they can identify steps in the onboarding process that are hot zones for abandonment.
In response, the team adjusts the enrollment journey, perhaps moving specific questions or data capture steps to later in the process. Maybe the language on the webpage needs simplifying? Just changing the form layout and button colors can improve conversions.
Many of these changes deserve a test-and-learn approach. You can use A/B testing to try different designs and enrolment paths.
Rapid visual development with a low-code platform like OutSystems makes this easy and affordable. By comparison, a high-code approach is too slow and costly.
Experimentation is a must when you’re at the forefront of disruptive innovation. What you’re attempting might never have been tried before. You don’t want to stymie such innovation with the risk of having to jettison months of development when ideas receive unfavorable feedback.
With a low-code-powered test-and-learn approach, you’ve got the speed and agility to experiment rapidly. That’s why we think CX improvement and low-code application development are a marriage made in heaven.
Editor’s note: Although this article particularly advocates using low-code for systems of innovation and differentiation, it can also be used to create systems of record, often referred to as “Core Systems.” Read “Mission-critical Low-code Apps” to learn how low-code platforms can deliver enterprise-grade scale, security, and UX.
Our portfolio includes a wide variety of low-code healthcare case studies. There are almost endless possibilities for low-code in the healthcare sector, so why not get in touch with one of our industry experts to discuss your requirements?