Adobe’s Ethan, Ted and Ryan recently gave a big thumbs up to Firebrand an RIA for watching adverts.

Niels Bruin responded with what I think is a very good wake-up call to the starry eyed approach to reviewing web apps with lots of transitions, reflections and other shiny bits. Niels highlights some real basic usability faux pas that Firebrand made such as mystery meat navigation, red punishing looking confirmation messages and inconsistent design touches.

To be honest, I read all the commotion and Niels put down before I looked at the site and to be fair to Firebrand I probably wouldn’t have picked up on those points myself. But then I’m not and would not claim to be a UX hotshot of any kind. The key point for me is that the points raised by Niels do not require a magical usability eye and could very easily be a printed checklist and implemented as part of a quality control assessment before final delivery of a product. To be fair I do also agree with the points Ryan makes in his followup and I’m also all too familiar with things such as expectation and deadlines which can all to easily prevent this much-needed attention to detail. However, if we keep reminding ourselves of it then hopefully it will become second nature and not needed as a time consuming afterthought.

If you’re responsible for the creation, delivery or quality of a customer facing project, take 20 minutes, open up your word-processor of choice (perhaps use it as an opportunity to try out Buzzword) and hack together a simple list of quality control checks.

Here’s a handful of checks plagerised from Niels post and an old post I remembered by Aral to get you started, copy the below and paste into a document, print out 10 copies, run through your current project and tick each one off and you’re well on your way to becoming a quality control engineer!

Niels’ Firebrand wrist-slap:

• Make sure any icons/metaphors are extremely obvious or explained with tooltips or other indicators
• Make confirmation messages look positive and warnings look like warnings (I.e. don’t positively confirm an action in red)
• Is everything laid out consistently? How much effort would it really be to tweak that button a few pixels to line up properly?
• Can familiar controls be used in a familiar manner? E.g. can I scroll a scrollbar using my mousewheel, drag it and click up/down arrows?
• Have you tested on all likely platforms/browsers? At least WinXP, Vista, Linux, OSX with IE6 & 7, Firefox, Safari, Opera

Aral’s old post on UI principles (interpretation by moi for checklisting purposes):

• I can use it but am I a ‘typical user’? Even better: can I get an intended user (or several) to use it?
• Does validation “prevent not scold”? Does the user get scolded “YOU IDIOT, WHY DIDN’T YOU SELECT A GENDER BEFORE CLICKING THAT BUTTON?!” or do we just make the button un-clickable until the gender has been selected with some unobtrusive instruction to do so?
• Does the user receive sufficient feedback? If the user makes an interaction, is it obvious that interaction has been acknowledged by the app and the expected result has happened? (see Niels point on adding to faves).

There’s a load of other things that can be added to this list, for generic testing and I’m sure for specific audiences/companies/application types etc. I’m going to do some digging on other principles people have come up with as I know there are a ton out there but whilst this is topical I thought I’d add my opinion and throw in a call to action to anyone reading.