Designing a good user interface (UI) is one of those skills that beginning programmers sometimes put off learning. As these beginners progress, they often continue to put it off, concentrating instead on “sexier” skills. Indeed, UI design is often thought of as someone else’s job—the realm of the academic or the QA guy, not worthy of the time and effort of a “real” programmer.
The problem is, UI design is a crucial skill to learn. Your software could be the most technically advanced, fastest, most feature-rich package the world has ever seen, but if it’s difficult to use, users will find an alternative or worse—continue to do things the way they always did before and experience all the same problems your software was supposed to fix. In this article, we’ll take a look at six fundamental things to keep in mind, regardless of your platform, when you build a user interface.
Remember the Alamo—er, the user!
Know your audience. Know as much as possible about who will be using your software. Unless you know otherwise, you should always assume that:
- Your user is not technical.
- Your user is not a process expert.
Ideally, your software should allow users to be as ignorant of their computers and of their business process as they want. Chances are, you will know more than the user about both topics. Don’t use acronyms or abbreviations that are not universally known—although there are fewer of these than you think. In addition, don’t use technical terms like record or Boolean search unless your user knows what these terms mean (most won’t). Technical people also have an easier time with hierarchical relationships like nested menus than do nontechnical people.
As a case in point, I once used the acronym TIN (Taxpayer Identification Number) as a universal term for a customer’s Social Security, Employer Identification, or Alien Identification numbers in a banking system I was developing. I even covered myself before adopting this acronym by conferring with several of our process experts, who were of the opinion that the meaning would be plain. Soon afterward, however, I began noticing that the first question asked by users upon seeing TIN used in the application was, “What’s TIN stand for?” Obviously, TIN was not as universally understood as I had believed.
Make frequently used features easily accessible. In most cases, it’s possible to make assumptions about which features a user will utilize the most. These features should be “top level” and easily located by the user. For instance, the user of a customer service application would likely need ready access to a customer search function. This function could even be the “main” screen, if it’s used frequently enough.
Don’t interrupt the user with trivial information or needless confirmations. All too often, applications interrupt the user with useless dialog boxes stating the obvious, complaining about things the user doesn’t understand or can’t help, and obtaining needless confirmations. This is a pet peeve of mine.
Here is a classic analogy: Imagine that you are at home watching TV when the channel breaks into static. Suddenly, a disembodied hand jumps out of the screen, flies across the room toward you, and shoves a card in your face that reads Warning! The frequency modulation signal strength has dropped below 15dB for this wavelength!, while a loud “Ping!” issues from your surround sound speakers. To your dismay, you discover that you can’t change the channel, turn off the TV, or even get off of your couch without taking this card from the hand and saying, “Thank you, Thing.”
You just entered the realm of the typical computer user by being:
- Interrupted from your primary task and probably startled.
- Provided with trivial information that you likely don’t understand.
- Alerted to a problem that you probably can’t fix.
- Forced to acknowledge the receipt of this information before you can do anything else!
Consistency is king
Have a consistent look and feel—use the standards for your platform. You wouldn’t know it by looking at some of Microsoft’s applications, but a standard covers almost everything about Windows applications, from menu labeling and placement right on down to button placement in dialog boxes. See Developing User Interfaces for Microsoft Windows by Everett McKay for a good reference on this standard. There is likely a similar standard available for whichever platform you develop.
Find the applicable standard and apply it to your software, regardless of whether you agree with what it says. The point here is that once a user learns something about one application, such as the Print command being on the File menu in Word, for example, he or she is going to try (and should be able) to apply that knowledge to any Windows application that has a print function. It doesn’t matter if you think Print works better on the Reports menu; users are going to expect it to be on File, and you will only confuse them if you put it somewhere else in your application.
Check your tab order. Then check it again! This step should be covered under “Have a consistent look and feel,” but it’s neglected enough that I thought it deserved special mention. If you really want to jack up the antipathy level between end users and IT, all you really have to do is make the user hit [Tab] six or seven times to advance one field down the screen. Want to make it worse? Consider it a low-priority problem and take a long time to fix it. You have to experience this yourself to appreciate how truly annoying a badly out-of-whack tab order can be for a user. There’s no excuse for it.
Be consistent in terminology, as well as look and feel. Developers seem to love to come up with colorful terms to apply to concepts or objects in their applications. This is fine, unless you later change your mind or another developer decides his or her term makes more sense than yours. Choose a term for something, get everyone else on the same page, and use it religiously to refer to that thing. Don’t use Product Number in one place, Product Id in another, and Item Code in a third. Are they the same thing? I don’t know, and your users won’t either.
Some good examples
If you’d like to learn more about UI design and the theory behind it, here are a few good books to read:
- About Face: The Essentials of User Interface Design by Alan Cooper
- The Design of Everyday Things by Don Norman
- The Inmates Are Running the Asylum by Alan Cooper
Some good bad examples
Most people learn best by example, so I thought I would leave you with some examples—bad ones. Isys Information Architects maintains a Web site called the Interface Hall of Shame, containing many examples of UI “design practices that are worthy of extinction.” It’s hard to read this site without chuckling at the dry wit of the reviewers. It also happens to be full of useful information and practical advice on how (and, obviously, how not) to build a user interface. I’d personally like to see the Hall of Shame become a required reference for developers.
Building a good user interface doesn’t have to be difficult, and it doesn’t really take any artistic ability. It does, however, require an understanding of your platform, your users, and your business process. Although this is a complex subject, keeping these simple tips in mind should keep you from going too far astray.
