Loveless Digitalization - eBanking Part 2

In the "Loveless Digitalization" series I briefly present a case of digital transformation that fails to deliver on the potential of possibilities and outline how a better product or process could look like.

The problem:

If you've ever found yourself in a situation of having to issue multiple payments at once, e.g. for salary payments to employees, lucky for you many e-banking portals offer the option of handling payment files. Those files contain structured data, usually in the form of an XML file, that shows all the payments that should be done. While not that easy to read for humans, the files make it very clear to a computer who receives what amount on which account, thus facilitating the process for the person that has to issue the payment: just upload the file, verify the information and authorize the payments.

It is the second step of that process where I've experience yet another example of loveless digitalization, this time in the form of missed potential. Because once a payment file was uploaded, I had to verify the content but instead of the actual content, the system only shows the filename and asks me to verify the filename. You could argue that this is a valuable question as I might have inadvertently uploaded a wrong file. However, the much more interesting information for me to make that judgement would be the content of the file instead of its name. And since this content is already structured and machine-readable, it would be perfect for an e-banking portal to be shown to me and verify the individual payments. Only showing the name typically leads to "rubber-stamping", i.e. simply approving to move on to the next step and issue the payments.

A typical case of not benefitting from structured data and not thinking about a process from the users perspective.

A better way:

Putting yourself in the position of the person that will use the payment file feature you can easily see that to verify the information of the payment file, the information contained in this file is much more helpful than the name alone. Given that the relevant information is already structured in a way that can easily be interpreted by a machine - after all, that's the whole point - a better way for this second process step would be to show a short overview of which person will receive which amount at which date to which account. This would be the relevant information for the person at this point in time. When designing a digital process, we often like to highlight the importance of user-centric design. However, we don't often talk about which user we are actually having in mind and if we really understand their needs. Overlooking this can easily lead to wasted potential of digital solutions, providing only marginal value or even nuisance to the actual users of a digital process. In the proposed better process we would also make better use of the heavy-lifting that has already been done in previous process steps by structuring the data in a proper format.

Thus, if you ever find yourself designing a digital process, ask yourself: what does the data available at this step allow me to do and what information and other needs would an end-user have in that situation.