Usability In Software
Written by: Doug Jenkinson
Article
One of the things that I as a software developer struggle with is the placement of user interface elements. UI design was something that is, unfortunately, not taught in a Computer Science degree. I have all too frequently come across software packages that you can tell the user interface was put together by the developer, and not someone with UI experience.
- Poor color or font choice. Inconsistant use of any color schemes or fonts.
- Poor menu layout, if any menus at all.
- Lack of shortcut keys.
Are all tell-tale signs of someone who just doesn't know better. I've been guilty of writing my fair share of terrible user interfaces.
The problem is, what makes a user interface good? Or effective for that matter. It really does not even depend on the medium.
The best rule, is not to listen to your users, but watch them. How they do a particular task. Where they get lost. What they are thinking when they can't find a particular feature.
For example, Windows users expect to find certain operations in the File menu such as New, Save, Save As, Open, and Close. And other set of operations in the Edit menu such as Cut, Copy, and Paste. And if your application is MDI, users expect to see a Window menu.
Perhaps the worst offense I see in interface design is the lack of help. Generally there is no Help menu nor a help file or online manual. And if there is a help file, generally the application does not link to it. This is just unacceptable when it comes to something being released to general public as a stable piece of software.
And the few times I've seen documentation, it's generally pathetic. My rule of thumb is never let the developer write the documentation that the end-user will read. This has worked out rather well, as it forces someone who did not write the program to not make assumptions about how the program will be used. One good methodology for writing documentation is write up some some basic help for the beta test, and watch the beta-testers and see where the flounder. That's where you need to improve your documentation. And if the user is lost before they even use the program, you need a better Getting Started section.
Perhaps the best rule to go with here is remember that not every user of your software will have your level of expertise with respect to computing. There will always be a novice trying to figure it out.
Revisions
- v1.0 (28 Dec 2005) - Article published.
