The Psychology of UX

A great list, but the first point reminded me of my favourite support story. The application was a medical analysis tool, and there was a pre-analysis algorithm that could be run over a study to assist a human then scoring it.

A user called up with an issue that could only be one of two things - she'd gotten an error box when she'd tried to run the automatic analysis. There are only two errors at that point, and the text in the box tells me which fix to apply. Unfortunately she'd decided that the error box was due to a corrupt file.

"Please read out the message in the error box" => "The file is corrupted"

"Can you please read out the exact text in the error box?" => "It says 'the file is corrupted'"

"I haven't seen that message before, can you please read it out word by word?" => "The. File. Is. Corrupted."

"Okay, I haven't seen that error before, can you please read it out character by character, so I can go to the developers with the exact wording" => "T-h-e a-u-t-o-m-a...." (the start of the sentence "the automatic analysis settings have not been enabled", the solution for which is ticking a box)

This user had called asking for assistance and still refused to read the literal words in front of her until I got down to the character-by-character readback...

The statement that "Make your website more scannable by using less text and adding more imagery (as humans are 90% visual creatures)" sounds as much like dumbing-down as anything I have ever heard, resulting in useless pages that I don't need. In fact at http://uxmyths.com/ myths 4, 7 & 8 counter this idea of more visual being better. The mantra I like more is "content is king". Think man pages. Although a specific use case, man pages benefit from concise, precise information, and pictures would be a detriment. Same goes for most news articles.

Similarly with error messages, the article uses specific errors to make a case and then uses Skype's login to illustrate the "right way". These are two very different use-case shapes being forced into a square hole. As many of us here should know, there is nothing worse than a fuzzy, warm error message that can't be searched online or in documentation. Sure, errors should not be "error: 0x15654213!" but should include enough information for the user to solve the problem (and please do not use exclamation marks in errors!). Often, some technical info, even if just an error code and a short description are enough to resolve the issue. If you can't log in, as in the Skype example, well, it's one of two things 99% of the time. You probably don't need to google that.

I like the rest of what the author has to say, especially that part about developers getting to do it over and over while UX is expected to be right first time (assuming the place you work actually does UX, mine doesn't and the results vary greatly). My workplace doesn't test either which I think is a huge mistake (so much so I almost couldn't write this sentence without swearing). That's something I am trying to change.

Citation needed? If true, that would be a nice parallel to modern operating systems and processors.