People Don't Want to Work or Think More Than They Have To
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...
Let's all remember that UX (& IxD!) should be based on research and testing, not on assumed patterns.
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.
> 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.
This is the biggest problem, I think - the conception of UX without "user" work.
This doesn't mean only testing per se, but any kind of empirical or data collection work (from using anthropological methods early to strict usability testing). If a given company is not doing any of this, then they're not doing UX at all. If they're not in contact with the user in any way, then it's not UX.
Having someone creating UIs in Photoshop is not UX and this is, I think, the biggest and most detrimental misconception of the field.
Great book indeed. Not quite as easily-digestible, but also very relevant and still well-readable: Jeff Johnson's Designing with the Mind in Mind [1], unemotionally explaining the psychological principles behind common HCI guidelines.
"While the time spent in the role activation stage may be minimal, it quickly adds up when you continually switch back and forth. And once you switch from one task to another, _it takes an average of 23 minutes and 15 seconds to get back to the original task._ "
I wish they would have better explored "2. People Have Limitations" via mental models and not been biased by "(as humans are 90% visual creatures)." Designing for and separating visuals from content can strengthen not only the user experience, but make accessibility elegant, instead of simply possible.
Lots of food for thought. A more practical approach is this list/listing tool: http://userium.com because that has stuff translated to practical terms.
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...