Creating Expectations

We seem to forget that whatever we put on a screen, card, form, or whatever we choose to expose our data with, creates an expectation with the end-user. “Whatever we put” means messages, field labels, or any other text and graphic we choose to communicate something.

It is something I come across on an almost daily basis, apps or websites using words that create an expectation of what I can or must, or should do. This past weekend I wanted to make changes to the notifications I receive from my bank (ABSA) when transactions take place. Parameters that can be configured include delivery method i.e. SMS or eMail, and transaction type i.e. current, savings, etc.

Great functionality but so badly implemented that it boggles the mind. The purpose of these notifications is to notify the account holder when there is activity on an account and contains no confidential information that might breach the security layer i.e. even if I receive a notification from an account not owned by me I cannot use any of the information in the notification to access the account.

Issues

ABSA made two very important mistakes when they designed and implemented this functionality.

a) They used bad terminology on their website. The use of ‘Manage recipients‘ creates the expectation that I can in fact manage the notification for a specific recipient. This is in fact not so. None of the parameters for this function can be managed by the end-user and this is a very bad interface design

b) They chose not to provide the functionality so that the end-user can make changes at their own convenience and any change must be done via the support line, which is a bad implementation in itself. The reason why they do this is unclear since, as mentioned previously, the notifications do not breach anything, be it security or confidentiality. This implementation makes a joke of the user journey and takes it from something that could take less than a minute to do to a process of over 30 minutes.

Resolution

The resolution for this is so simple it is actually painful to type.

• Use terminology that make sense and creates the right expectation. Repeat after me ‘terminology is important’.
• Understand the user journey and where their pain points are. Focus on aleviation those pain points. Making a process longer that it should be does not aleviate anything.
• Remove complexity from the end-user and take it upon yourself i.e. move complexity to the backend where the end used does not have to deal with it. Just removing complexity al together often means the oppisite, you move the complexity onto the end-user so that you do not have to deal with it. That is like stealing pension money from a pensionare.