Application design in the times of RPA

Different type of application interfaces

Software applications need interfaces to interact with users and other applications. The interface for users is intuitively called the user interface, and the interface for other applications is called the API (Application Programming Interface). APIs used by developers to enable communication between applications through programming and hence called a programming interface.

At the heart of RPA is the idea that a software application could also use the interface designed for human users in a similar manner – through the keyboard and mouse.

Should we design applications to be RPA friendly?

The question is, given the fact that RPA is becoming more and more prevalent, should application user interface designers start considering “bot” as another type of user persona?

I think they should and here are my arguments for it.

Most applications used in every enterprise will be a part of an RPA use case soon, if not already. Why not tout a “bot-friendly” design as a selling point? RPA practitioners will tell you that often automation is made harder because the user interface is harder to automate because it is “user-friendly”, meaning it was designed to be intuitive for the human user. Providing a bot-friendly user interface would make it much easier for RPA tools to automate the application. This could be a second, alternative user interface without affecting the core application logic. I know this is a reality because one of our customers is considering replacing a legacy COTS application. While considering an alternative application they are making sure that the RPA tool that they are currently using can easily automate its user interface.

But why should the product vendor go out of the way to help the RPA developer? What is the incentive?

A few software vendors have already started toying with the idea that if the end-user is a robot, the price of a “seat license” should be higher. That is perfectly understandable because robots will end up consuming fewer seat licenses than human users for accomplishing an equivalent quantum of work. Why not introduce a bot user interface and add it to the new licensing scheme?

One argument against this could be, as a product designer, why should we spend the effort to develop a bot interface when we can design APIs that bots, as well as other applications, can use?

There is another less obvious reason why product vendors should consider this.

APIs are always limited and can never be as rich as their cousins, the user interface. APIs are mostly stateless, data exchange mechanisms with no contextual information or business logic. They do not represent effectively a “session” between applications. Contrast this with an RPA scenario. Through RPA you could have application A to start an action, navigate to a particular screen with live data, and then transfer this data to another application B in flight with context and as a part of a meaningful business transaction. It is as if we have a screen to screen API with rich business context, data, and logic. It is no longer appropriate to denigrate RPA as “screen scraping”. Can product designers come up with APIs as rich as this? It would be difficult and prohibitively expensive to do so.

Application vendors can also provide web forms that match each of their API calls. These webpages can then be accessed by RPA tools to interface with the application rather than, developing adaptors which are often wrappers around REST, SOAP, or other clients.

Many of the RPA use cases revolve around going through a series of screens in one or more applications to complete a transaction where data is read and/or entered. These steps are then repeated many times in a session at a high speed which essentially provides benefits. What if the applications in scope already provided a method to upload a file that contains the input data in a predefined format, and the application had the design smarts to loop through the input data and feed itself? That would eliminate the need for APIs or automation in many cases.

Conclusion

The initial pitch by RPA vendors was that application integration through API is expensive and time-consuming, and RPA is the easy solution that can be implemented quickly at a lower cost. A problem solved, though temporarily, is a problem forgotten. With the implementation of RPA, you also incur technical debt and a barrier to further change in the near term. Because of these reasons, RPA once introduced will be hard to replace. Another aspect that makes it harder to replace is its integration with other complementary technologies like BPM, Imaging/OCR/Data extraction, AI, and ML. It is already being thought of as a mainstream integration technology that brings together these powerful functions.

That being the case there is merit in designing applications with digital workers in mind.