3

When a transaction cannot be completed in my banking software, we display an error message to the user.

In the back-end, we do not know whether the problem is temporary or permanent. We also do not know if it is the user who is doing something wrong.

Currently, the same error is displayed under all circumstances. The first line states that the problem should be temporary. On the second line of the error explanation, the user can read some details and decide on whether to try the transaction again.

Our aim is to drive the customer through the transaction.

Should the generic error message saying that the error is temporary remain, or should only the specialized error message be shown? If only the description is shown, would that result in more users attempting to go back and fix their errors?

Improve this question
8
  • "...user who is doing something wrong.". Assuming inputs are validated and preprocessed both client and server side then this should be a completely different and well handled case. Nothing more annoying than "operation can not be completed" when I forget to enter my birth date. For the other part (assuming it's not an invalid input)... always says it's temporary problem and in this case users don't need more intimidating details (just a short error code, maybe, to help technical support).
    – Adriano Repetti
    Commented Nov 12, 2015 at 9:02
  • It's about trust: nothing is permanently bugged in your site, at maximum there is a temporary error (and users don't need to know if it's because of a bug in your app or a problem in national Internet connectivity).
    – Adriano Repetti
    Commented Nov 12, 2015 at 9:03
  • Thank you for your answers. My problem is I cannot differentiate between temporary errors and user's breach of a trx rule that will prevent user from completing it forever. So if i am to choose one of the warnings, which one should it be? Temporary or ever?
    – pilachka
    Commented Nov 16, 2015 at 21:43
  • Then you may try to be honest, ask them to double check their inputs and if they are correct then try again later. It's not nice feedback (IMO) but thousands programs give this kind of generic messages. Bad but acceptable if you can't do better.
    – Adriano Repetti
    Commented Nov 16, 2015 at 21:46
  • My bank always gives a cryptic error code without any other information. I hate it but...that's it, if you try to be nice then at least they'll be less mad...
    – Adriano Repetti
    Commented Nov 16, 2015 at 21:47

1 Answer 1

Reset to default
1

Sorry to disagree with your assumptions, but a software that cannot distinguish between (1) invalid input, (2) a temporary failure (such as a sub-server not being reachable), or (3) a crash in the main algorithm will not support a good User Experience. Never.

Error messages are rather useless if they do not tell the user what he can do to fix the error. The first prerequisite for this is to know why the transaction failed.

So the first issue to fix is to change the "back-end" so that it can return an appropriate description of the failure.

  • Invalid input: Then mark the erroneous fields, indicating whether it's a missing mandatory field, or a specific date format is required, etc.
  • Temporary failure: Say it's temporary, explain the trx is queued, and offer to inform the user (by email, SMS, ...) once it is completed
  • Crash: Apologize (I like Mozilla's "This should not have happened"), and present a real-life contact the user can tell about the failure as well as finish the trx (ultimately, this is what I need a bank for).

This sounds costly, but if I was to find out that the so-called "temporary failure" of my important trx messed up one of my business relations, I would switch providers (does not apply to banks only). In the end, this may be more costly than paying for a decent back-end implementation.

Improve this answer
2
  • Thank you for your detailed explanation, may be I could not explain it well. Fields are filled with valid information. But customers overlook filled fields and do not realise that the information is outdated (the office address of an old employer or an old phone number) So we cannot differantiate by analysing the data inside. We have to test it to understand whether it is up-to-date or not. We don't want to require all customers to fill in those fields.
    – pilachka
    Commented Jul 29, 2016 at 7:09
  • But you surely have a phone directory and can validate the phone number entered? (I don't understand why a wrong phone number would block a trx, though.) Maybe I don't understand what you mean by "a transaction cannot be completed"... I agree your system cannot check for all outdated information (i.e., I customer phone number changed), but you could add a safety net by sending a confirmation email ("We received your request to call you back on <phone no>"), so that the customer has the chance to recognize he entered the wrong number if your bank doesn't call back.
    – virtualnobi
    Commented Aug 24, 2016 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.