How enterprise app user interfaces need to change to accommodate machine learning probabilities
My plan for making AI simple, not complicated, for the millions of business software users that learn to co-exist with thinking machines and software robots.
Business software has looked pretty much the same since I started working in tech 21 years ago. Fields crammed next to each other, and some tables with all the data. And buttons that presumably do some things.
Admittedly, there has been a transition from heavy client-based apps to web — but the real impact on user experience remains mostly cosmetic. Just look below, and I’m sure you know what I am talking about. Everyone has seen these over and over again.
We live through a more drastic change than I have experienced in my career before. Even bigger than the demise of Nokia, which was obviously a big thing in my home country.
To this date, a field in a business app has had pretty much two states and two only: filled or empty. Look at the example below, the field has a value— or not.
There is nothing in between and no way of indicating something that might be, but not 100% sure. The uncertainty. Or probability. Why this is important, you may ask!
Enter machine learning.
This is not an article about opportunities AI brings to enterprises, since you surely have read your share about this topic. I am talking about a fundamental change in user interfaces in all business apps, regardless of the use case. It can be SAP, Salesforce, QuickBooks or Basware.
Businesses are increasingly adopting technologies such as RPA or intelligent automation to harness the power of AI in automating their processes. These processes often take a shape of a sequence of actions in the business software mentioned above. For example, read an incoming invoice from a vendor, map its data against the master data, decide some accounting parameters (like GL code that I had in the previous example field), review/approve the contents and input the invoice in the ERP system.
I’ve been working on multiple such automation projects, and there is a common problem arising. When using machine learning to predict some values needed in the process, there is no “native” way in the business apps to indicate that the values come with uncertainty.
The automation works alongside a human user, as there is not likely to be 100% touchless automation. Key concepts are confidence and threshold: how sure the ML is about its own results, and what the organisation has set as a limit to be “sure enough”.
For example, a software robot might use machine learning to predict the most likely GL code(s) for the invoice, and the result could be “This invoice should be accounted to GL code GL-4100100; with the confidence of 0.78.” If the company, in this case, would have set the threshold to be 0.8 for automation to progress without human review, this particular case would end up being looked at by a person in the accounts payable department.
Now, there is no way to communicate the confidence of the predicted value to the user in the majority of the enterprise app interfaces. The sub-optimal solution is often that RPA engineers end up writing the additional machine learning output data into some notes or comments fields, where the user needs to look for them.
What if we would actually build the user interfaces to accommodate the fact that some fields are filled by the user, some by ML — and create a way to indicate the confidence right there in the field?
Let me elaborate on this through some examples. Bear in mind that I am not a user interface designer, so the illustrations below are mere concepts. I wish they trigger the interest of a designer to make them real one day!
Human filled value vs ML prediction
Whether it is a software robot or API that manipulates the value after prediction, today, the result looks just the same as the flesh-and-blood user would have entered it. Like you already saw in the example above.
A human operator would benefit from an immediate visual cue of the source of the value in the field. In my example below, the machine predicted fields come out as fluffy grey thicker stroke, where human entered “facts” retain the standard solid black stroke.
Indication of confidence and threshold
In the automation workflows, the confidence threshold determines which values are automatically used and which ones are reviewed by the user.
I have found that confidence and threshold are generally not well understood. So it is our job to make them comprehensible.
The trouble arises from the fact that the right threshold value can be wildly different from one field to another. It’s different for GL code than for profit center. So showing arbitrary values for confidence, like 0.9221434 or 0.732123, don’t really make much sense to the user, yet this is what you most commonly see in the comments field.
What if we would indicate confidence with simple traffic lights?
The proposed approach omits the actual value on purpose; it merely displays the colours: green for confidence being greater than the chosen threshold, yellow for values close to the threshold and red for way below the threshold.
By moving the configuration of threshold to settings controlled by automation professionals, they are able to adjust the process values without any visible change to the end-users.
Accepting and rejecting predicted values
Let’s assume that the above GL-code predictions are made, and the confidence was below the threshold. So our case here needs review. In the current model, where the machine and human inputted fields are equal, there is no immediate and simple indication of what has been done. Maybe a user needs to manually write an audit trail, which easily kills the entire idea of automation!
I am proposing that there should be an easy way with one click to accept or reject the value and change it to a “reviewed” state. This approach serves few purposes. First of all, now it is safe to write even low confidence values into fields to assist us, humans. The assisted automation brings benefits, as often even the lower confidence predictions might be correct. Second, the review “clicks” can be immediately fed back to machine learning as new training data points.
Explainable AI — explained.
What were the factors behind this particular GL code prediction? Why does this always go wrong? What was the next best alternative? There are moments when more information than the mere field value would make sense.
For those moments, we need a tooltip (and by now, I had already exhausted all my design skills 😬).
Machine learning platforms like Aito.ai provide a simple view of the main factors behind the predictions — which features had a positive lift and a negative lift.
Yet again, we should not fall in to trap of thinking that a user in the accounts payable department values the scientific approach. We need something understandable like in the above picture, plus and minus symbols to indicate the top contributors to the prediction.
Similarly, the tooltip can accommodate the next best prediction, with a way to easily flip that value into the field. The possibilities are endless!
What I am proposing above is not only a minor tweak in the UI. I consider usability and understandability being fundamental factor in making use of AI spread wider.
It is our responsibility as designers and creators of these systems to make sure we don’t add more complexity, but use this as an opportunity to simplify and make work more pleasurable for the millions and millions of people who use these systems daily.
I hope you are on board with me on this!
I have worked with enterprise software since 1999. Currently, I am an Executive Chairman and CPO at an intelligent automation company called Aito.ai based in Helsinki, Finland.
