We as product builders tend to look at all the good case scenarios of success and just a few failure scenarios. But when engineering meets design, there is a lot of empty space where cases are not covered.
Once the user hits an incomprehensive error message irrespective if its their fault or not, they will move on. Since, there are 10s of app to do the same job why will the user be stuck with a mediocre product.
- Suppose you’re trying to pay your Taxation returns to the government but whenever you do the NEFT payment, your payment app tells you “Something went wrong”.
- Here, what did the user did wrong? Was he at fault or was it server side issue with bank? By providing no context or a good error messaging the user is left clueless. User will try to each the customer support to understand what happened thereby increasing the load and cost spent on customer service. This can be averted if we can spend 2 more hours listing down the failure messages in the code.
- Problem with error messaging which has “try again later” is, first it lack context when is later? Is it 1 hour, 1 day or week? At what point user will understand that their payment will never go through? This can make the user really frustrated.
- This error messaging can might as well be “I don’t know why your payment failed but why don’t you try 5 more times before you throw in the towel and switch to another app?”
- When you create/save a new password, Glassdoor tells you that it can’t save password. But what does that mean to the user? I mean what will the user do with that information?
- What mistake did the user make on which he needs to improve? Did he not provide the password secure enough? Is there a network change issue due to which connection break and user needs to try again?
- Why can’t the front end code save the password in memory and try again by itself? How does try again help? Lets say the try again after 3 times also doesn’t work, now the user is stuck and doesn’t know what to do.