An approach for unearthing usability issues in web-based systems.
These days people expect so much from a user interface. Thanks to companies like Google, Microsoft, 37Signals and many others, web surfers have come to expect a world-class user experience no matter what application they use. People don't care if a multi-million dollar budget is available or not, the 'big boys' have spoiled them rotten and exceptions are high. This is bad news if you don't have a skilled UI person on your development team (or if you don't have the budget to hire someone for a short-term contract).
The consequence of sub-standard usability on a website may be subtle. For instance; if your online shop crashes when a person adds an item to their basket, they may be inclined to tell you about it. But if it’s something seemingly innocuous like locating contact details inside your 'About Us' page (instead of within a dedicated contact page), there's a good chance visitors wont even be able to find contact details to let you know something's gone wrong.
This is where a usability review comes in (or usability audit if you prefer). Conducting a usability review requires a certain kind of knowledge and expertise not common to all IT professionals. The same way a person may have a knack for SEO or picking up new programming languages, such is the nature of UI design. The intuitive aspects of usability and HCI analysis, like any other skill, can be learned, but not everyone is inclined to do so. Therefore, some kind of guiding template would be useful to those not willing to commit vast amounts of time to mastering the discipline. A usability review can provide just this kind of structure.
What sort of project would benefit from a usability review? Pretty much any system which has been developed without the direct input of a usability expert from the start. If a usability specialist has been engaged from the onset of the project, chances are good that many usability best-practices have already been implemented. In this situation, you'd be better off spending time conducting usability testing instead of investing time in a usability review (e.g. watching end-users directly interact with the system).
So what does a usability review look like? The structure is quite simple; it’s just a Word document full of bullet points describing two things: what the problem is, and a suggestion for fixing it.
You may wish to create a few sections within the Word document to make it more manageable (e.g. Interface Issues, Visual Communication & Branding, Information Architecture, Error Messages, Content & Language, etc).
The big question of course is; what to look for when conducting your review. This is a tricky question because in truth, the answer is far beyond the scope of a simple blog article like this. That said, I have prepared a basic list of a few common UI errors to keep an eye out for:
How long does a usability review usually take? Unfortunately, the deeper you go into a flawed system, the more problems you're likely to uncover. There is sort of a snowball effect, so you do have to decide a cut-off point; how long you are willing to spend reviewing each screen (e.g. 45 minutes per page, including writing up corrective notes). The number of problems you unearth is also a function of your skill level, if you're good at it, UI issues will jump out the screen at you. Another thing to consider is this; there's no point conducting a usability review unless you've done at least the most basic of QA testing (e.g. checking for broken links, alerts for required fields on forms, cross-browser compatibility, etc).
If you are interested in going further into the realm of usability, I would suggest Steve Krug's book Don't Make Me Think. As far as online resources go, you can't pass up Smashing Magazine (although this is heavily targeted towards graphic designers). There is also Jakob Nielsen's useit.com website and Joel Spolsky's Joel on Software website.
Subscribe to RSS Feed.