Last Updated on
If you’re a web designer or an operating system developer, all those systems have users. Most of the users that will be utilizing your software won’t be as technically experienced as you. Yet we keep blaming the user when something is wrong. Here are some truths about those users:
Users aren’t stupid.
The system or application you designed just isn’t easy enough to use. This means that you need less complexity (preferably without losing functionality), simpler layout, and better explain to the user how to use it.
Users aren’t lazy.
Only very few users want to master the application they are using. Most of them just want to get their things done. So don’t expect them to know the system in and out. When they need an option that’s hidden away, why not point them in the right direction with some friendly text or a link?
Users aren’t incompetent.
As said before, most users aren’t technically experienced, so why not use ordinary understandable language? Words and phrases everyone can understand. The number of errors that occur (and frustrations that arise because of those errors) will also shrink when the user understands better what you expect from them. Why not even give them a hint? For example, the format you expect a date to be in.
Users aren’t perfect.
There will always be errors that occur, may be due to user input, maybe not. It’s the task of the developer to handle them and handle them nicely. Don’t be ashamed that something goes wrong and hide it. Tell the user if an error occurred, why it happens, and how it can be prevented (or when it will be fixed in case of a system being down, for example).
So by keeping these 4 truths about users in mind, you’ll develop better software.
The user experience of negative replies
Ever needed to build a website for someone or wanted to sell an item like a car and the buyer says: “I’ll let you know what I decide”? Now when he/she actually wants your item or service, you’ll hear from him/her, obviously. But when the deal doesn’t go through, you can keep waiting for an answer.
This also can be reversed…Imagine you want to buy a new cellphone, however, it’s not available at this time but that it will be in a week. So you ask the seller to let you know when the new shipment arrives. After waiting two weeks, no word yet. You go back to the store only to hear that they have been delivered 5 days ago.
Both of these situations are examples of bad user experience, where the first will leave you dissatisfied with that client (you’ve probably invested time to come up with a proposal for that website or taken time to show him/her that car), the latter gives you a bad impression of the cellphone store and maybe choosing another one next time.
Both situations can leave you with a better experience if there just was a little communication even if it were negative: “I’m sorry but I’m no longer interested in that website/car” (if you’re lucky you’ll get a reason) or “I’m sorry to inform you but the cellphone you requested is out of production”. You prefer a more positive reply, but now at least you’ll know and the experience won’t be as bad.
In the situations above you are the one who is experiencing them as bad. But imagine a client who sends you comment or e-mail to request some information or letting you know their complaint. (Be happy you get that comment or complaint, less than 1% of your users actually takes the time to send you something, it’s the best measurement of how you’re doing).
Instead of not answering those emails or letting them sit for weeks, answer them sooner, like the next day. If you don’t have an answer yet, say something like: “Thank you for your question. I don’t have an answer right now, but I’ll have one within a week”. (Now don’t forget to deliver that answer within the week, even if it’s to report you can’t help that person.) This will leave the client happier than you think and he/she might even return later because their experience as a user/client wasn’t that bad.