Conducting a Usability Review

An approach for unearthing usability issues in web-based systems.

You don't see the spots before your eyes until they are there.

- Chinese proverb

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.

For example:

• Use of ‘click here’ hyperlinks - this is dated and passé (also poor in terms of SEO).
  Fix: remove instances where ‘click here’ is used with hyperlink (e.g. ‘click here for sales enquiries' would become 'make a sales enquiry').

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:

• Flag distracting animations as a usability issue (e.g. Flash)
• Show the file size of downloads (e.g. Annual Report PDF - 200 KB)
• Watch for poor typography usage (e.g. small fonts for headings)
• Keep an eye out of misaligned controls and UI elements.
• Review online forms for consistency (e.g. widths of textboxes)
• Be watchful for unintuitive error messages written by programmers
• Is there online help for complicated forms or interactive tasks?
• Should form fields marked as required be optional instead?
• Are required fields obviously marked in some way?
• Can some labels on forms be shortened (e.g. 'Phone' to 'Ph.')
• Should some labels be expanded to become more understandable?
• Are large images used which do nothing other than add load time?
• Are JavaScript pop-ups used for error messages?
• Is a 'No records found' message shown for unsuccessful searches?
• Can a user tell where they are within the website?
• Is the navigation structure unnecessarily deep (>3 levels is bad)?
• Are there graphics anomalies (e.g. overly compressed JPEGs).

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.

Article Adjunct

• Usability reviews should be done after conducting at least basic/ad-hoc usability testing with a few users.
• What you find during user testing should dictate what issues you address first (before a usability audit).
• As a developer or system architecture working with the software on a daily basis for long periods of time, it becomes easy to miss problems staring you right in the face (i.e. you can't see the forest for the trees).
• If the usability report is expected to be seen by non-technical stake-holders, it's a good idea to include a short summary at the beginning of the document. This would outline the most important findings of the usability audit.
• The suggested fixes contained in the audit should also under-go user testing. It's always possible that the suggested fixes don't solve the problem (or they may even introduce new ones).
• Ideally, the best time to conduct a usability review is early and at multiple stages throughout the SDLC (not just as an after-thought at the end of a project).

- Contributed by Moin Uz Zaman, Senior Usability Specialist

Subscribe to RSS Feed.

Consistency in Web UI Design

How to keep your software's UI consistent when many programmers are working on the project.

In a development team with half a dozen programmers all working on the same project, creating a uniform user interface can be a nightmare. There can be problems ranging from inconsistent use of icons to language (e.g. formal vs. informal). So the question is, what's the best way to achieve a cohesive user experience?

Few would argue the importance of UI design these days, especially since companies like Google and Apple have spoilt users with dazzling almost joy-to-use interfaces. But a functional application is still more important at least initially, you can always pretty things up once your software actually works.

When working as a UI designer, it was my responsibility to create mockups for the application being developed. Once I had created the HTML and image files in Web Expression and Photoshop, all I needed to do was bring them into Visual Studio as Master Pages. This worked out great because the programmers would then come along and add the logic.

This turned out to be an excellent approach since it doesn’t require a style guide or volumes of documentation. It works because just one person was in charge of the UI design. The reality is most companies don’t hire someone specifically for a UI role, although more companies are starting to (compared to a few years ago).

Having worked as an IT project manager for a few years now, I have found there is another approach which works well for ensuring UI consistency. Personally, I don’t put much faith in writing UI guides and expecting programmers to follow them. There’s a few reasons for this: 1) programmers often aren’t good at UI design, 2) it’s a lot to remember, and 3) its counter-productive.

UI style guides slow down programmers because you are expecting them to be good at something which they aren’t geared for; they are good at coding, so let them code.

So what do you get when you let programmers do their thing and just code with no specific guidance on UI? Inconsistencies in the interface. This even happens when you provide programmers with mockups to work from. For example, your mockup might not contain the exact wording for an error message so a programmer, quite rightly, proactively puts one in (e.g. “Invalid input”).

What’s the solution? Easy, you have one person review the entire interface at milestones and log bugs in the issue tracker. These bugs would be marked as UI or low priority. If there’s a script error in the software, it’s obviously more important to fix that first before looking at a UI glitch.

The next question is, who should be doing the interface review? It should be one person only (for consistency sake), and that person should be whoever is the most talented with HCI/UI design.

My point is this, don’t make programmers try and be UI designers. When you log a UI bug, it’s there in the issue tracker, it won’t go away. The programmers will come and fix them when they are good and ready. UI bugs are generally easy to fix so they can act as a good break for a programmer. Imagine a coder has just spent 2 hours debugging a serious data corruption issue. Fixing a few UI bugs would most likely come as a welcome relief.

As far as language or wording in an application goes (e.g. error messages, online help, labels, etc), you wouldn’t necessarily need to log bugs for that. If you are using a string table, or some kind of configuration file like XML, then it’s easy for the UI person to tweak text by directly accessing the configuration store. For example, if you found "login error" in the configuration XML file, you could change that to "the username or password you entered is incorrect".



When things get written down they will be forgotten. This is especially the case when documents get long (e.g. 20+ pages). The problem becomes compounded when you realize that programmers could care less about consistent UI across all the screens of an entire application. Their task lists often say 'Code login screen', not 'Code login screen - and make it look pretty'.

As a side note, I should say I have written a massive UI style guide for an application I designed. It took me almost 2 weeks to write and personally I think it was unnecessary. It was basically a way for programmers to understand how to modify the interface once I finished my contract. As to whether they found the guide useful or not, I don’t know. I think design should be left to designers and coding should be left to programmers, it just makes good business sense.

Subscribe to RSS Feed.