I think user experience goes beyond stuff like where your button is placed, is it going to be a menu or a side bar, how many taps are needed to get that thing done. It’s about how the user ‘feels being with’ your product. More and more, with the invasion of people’s time by mobile computers, if you may call them that, people talk more to software than even to the most intimate person in their life! 😉 So their feeling of goodness of being with the software is taking more priority than ever before!
Having said that, a key aspect, often overlooked in my opinion, is handling of the situation when things go wrong.
As a designer, we often rather think about, say, ‘How do I add a user?’ … a button click … a menu? … or a sub menu?, but we don’t spend as much time to think of ‘What could go wrong when attempting to add a user?’ Things can wrong owing to two possible disturbances (yes, ‘disturbances’) :
1. within the user
2. within the software
When something goes wrong with the software, we know it because we wrote that bug 😉
But what when something goes wrong with(in) the user? Say, he’s upset that some big deal was lost, or is simply in an urgency to get something done. What is common to both these scenarios is that the user is ‘under stress’, which means his tolerance is really low. If someone is stressed and you point fingers at them, you know they are gonna thrash you! This is a crucial design principle. When a user is stressed and he does something wrong with your software, don’t say
“You got it wrong!”
that is, some message like
“The number you entered is invalid”
Instead take the blame on yourself and say
“Am sorry! I don’t think I understand”
That is, in our example
“Sorry! Could not read it. Can you try that number again?”
Which subtly puts the blame on the software and makes the user more tolerant to try again.
Coming to the more crucial aspect of ‘transparency’ or the lack of it! Rarely do we realize that the lack of transparency stresses the user, especially when something doesn’t work.
This is as much true, as it is with the relationships in our lives.
While this seems a no-brainer, it has subtle yet crucial lessons that we often oversee. When an error is spit from the product, we don’t pay much attention to how we deal with it. How this error impacts the user is a complex thing ; it depends on a variety of other not-in-your-product details like
Has the user used a competitor’s product before?
Has he used any such software before?
What brand image does he have about your company?
Has he has any previous distasteful experiences with your company’s other products?
How old is he?
How has his day been so far?
… And so on
So you can instantly see that a user may be very tolerant and go past the error point very quickly depending on many other things than the error itself; or the user may get frustrated and close the App (or even the subscription!) at that point depending again on variety of complex factors underplaying in his mind. Yes, you know how many times your product lost a subscription owing to this!?!
Take, for example, this scenario handling by Google:
I was logged into Playstore Developer Console (this is where you submit new versions of Android Apps for release into Google Playstore) in one browser tab. Then in the other tab, I had gmail open. In this gmail tab, I signed out and signed into another Google ID. Now, I go back to the Playstore developer console tab, and tried to upload an icon image for the App. It threw error saying “upload error”.

It took me a while to get what happened. Definitely, in the inside code that executed, Google knew it was owing to the login ID being different than the one it expected. Now in this scenario, you can visualize the three points I discussed above on handling the situation.
1. Be Open : tell the user whatever you know. If the software can get more detailed information on the error, then tell the user about it.
For example, if you are unable to connect to the Internet, don’t just say “Could not connect”. Instead, say what information you have gotten from the network connectivity API (but in non-technical terms!) -> for example, “WiFi signal seems weak.”
2. Show Intention : show your true intention in helping the user get his thing done
In the above error message, we could instead say “WiFi signal seems weak. Can you move closer to the router or move elsewhere?” ; or we could even go a step further to offer to store it offline and sync later.
3. Assure Resolution : or atleast alternatives. Tell the user how he can get his stuff done, and not let this error get in his way.
Ending this argument, it’s essential to stress that error handling is a key aspect in product management, and should not be left solely to the developer. Atleast handling of the key and common error use cases should be discussed in detail by the product manager. This plays a key role in retaining users of the software and in giving them an increasingly feel-good factor that this software wouldn’t let them down!






