UX and integration of systems
Integrating different systems is as deep as you can possibly go when it comes to software development. There’s a lot of unknowns, a lot of assumptions, a lot of matching and mapping data between different models, and usually not enough documentation to go along with this.
We always try to keep these nasty integration challenges out of the sight of the end user, wrapping things around in logic that tries to make complicated flows into simpler ones, or hiding certain errors by treating them as we see fit in the business context we are working with, or many other tactics, but there’s only so much that can be done.
There are many situations where an integration is the only way to go, take for example your common e-commerce scenario where the user needs to pay something using their credit card. In this scenario we need to talk to the bank to ask for the credit value in the account of the end user to know if he is able to pay for whatever is on the shopping cart, and that is usually done by a payment provider.
So let’s go about it step by step, the online store system integrates with the payment provider system maybe through an iFrame or something similar that usually can be styled in terms of colors and fonts to be align with the online store design. The payment provider in turn integrates with the bank system out of sight of the end user, needing some special authentication and handshakes to prove they are who they say they are and can ask for this sensitive information. The bank says that the user has credit to the payment provider, and the payment provider tells the online store what the bank said and the user gets a nice sucess message if they have money to pay for the shopping cart. Now the online store will generate a receipt and integrate with an email server to send a friendly text message with the information of the purchase and the attached receipt. This whole chain of integration is nowadays something pretty ordinary.
However, most of the times the response that a payment was successful that the end user gets on the moment of payment is not really a success from the payment provider system, it’s more of a “we think it will be a success because there was not straight away error” and the actual success message comes later on, eventually. The email is usually just sent when this final success message is received.
For the end user this is the best experience possible, because in their perspective “I wanted to pay and it worked instantaneously”, but this is not the reality under the hood. This is UX being the driving force at its fullest.
Let’s change our mindset to a different scenario, a bit more generalist. When we get into an app or site that has a lot of dependent systems we use loading strategies to mitigate the problems of an integration. The interface is built in a way that we use modules that are independent of each other in terms of rendering, and this would allow us to treat a module that is somehow dependent of an integration to have that little loading circle while the rest of the modules are already loaded and visible. Now we have the ability to handle the worst case scenario of errors and chose to never load the module that depends on the integration, or be more transparent about it and make it react to an error notifying the end user.
Integrations have a lot of engineering behind it and they bring many variations to the scenarios of a system, this is why we need to take them into serious consideration when we are thinking about the experience of the end user, because they bring many variations of scenarios.
Next post in the series:
UX and documentation
Documentation is of extreme importance to end users and not what developers like the most to do.
Previous post in the series:
UX and the technology stacks
In the context I’m referring here, a technology stacks are the languages, frameworks or tools that are used to build…
This is part of a series of posts listed here: