Introduction

Good user interfaces matter. In fact, they matter a great deal to the success of a program. While a program s design and technology affects its overall capability and performance, as far as the user is concerned, the user interface is the program. If the user interface isn t good, the program isn t good. Don t expect users to look behind a bad user interface to see what lies beneath. They won t.

How many Microsoft Windows software products on the market that have bad user interfaces have been commercial successes? I am familiar with only one: a popular high-end image-processing program (which shall remain anonymous). Ask anyone who uses this program how they like it and you will get the same response: love the program, hate the interface. But this program is fairly unusual. It provides complex image manipulation that is unavailable in other programs, and its awkward interface allows for batch processing that its users love. As a good rule of thumb, if there are several programs competing in a particular market segment, the winner will be the one with the best user interface.

Since the ultimate goal of software development is to make successful software products that make lots of money (this is certainly my goal), it would stand to reason that most software developers would be obsessed with obtaining as much knowledge about user interface design as possible. Surprisingly, this is not happening. I have several explanations for this:

• The software development process and those who manage it are usually focused mostly on schedules and less on software quality. For every manager clamoring for better user interfaces, there are probably a hundred who are clamoring to get the product out the door. For programmers, this means that success lies in understanding the tools and technologies that help deliver software quickly. Focusing on quality user interfaces tends to have the opposite effect.
• Programmers are often encouraged not to do user interfaces. Programmers are often told that they aren t capable of being good interface designers. In large software companies, interface designs are often done by specialists, usually user interface designers or graphic designers. Consequently, programmers do not have much motivation for improving their user interface design skills. This is in spite of the fact that the user interface constitutes a significant portion of most modern programs.
• User interface design is not part of most computer science curricula, nor is it a prominent topic in most programmers magazines. Some programmers magazines have never run an article about user interface design.
• Many discussions about user interface design are deemed by programmers to be irrelevant or too academic to be useful. Often they are right. Many user interface books are focused on the theoretical, not the practical. They are often jam-packed with useless mumbo jumbo.
• Programmers might simply be unaware of how poor their user interfaces are. They might be aware of problems in other programs user interfaces but not of problems in their own.

Since a significant portion of most modern software development is the user interface, a skilled programmer needs to have a solid understanding of user interface design. Very few programming jobs today require no user interface work at all. Even if a programmer works in an organization where specialists design the user interfaces, how can such a programmer do quality work without understanding what the interface is trying to accomplish? How can such a programmer identify problems, find bugs, or make appropriate changes? Understanding the fundamentals of Windows user interface design is essential for all programmers to create quality software.

The Audience

The target audience for this book is Windows programmers, specifically those programming Windows applications and utilities using MFC, the Windows API, or Microsoft Visual Basic. Many of the ideas I present also apply to other types of programming, such as programs designed for other operating systems, Web pages, and thin-client Windows DNA (Distributed interNet Applications architecture) programs, but I have not gone out of my way to address these specific subjects. Likewise, many of the ideas I present should be useful to software development team members other than programmers, such as managers, quality assurance testers, and technical writers, but again I haven t gone out of my way to address these specific audiences.

The Goals

To best present the subject of user interface design to Windows programmers, I have established several goals for myself:

• To focus on specific, practical, experience-based information. I ve tried to focus on ways to avoid mistakes that I have seen myself and other programmers make.
• To present the information in short, self-contained chapters.
• To avoid vague generalities, user interface clich s, academic theories, and other forms of mumbo jumbo.
• To not try to explain everything about user interface design, but to focus on the key concepts that every programmer should know. You are referred to other sources for additional information when appropriate.
• To try to avoid "exercises" for the reader (at least the target reader). I try to provide specific examples in the text whenever practical.

This book is essentially a summary of what I believe a programmer needs to understand to create great user interfaces. These ideas and techniques have helped me tremendously in my work, and my ultimate goal is to share them in the hope that they will help you achieve great results.

What Is a User Interface?

So just what is a user interface? Interestingly, none of my favorite user interface books bother to define it. I use a fairly broad notion of user interface. To me, a user interface is much more than just the windows and dialog boxes—it is the entire user experience of using a program. In addition to the standard user interface elements, I believe the user interface also includes details like how the program installs, how the program integrates with Windows, how fast the program loads, how responsive the program is, how helpful the error messages and documentation are, and how well the program prints. Furthermore, developing a user interface is very much a team effort. I find it important to understand the roles of the other team members and how to help them help you make the best user interfaces you can.

