Want to excel at customer excellence? Take a "low-code" approach

Earlier this year a paper was published by market research and advisory, Forrester Research. Titled "New Development Platforms Emerge for Customer-Facing Applications", the report lit a fire under numerous tech companies across the globe.

Championing systems which were intuitive, easy to use, quick to turn around and most importantly, measurable, the study heralded the advent of a new "low-code" approach as the answer for companies looking to engage with their customer quickly, intelligently, and in a across different channels.

However low-code is still an incredibly new term, and like "big data" or "cloud" before it, many outside of the tech world are still largely unfamiliar with what it is and what it can do. I spoke with a co-author of the Forrester Research report, Clay Richardson, to shed some light on low-code and why you should consider this approach to speed development for customer-facing apps.

Craig Sharp: Good morning Clay, thanks for joining us today.

Clay Richardson: Good morning Craig, it’s a pleasure.

Craig Sharp: So you and your co-author, John R. Rymer coined the phrase low-code in your July research report?

Clay Richardson: I hesitate to say we were the first to coin the term. When we began our research, we really started with a premise that said we believe that customer-facing solutions require a faster development and therefore require less hand-coding. How do you build a system of engagement rapidly that meets customers’ needs and also does a better job of connecting customers with employees?

We interviewed a few dozen companies for the paper, and we’re conducting further interviews at the moment. What we found as a consistent theme for companies building these customer-facing solutions and systems of engagement was that they did confirm that they were using these newer platforms to quickly build in a more visual development environment. Less hand-coding was required; these companies needed something where there wasn’t as much developer involvement and something they could use right out of the box.

Low-code or Zero Code?

Craig Sharp: So where does the name low-code come from?

Clay Richardson: We initially played with the term "zero-code", but when John and I stepped back and started doing some of the analysis we realized it wasn’t zero-code at all. No one told us there was no code, what they were saying was that 80% to 90% of development was visual, with another 10% to 20% of hand coding where a programmer could come in and clean up the last little pieces. That’s significantly better than what we’ve seen historically.

Ten years ago you would see significantly more hand-coding for the UI, for personalization, even for the processes and rules. The term low-code represents a significantly lower requirement for hand-coding, making the development tools much more accessible to a layman.

Test & learn is key

Craig Sharp: I’ve been trying to understand the terms myself, and I’ve been likening it to WYSIWYG (What You See Is What You Get), which of course has been used in development for years with the likes of Drupal, Wordpress, Conduit etc. Is that a fair assessment?

Clay Richardson: You could think about it like that, the visual interface at least. But I prefer to think about low-code more for its other benefits – the key is the ability to test and learn.

When you think about customer applications, you’re building something that a customer is going to interact with or that an employee working with a customer is going to interact with… You’re building this access point that a customer is going to interact with and with the best will in the world you’re never going to anticipate all of their requirements.

Some of the companies we spoke to are building these solutions and experiences that they had never had before, so there was a great need for them to be able to build something, test it out, and learn what works or doesn’t work on a very quick turnaround to ensure they were meeting the customer’s needs. The key is that low-code platforms allow you to build quickly, roll-out, get feedback and then update and amend your apps and platforms very quickly.

You need WYSIWYG tools, the ability to visually drag and drop, test and learn, build quickly and change quickly without a lot of IT involvement. That’s the key to low-code.

Craig Sharp: How do current providers fit in to low-code?

Clay Richardson: If you look at current providers, BPM solutions for example, they’ve always had this visual configuration that we talk about in low-code. I can easily model out a business process, I can easily build out a form. Where current solutions need improvement is around analysis, because a low-code environment is really about test and learn as I said before.

"Low-code" resonates in the BPM space due to the quick modelling for orchestrating interaction, and of course for the UI design – being able to quickly, visually model the user interface and actually build something that is quickly deployable. Some of the vendors out there do this very strongly – MatsSoft and K2 are a few good examples that combine strong user experience design and process design.

Intuitive design

Craig Sharp: So user-friendliness is key to a low-code platform too?

Clay Richardson: Exactly. The low-code platform has to be intuitive to the point that it doesn’t require a significant amount of training. Intuitive also extends o the end user – so the solutions companies build have to be "intuitive-now", something that a customer can pick up and use right away.

Craig Sharp: As with all new terms, there seems to be an air of unfamiliarity around low-code. Do you think the term has reached the point yet where it resonates with end users or is it still very much a vendor-driven phrase?

Clay Richardson: It’s interesting. John and I have fielded customer inquiries where the term is used, but what we’re seeing more is customers asking how they take a more app-centric approach to BPM, how to use it more from a low-code perspective. They don’t usually use the term, but there is a clear shift towards this way of thinking.

I think before the term catches on with the end users, we have to really promote a low-code approach to building solutions. We’ve been really good with this in saying it’s not just about the technology, it’s also about adopting new practices. In this way, having a low-code approach becomes just as critical as having the right technology to support it.