I’ve been putting this usability audit discussion off for a while, because honestly, this is tedious to think about, let alone to talk about. Don’t give me that look, because you’ve put off researching this too, haven’t you? Yeah, I thought as much.
Why is that, exactly? Well, it’s because you and I both know in our heart of hearts that this is going to be one of those things where we have to think about psychology, sociology and why to disregard half of it and not the other, and of course, we have to address the GUI.
So, because these are aspects of a usability audit, we have to also spend time remembering that the GUI and aesthetics are only half the battle, while at the same time obsessing over them in the conversation.
But, this is important, so let’s you and I go ahead and talk about this. The sooner it’s begun, the sooner it’s done. And, the sooner your usability is as good as it can be.
#1 – Rate of Immediate Accomplishment
Ok, you may have guessed that this is going to be more about what to test for in your audits. See, all an audit is, is a usability test performed at any time even after release. Sometimes it’s before a new version is begun to be worked on, and the existing one is reexamined to see how the usability is, and make changes that address them.
The first one of these is, of course, rate of immediate accomplishment. Basically, this is how many users, if put in front of the software having never seen it before, can at least do the simplest mostly useful thing in less than half an hour of puttering around directionlessly.
#2 – Examining Requested Features
One of the things that you need to keep an eye on is the requested features that already exist, but that users have not discovered. This indicates that your flow navigation, layout or something isn’t helping them find them in a natural way.
Microsoft encountered this with their Office suite, and it resulted in their introduction of the ribbon interface. Between you and me, though, that was so not an improvement.
#3 – Examining Bug Reports
Yes I know a lot of this is more for the coders than the usability people, so don’t really worry about the bug reports that are error numbers or the like. Worry about the bug reports users hand in that show the UI doing something absurd.
Pay attention to how much of that is a flaw in the GUI, and how much of that is just that they, in confusion, did stuff in an order they shouldn’t have. This will tell you first, to put in prevention for if they do things like that in the future, and to address aspects that are causing them to be so confused in the first place.
Conclusion:
These are the biggest things to remember for a usability audit, because they tell you the most, if sometimes indirectly, about what is or isn’t wrong with your current design. So, maybe this wasn’t quite as bad as you or I thought it’d be.