All these factors play a role in how the user perceives a program. Consider how users react to a slow program. They don t say, "Oh, looks like this program has an inefficient internal algorithm." Rather, they say, "This program has a pokey user interface." Whether the slowness is caused directly by the user interface or not, the user interface gets the blame. Consequently, this book covers a number of subjects that relate to this total user experience that are not covered in most user interface books.

More of a Clich than a Science

Alfred Hitchcock often said that one of his primary goals in filmmaking was to avoid the clich . While I m not exactly working at his level, I have made a sincere effort to avoid the standard user interface clich s and vague generalities. I have tried to avoid the common practice of describing user interface concepts in terms of analogies. There is no discussion of the KISS Principle. (And if you don t know what that is, I m not going to tell you.) I m not going to say that anything is more of an art than a science. Nor am I going to discuss being "user-friendly." I do include a "Keep It Simple" chapter, which is clearly titled after a vague generality, but the chapter mostly describes specific, practical techniques that a Windows programmer can use to simplify a user interface.

I ve made an effort to focus on user interface techniques that are practical. The user interface techniques that I discuss are either standard techniques, techniques that I use, techniques that I used to use, or techniques that I could easily use when necessary. I don t suggest doing things that I would never do myself. I ve also made an effort not to overstate the importance of things. Many things are important, but they are not all the most important. Many good user interface techniques can actually harm an interface when poorly done or overdone. I try to discuss both the right way and the wrong way and how to make sure you haven t overdone it.

Many of the user interface suggestions I make are easier to deal with early in the development process. Often this means that they are easy to implement in a new project but difficult to implement in an existing program. This is an unfortunate fact of life. If you re working on an existing program and you want to maintain a schedule, you simply cannot fix all user interface problems even if you want to. You have to choose your battles.

User interface development is a team effort, and it s important to have a realistic idea of when and how to involve the various members of the team in the process. I could say that you involve absolutely everybody in absolutely everything as early as possible, but this is clearly impractical. No one can work that way. So, for example, when I say you need to involve a technical writer early in the process, I try to give guidelines on just how early.

Finally, all rules have exceptions, so I try to explore exceptional cases whenever I can. To be practical, you can t just make blanket statements without exceptions.

User Interface Design Is No Longer a Mystery

I believe user interface design is no longer the mystery it once was. Today s typical Windows 98 user interface is far better than yesterday s typical Windows 3.1 interface. The behavior is much better and more powerful. The look is much cleaner and more professional. On the whole, Windows programs are more consistent because the Windows API and development tools like MFC have much higher-level user interface support built in. Today, you can create a good program framework in a matter of seconds by using the Microsoft Visual C++ AppWizard. An MFC program can provide advanced features like a print preview without any additional programming effort. These tools help make good user interfaces easier to implement, but they also raise the bar for the level of quality that users expect.

Most important, we now have a much better understanding of what a good Windows program looks like. The Windows 95 user interface really set the standard. We now understand the basic user interface components better: menus, toolbars, status bars, dialog boxes, property sheets, and message boxes. And we have a much better understanding of how user interface components fit together and their limitations. For example, we know that MDI isn t the right solution for all programs.

Since we are now creating user interfaces at a much higher level, your job should be easier. You can now create a good user interface by understanding the basic concepts of user interface design, understanding the Windows standards, understanding the basic user interface options, and making the right choices to help your users get their work done. There are many good Windows user interfaces that you can use as a model. What you don t have to do is design everything from scratch—there s little you have to invent. You don t need to have elaborate user testing facilities with two-way mirrors and videotaping. You don t need to perform elaborate user testing to determine the best way for a user to set the properties of an object. If you use the standard controls and follow the Windows standards for user interface design, most of this hard work has already been done for you. Many user interfaces have withstood the test of time. We already know they work.

One of my important goals in this book is to help you fully understand the Windows user interface components and how to make the right choices.

User Interfaces for Users

When you make user interface decisions, you need to remember that the ultimate goal is to help users get their work done. In fact, the best user interfaces go out of their way to help users get their work done. This is why they are called "user interfaces" and not "program interfaces."

While this observation might not seem especially profound, programmers often fail to make decisions based on what is best for the user. Rather, they often make user interface decisions based on what is best for themselves. Programmers choose to add inappropriate features because they are cool, because they are fun to program, or because they are easy to implement. Programmers rarely add inappropriate features because they are trying to help users get their work done.

