When most of us begin to design a program, and we are faced with that awesome blank screen, we know we must fill it with a useful and usable interface, so we depend on one of the oldest and most productive techniques in the annals of applied engineering: we copy from those who have gone before us. There is much good to be said about following firmly in the footsteps of those redoubtable designers who preceded us, and as a result we frequently see applications with interfaces that look remarkably like those of Microsoft Word, Lotus 1-2-3 and even Visual Basic. These programs make obvious role models because they are omnipresent, bigger-than-life and commercially successful, but would you model your life after Madonna? After all, she is also omnipresent, bigger-than-life and commercially successful. Madonna and Word may be what you aspire to be, but your behavior-and the behavior of your program-should better reflect the reality of its purpose.
A program may be bold or timid, bright or gray, but it should be so for a specific reason rather than for any personal preference of its designer or programmer. The behavior of your program should reflect how it is used, not some arbitrary standard. If your program is used like Excel, then modeling its behavior after Excel is suitable. If not, your program can end up looking like Henry Kissinger dancing the hula. I have divided desktop applications into four behavior categories that I call postures. A program's posture is its stance, the way it presents itself to the user. Programs have a dominant behavioral posture in the same way that people do: the teacher is imperious; the toll-taker is bored and invisible; the actor is shining and bigger than life; the butler is obsequious and servile. The posture of the program does much to determine how the user relates to it and it strongly influences the usability of the product.
I call the four principle postures sovereign, transient, daemonic and parasitic. Each is a description of a different set of behavioral attributes so naturally they also describe four different types of user interaction. The look and feel of your program is not an aesthetic choice as much as it is based on its behavior, and your program's posture is its behavioral foundation.
I call a program that is the only one on the screen, monopolizing the user's attention for long periods of time, a sovereign program. Sovereign applications travel in royal splendor surrounded by their numerous courtiers. Good design are word processors and spreadsheets. These programs deploy on your screen for long periods of time while you work with them to create the desired output.
Sovereign programs are used continuously for long stretches of time, dominating a process. PowerPoint, for example, is maximized while I create a presentation, from start to finish. Even if other programs are used for support tasks, PowerPoint remains in the prime role.
The implications of sovereign behavior are subtle, but quite obvious once you think about them. The most important implication is that the users of sovereign programs are experienced users. Sure, each user will spend some time as a new user, but only once and only for a short period of time relative to the amount of time they will eventually spend using the product. I'm not making light of the difficulty the new user has getting over the painful hump of first-learning, but, seen from the perspective of the entire relationship, the time the user spends getting acquainted with it is small. From the designer's point of view, this means that the program should be designed for optimal use by experienced users and not for first time users.
Sacrificing speed and power in favor of clumsier but easier-to-learn idioms is out of place here. Of course, if you can offer easier idioms without compromising the interaction for frequent users, that is always best. Because a sovereign program fully deploys on the screen, don't be afraid to go ahead and take as much real estate as possible. No other program will be competing with yours, so expect to take it all. Don't ever waste space, but don't be shy about taking what you need to do the job. If you need four toolbars to cover the bases, use four toolbars. In a different type of program, four toolbars may be overly complex, greedy and inappropriate, but the sovereign posture has a defensible claim on the pixels.
Because the program remains deployed for long periods of time, the user will be staring at it for hours. You should take real care to mute the color and texture of the visual presentation. Keep the color palette narrow and very conservative. That big red-striped gizmo may look really cool to newcomers, but it will seem garish after a couple of weeks of daily use. Tiny dots of color will have better effect in the long run than big splashes. You can also pack controls together more tightly than you would otherwise.
Sovereign applications are great platforms for creating a truly rich output environment. You can productively build extra little sources of output into the interface. The status bar at the bottom of the screen and other dusty corners of the program's visible extents can be filled with graphs, numbers, and many other visual indications of the program's status, the status of the data, the state of the system and hints for more productive user actions. The first-time user won't even notice such artifacts, let alone understand them, but after a couple of months of steady use, she will begin to see them and wonder about their meaning. At this point, the user will be willing to expend a little effort to learn, and if you provide an easy means for her to find out what the artifacts are, she will become not only a better user, but a more satisfied user, as her power over the program grows with her understanding. Adding such richness to the interface is like adding richness to a meat stock-the complex combinations of flavor enhances the entire meal.
Similarly, sovereign programs benefit from rich input. Each frequently used aspect of the program should be controllable in several ways. Direct manipulation, dialog boxes, buttcons, keyboard mnemonics and accelerators are all appropriate.
Go ahead and use all of the corners of the program's countenance for controls. In WinWord, Microsoft has put the frequently used functions on buttcons on the two main toolbars. They put the visually dislocating functions on small buttcons near the bottom of the screen. More experienced users, with more confidence in their understanding of the program will eventually notice the controls and experimentally press them. This is a very appropriate mapping of control placement to usage.
Many sovereign programs are also document-centric, and because of their frequent partnering it is easy to confuse the two, but they are not the same. The sovereignty of a program does not come from its document-centricity nor from the size of its document-it comes from the nature of the program's use. If the program manipulates a document but does some very simple, single function, it isn't a sovereign application and shouldn't exhibit sovereign behavior. Such single function applications have a posture of their own, which I call transient.
A transient posture program comes and goes, presenting a single, high-relief function with a tightly restricted set of accompanying controls. The program is called when needed, it appears and performs its job, then it quickly leaves, letting the user continue her more normal activity, usually a sovereign application.
The salient characteristic of transient programs is their temporary nature. Because they don't stay on the screen for extended periods of time, the user doesn't get the chance to get intimately familiar with them. Consequently, the program's user interface needs to be unsubtle, presenting its controls clearly and boldly. The interface must spell out what it does-this is not the place for artistic but ambiguous images on buttcons-it's the place for big buttons with precise legends spelled out in 12 point type.
Although a transient program can certainly operate all alone on your desktop, it will usually act in a supporting role to a sovereign application. The transient program borrows space at the expense of the prevailing sovereign. The transient program must necessarily respect the sovereign by not taking more space on screen than is absolutely necessary. Where the sovereign can dig a hole and pour a concrete foundation for itself, the transient program is just on a weekend campout. It cannot deploy graphically or temporally. It is the Roto-Rooter truck of the software world.
While a transient program must be conservative of the total amount of video real estate it consumes, the controls on it's surface can be larger than those on a sovereign application. Where such heavy-handed visual design on a sovereign program would pall within a few weeks, the transient program isn't on screen long enough for it to bother. On the contrary, the coarser graphics help the user to orient herself more quickly when the program pops up. The program's main window, too, shouldn't restrict itself to a dull corporate gray but rather should paint itself in brighter colors to help differentiate it from the hosting sovereign, more appropriately decked out in gray flannel.
Transient programs should have instructions built into their surface. The user may only see the program once a month, and they will forget the meaning of the choices presented to them. Instead of a button captioned "Print," it might be better to make the button large enough to caption it "Print Document Now." The meaning is clearer, the button is more reassuring. Likewise, nothing should be abbreviated on a transient program-everything should be spelled out to avoid confusion.
Transient programs are not the place for tiny scrollbars and fussy point-click-and-drag interfaces. Simple push buttons for simple functions are better. Providing a keyboard interface is only beneficial if they are religiously standard, like ENTER, ESCAPE, and the arrow keys. Keep controls off of the borders of the window. Don't use the armrests, sidewalls and overhead in transient programs. Instead, position the controls up close and personal in the main part of the window.
Keep in mind that any given transient program may be called upon to assist in the management of some aspect of a sovereign program. This means that the transient program, as it positions itself on top of the sovereign, may be obscuring the very information that it is chartered to work on. This implies that the transient program should be movable, which means it must have a caption bar. Making it reshapable is certainly also desirable, though not mandatory.
Having said that, it is vital to remember how important it is to keep the amount of management overhead as low as possible with transient programs. All the user wants to do is call the program up, request a function, and then end the program, so it is completely unreasonable to force the user to add non-productive window management tasks. The multiple document interface (MDI) is a strong example of non-productive window management. MDI can certainly be useful in some situations, but I cannot imagine a need for it in any transient program. For example, the Program Manager in Windows is transient program yet it insists on using MDI. The amount of time and frustration users spend wondering where their icons are, zooming, moving, reorganizing and managing their group windows is high in relation to the its benefit.
The most appropriate way to help the user with both transient and sovereign apps is, as usual, to give the program a memory. If the transient program remembers where it was last time it was used, chances are excellent that next time it will be a more appropriate configuration than any default setting might be. Whatever shape and position the user morphed the program into is the shape and position the program should reappear in when it is next summoned. Of course this holds true for logical settings, too.
No doubt you have already realized that almost all dialog boxes are really transient programs. You can see that all of the above guidelines for transient programs apply equally well to the design of dialog boxes.
I call programs that do not normally interact with the user daemonic programs. This is a program that serves quietly and invisibly in the background performing possibly vital tasks but without the need for human intervention. A printer driver is an excellent example.
As you might expect, any discussion of the user interface of daemonic programs will be necessarily short. Too frequently, though, programmers give daemonic programs full screen control panels better suited to sovereign programs. Designing your fax manager in the image of Excel is a fatal mistake. Also too frequently, daemonic programs are unreachable by the user, causing no end of frustration when adjustments need to be made.
A question that is generally taken for granted with programs of other postures becomes very significant regarding daemonic programs: if the program is normally invisible, how is the user interface summoned on those rare occasions when it is needed? One of the most frequently used methods is to represent the daemon with an on-screen program icon like Adobe Type Manager and After Dark screen savers do. Putting the icon so boldly in the user's face when it is almost never needed is a real affront, like pasting an advertisement on the dashboard of your car. If your daemon needs configuring less frequently than once a day, get it off of the main screen. A better approach is to create a "control panel" application and install it in the Windows control panel program, CONTROL.EXE. The user then has a consistent place to go for access to such process-centric applications. A simpler and equally effective solution is to create your own transient program that just runs as a launchable app to configure the daemon.
I call programs that blend the characteristics of sovereign and transient programs parasitic programs. The parasitic program is continuously present like a sovereign, but it performs only a supporting role and is small and superimposed on another application the way a transient is. The Windows Clock program is a good example of this. The Microsoft Office Manager is another parasitic program.
Parasitic programs are often silent reporters of ongoing processes. This may be a function they perform in addition to their main function of actually managing that process, but not necessarily. A parasite may, for example, monitor the amount of system resources either in use or available. The program constantly displays a small bar chart reflecting the current resource availability.
A process-reporting parasitic program must be simple and bold in reporting its information. It will ride on top of a sovereign app so it must be very respectful of the pre-eminence of that other program, being quick to move out of the way when needed.
Most programs you will design will fall into one of the four categories of program posture. Determining the posture will tell you much about the behavioral persona of the program which, in turn, dictates many of the important guidelines for the design process. As a user interface designer, you get a lot of bang for your buck merely by assuring that your program behaves in the posture most appropriate for its behavior. You won't be as dependent on copying bestsellers for interface design, and, eventually, your program might become as popular as Madonna.
Copyright © 1996, Alan Cooper
Last updated January 6, 1997
Talk back to us!