What You See: What You Want?

User interfaces are in your face all day. What decisions go into -- or should go into -- their design?

Dinah McNutt

To read E-mail in one Windows application, you press Alt+M G. In another application, it's Alt+U R. And, in a third, Alt+B N. All pretty intuitive, right? Who thinks up these things, anyhow?

Graphical user interface (GUI) design is one of the most controversial aspects of software development. While few people might care how the application itself is programmed or what language is used, everyone has an opinion on the UI of an application. As a software developer trying to design a product, or as a customer trying to use what developers hand us, we all have been invo lved in interface design. And we have the mouse-scars to prove it.

Icons Rampant

The process of designing a UI varies depending on the size of the organization. At a small software company, it is all too common for the software engineers to design the interface themselves (usually on the fly), with predictable results. One example of this is a call-tracking system that had a call-logging option. When the user minimized the logging window, a crude bit map of a wooden log was displayed in the iconified window. One suspects an engineer quickly drew this icon to use during development, but it was never replaced with a production-quality icon in the actual product.

Other fingerprints that indicate engineers have had their fingers in the UI design are arcane technical terms used in the interface menus or commands. Often the display shows raw data instead of data in some format that might actually make sense to someone not already familiar with the information. For example, most Unix system administrators can easily recognize and parse the following data:

student:cOYWzzCDUrNP6:202:20:
Test Account:/users/student:
/bin/sh

This is a user entry from the system password file. But to the uninitiated, it makes more sense to display the information in the following way:

Login Name: student
Encoded Password:
cOYWzzCDUrNP6 
User ID: 202
Group ID: 20 
User Name: Test Account 
Home Directory: /users/student 
Interactive Shell: /bin/sh

Note that none of the information has been lost, but it is now displayed in a manner that both the seasoned system administrator and the novice user can understand.

Conversely, having someone who understands nothing about what the product does design the UI can be just as disastrous as the programmer-turned-interface-builder. Imagine a software package for accountants that does not use common accounting terms. No one with any accounting training would be able to use such a package. Novice u sers are probably going to have to learn the standard terminology anyway, so why invent terms no one knows just to make the product "friendlier"? Instead, the focus should be on the interaction of the user with the product.

Feast of the Unwarranted Assumptions

Never make assumptions about how your product will be used. People will always find new ways to use -- and misuse, and abuse -- your product. Search for beta testers who will stress your software in new ways and find out which parts of the interface work and which parts don't. These testers can also help you find new potential markets for your software. When they say, "What if when you clicked here it did this?" you may discover a whole new niche.

Another example: One product allowed users to schedule jobs off-hours. However, the designer built in assumptions about what a "normal" work schedule is and which hours are "off-hours." There was no technical reason for this limitation, so why impose one? Who needs a user interface to dictate their work schedule?

The Menu That Ate Cincinnati

Scalability is a prime area to focus on when evaluating an interface for usability. If a word processing package scrolls nicely for a 10-page document, how does it work for a 100-page, multidocument book? Vendors should design software that works well for both the low-end and the high-end user. A menu with 10 items is quite manageable, but what if there are 1000?

Try this, user interface designers: Multiply the number of items by 10 and then 100. Is the concept still usable? If not, see if you can come up with a different paradigm. For example, the interface of a checkbook program might work fine when the user is entering one or two transactions at a time. But some people, especially with joint accounts, write lots of checks. The software has to deal smoothly with a few checks or many checks each month. We would rather change our software than our way of life.

Understanding the Audience

Before the design process ever begins, identify an audience for the software. Keep in mind the level of expertise of the audience -- and especially their expectations of the product. If the audience is diverse, you may need to decide which subset of the audience you are going to target. Then you need to rethink your marketing strategy to see if the product is still viable. Most operating systems, of course, have a "one-size-fits-all" interface.

Many system-administration products offer only a GUI. This type of interface is great for novice administrators but tends to hamper more experienced administrators, who are used to command-line interfaces. In this particular market, it does not make sense to satisfy the requirements of only the senior system administrator, since one of the motivating factors for buying administration software at all is the ability to delegate tasks to more junior administrators. However, by ignoring the senior administrators and developing only the slick G UI for the novices, you may not be able to sell your product at all.

Wheels Reinvented Here

Many people come from backgrounds, such as Unix, where reinventing the wheel is frowned upon and reusing ideas is encouraged. But that philosophy should not apply to user interfaces. Even unimaginative implementors can appreciate good ideas. Only through innovative UIs can ubiquitous computing ever be achieved. What these interfaces will look like we perhaps cannot imagine, but we can imagine the useful things computers could do if they were more deeply integrated into our day-to-day activities.

Software and hardware design will both play factors in the role of UIs. The venerable keyboard-and-mouse combo is not always a practical way to use a computer. Both hardware technology and user demands for better interface designs should drive each other to improve the computing environment.

There was a time when it was unimaginable that anyone would need more than one window on a term inal. (When sharing a VAX 11/750 with 20 other people, this is probably true.) Now we may need several computers with many windows to do our jobs. In the same way, why should our computer interaction be limited by how fast we can type? Someday those limitations, and others we don't even recognize yet, will be removed. Now what will that interface look like?