To create good user interfaces, you have to become an advocate for users and put their goals ahead of your goals.

Programmers Can Create Good User Interfaces

In his otherwise excellent book About Face: The Essentials of User Interface Design, Alan Cooper flatly states that programmers are incapable of creating good user interfaces because they are too concerned about things like efficient algorithms. It is true that programmers have created some truly terrible user interfaces. However, I reject the notion that programmers are incapable of creating good interfaces because of some kind of innate inability. I m just as concerned about efficient algorithms as the next guy, but it hasn t impaired my ability to create usable software.

Rather, I believe the problem is much more fundamental. Many programmers are simply not trained in the fundamentals of good user interface design. User interface design is not a standard part of the typical computer science curriculum (at least it wasn t for me), and it s not a popular topic in programmers magazines. Programmers are fed a steady diet of "how-to" information that they need to get their work done, and interface design has not traditionally been presented in this manner. Without a solid understanding of the fundamentals, neither programmers nor anyone else can create good user interfaces. You cannot expect someone to have expertise in a skill they have never been trained in.

I believe it is important to understand that, like it or not, programmers are the ones doing most of the user interface work. Few organizations have specialized user interface designers. (For me, most of the projects I have worked on have been user interfaces with very little true core code. If you removed the user interface work from my projects, there wouldn t be much left.) Thus, there s a significant need for programmers to improve their user interface skills. And I believe programmers, with the right information, can create good user interfaces.

Controversial Ideas

Developing user interfaces is a highly personal subject. There is no one way to do it, nor is there one right way. That said, most of the advice I give in this book shouldn t be especially surprising since similar ideas have been described in other software development sources. However, in addition to believing that programmers can create good user interfaces, I have some other ideas that are not widely accepted, specifically:

• Users are not designers, so you cannot expect them to design your interfaces for you. Users can give you valuable information and they can test your program to tell you about its usability problems, but you will have to do the designing. Users can t turn a poorly designed program into a well-designed program. At best, they can turn a poorly designed program into a usable, poorly designed program. I believe the best way to design software is to work with users and other team members to create a program vision. You then use this vision as a decision-making framework.
• Prototyping can be very effective when done right, but it is easier to do wrong than most people think. Most prototyping efforts I ve seen have been a waste of time. A couple of them were catastrophic disasters. To prototype effectively, you need to have a specific problem that needs to be solved; you need clear, realistic goals; and you need to know how to do proper user testing to get good feedback. Otherwise, don t waste your time. Finally, there are many types of design problems that prototyping cannot find.
• Programmers are primarily responsible for quality. Programmers can and should test their own user interfaces. The biggest hurdle is testing the program as a user by performing real tasks that users perform. Performing the same tests you used during debugging won t do the job. I ve presented many practical techniques for testing user interfaces that any programmer should be able to use.
• User testing can be valuable, but you need to do programmer testing and QA testing first. User testing is more realistic than these other types of testing, but you can find many usability problems by using more cost-effective techniques.

Well, that s it. That is as controversial as I get. You might not agree with these ideas, but I ll do my best to talk you into them. These ideas reflect what I have experienced personally, and they have worked well for me. I have to call it as I see it.

A Word About Microsoft Software

I feel strongly about presenting practical, experience-based information in this book. Since it is important to understand why good programs are good and bad programs are bad, it is necessary to present real-world examples of both good and bad user interfaces. To make such examples practical and experience-based, I thought it would be a good idea to focus on products that I have extensive experience with and that most programmers are likely to have experience with as well. These would have to be programs I have used for years, not hours.

In my original proposal for this book, I chose several Microsoft products as examples of programs with good user interfaces and several non-Microsoft products as examples of programs with bad user interfaces. But when Microsoft Press agreed to publish this book, I immediately realized that I had a problem. It would be a little too cute for a book about user interface design from Microsoft Press to use Microsoft products for good examples and non-Microsoft products for bad examples. This would give my book a bias that I did not intentionally set out to give it.

My solution to this problem was to feature Microsoft products for all examples, both good and bad (with only a couple of exceptions). This approach has balance, and I m happy to report that Microsoft Press made no effort to censor any of my criticism of Microsoft products. I realize that there are many other companies out there creating excellent user interfaces, but unfortunately these are not products I use on a daily basis.