Sample User Interface Guidelines

Extracted from Chapter 4 of Mckay, Everett N. (1999). Developing User Interfaces for Microsoft Windows. Redmond, Washington: Microsoft Press.

The following is a list of sample user interface guidelines that you might want to consider using. The items marked with an asterisk are considered rules and should be followed in most circumstances. The remaining items are guidelines. My personal criteria for rules is that either the rule must be followed to satisfy the standards, or the rule is objective (as opposed to subjective) and there is rarely a good justification for not complying. However, for me, there is no such thing as an absolute rule in user interface design. If I have an excellent justification for breaking a rule, it’s broken. I rarely do.

Some of the guidelines give what might seem to be arbitrary sizes and spacing. However, the sizes and spacing given agree with the standards and are known to work well with the English language. If you have a good reason for using other sizes and spacing, you should do so. Just make sure to use whatever sizes and spacing you choose consistently throughout the program.

Lastly, note that in Visual C++ shortcuts are called “accelerators” and access keys are called “mnemonics.” Normally, shortcuts are obtained with the Ctrl key, and access keys use the Alt key and are indicated by an underlined letter. The terms used here are consistent with Designing for the User Experience and the Microsoft Manual of Style for Technical Publications, Second Edition.

General appearance

  • Use consistencyA consistent appearance will make the user interface easier to understand and use. The user interface elements should look as if they belong together.
  • Use arrangement and flowIn Western cultures, people read from left to right and from top to bottom, so place the more important information on top and to the left. The upper left corner receives the most attention.
  • Use alignmentIn general, use left alignment to make user interface elements easier to scan. Use decimal alignment or right alignment for numeric text. Avoid right alignment and center alignment for non-numeric text. You don’t have to center everything or make everything symmetrical. Prefer having white space on the right side and bottom instead.
  • Use groupingGroup related user interface elements to show relationships. Display related information together. Place controls near the objects acted upon. Use white space, group boxes, lines and labels, or other separators to group related user interface elements.
  • Use emphasisTry to draw attention to the user interface elements that need to be seen first, using focus, location, grouping, hierarchy, enabling/disabling, size, color, or font attributes. Try to visually indicate what the user should do next.
  • Use visual cluesTry to use like sizing and spacing to indicate that user interface elements are similar and different sizing and spacing to indicate that user interface elements are different.
  • Use white spaceUse white space to create “breathing room” that makes window layout easier to understand and more comfortable to view. The spacing should appear more or less balanced and even, with no awkward gaps. However, avoid having too much white space. If possible, try to make the window smaller instead.
  • Watch for vanityDon’t plaster company or product names and logos all over the place. While large company or product names and logos are perfectly acceptable in splash screens or about boxes, the available space in other windows should be used for something else. If there is nothing else, try to make the window smaller instead.
  • Watch sizingMake user interface elements resolution independent. Use either system metrics (using the GetSystemMetrics API function) or text metrics (using the GetTextMetrics or GetTextExtentPoint32 API functions) to determine the size of user interface elements. Any object that displays text, such as dialog boxes or printed text documents, should use text metrics. Avoid using pixels for sizing.
  • Consider using resource templates or predefined layout gridsResource templates or predefined layout grids will help you obtain consistency between different windows.

Note how the second dialog box below, unlike the first, has a compact, left-to-right, top-to-bottom flow; left-aligned labels that are easy to scan; and edit boxes aligned and sized to give them an organized, balanced look.

Acceptable

Better

Windows visual affordance

Affordance relates to the ability of a user to determine how to use an object just by looking at its visual clues. Maintain the following visual affordances used in Windows:

  • Raised items can be clicked.
  • Items that become highlighted when the mouse cursor passes over them can be clicked.
  • Recessed items cannot be clicked.
  • Items with a white background and a flashing vertical bar can be edited.
  • Items with a gray background cannot be edited.
  • Gray items are disabled.
  • Raised lines can be dragged.

Windows visual affordances

Interaction

  • Try to provide keyboard access to all featuresIdeally, all functions, except graphical functions like drawing, should be accessible with the keyboard alone.
  • Try to provide mouse access to all featuresIdeally, all functions, except text entry, should be accessible with the mouse alone.
  • Make sure that activities that have significant consequences require explicit selection from the userThe user needs to be fully aware that he is about to do something dangerous or destructive.
  • * Give feedback for all time-consuming operationsMake sure there is a wait cursor, progress meter, or some other visual feedback during lengthy operations. The user should be able to cancel lengthy operations. Label the button Cancel if canceling undoes the operation, otherwise label the button Stop.
  • * Visually indicate modesGive the user visual feedback to indicate when he has entered a mode, typically by changing the cursor or the title bar text.
  • * Make sure single-clicking and double-clicking are consistentUse single-clicking for selection for nonbuttons. Use double-clicking for selection plus performing the default action. In other words, double-clicking (in a list box, combo box, or any other control that takes a double click) should have the same effect as selecting an item in the control and pressing the Enter key.
  • * Use the right mouse button only for context menusMake sure the right mouse button is used for context menus and not for any other purpose.
  • Do not use the middle mouse buttonIf the user has a mouse with a middle mouse button, let the user assign the behavior using the Mouse utility in the Control Panel.
  • Assign shortcut keys consistentlyUse function keys and Ctrl key combinations for shortcuts. Don’t use Alt key combinations except by convention, since they are used for access keys. Never combine Alt and Ctrl keys, since such combinations make shortcuts cumbersome and less accessible.
  • Always make shortcut keys redundantNever make a shortcut key the only way to access a command. Give the user a more visible alternative.
  • Avoid horizontal scroll barsUnlike vertical scrolling, horizontal scrolling is undesirable because it makes it difficult to read an item. As an alternative, try to use a vertical scroll bar, make the window wider, shorten the text, or wrap the text instead. Of course, use horizontal scroll bars if you really must.

Programs

  • Only main program windows have title bar icons, menu bars, toolbars, and status barsSecondary windows must not appear on the taskbar, since clicking on a primary window taskbar button also activates any secondary windows. Secondary windows should not have the complexity to warrant a menu bar, toolbar, or status bar. Title bar icons are used as a visual distinction between primary windows and secondary windows. Also, never use the default Windows icon (the flying window icon) as a window icon.
  • Make the default configuration very simpleLet users grow into a program at their own pace.
  • Applications should use either a multiple-document interface (MDI) or a single-document interface (SDI)These program interfaces match the usage pattern of applications.
  • Applications should be maximized by defaultThe user is usually more productive when the full screen is dedicated to an application.
  • Utilities should use either an SDI or a dialog box interfaceThese program interfaces match the usage pattern of utilities. Using an MDI interface is not recommended for utilities because it requires too much effort to manage all the windows.
  • Utilities should work in a small screen spaceUtilities are often used in conjunction with another program, so they need to run in a small screen space. Utilities should have a flexible window layout so that they can accommodate a wide variety of sizes. Utilities rarely run maximized.
  • SDI programs that use actual documents must support running multiple instancesRunning multiple instances will allow the user to work with several documents at a time.
  • Use an Exit command to quit a programUse Exit to quit a program, Close to remove primary windows and modeless dialog boxes, and Cancel to remove modal dialog boxes. Use Close instead of Exit for primary windows when closing the primary window doesn’t imply terminating the process. For example, closing a printer status window doesn’t cancel the outstanding print jobs.

Terminology

  • Use the same term to describe the same thingUsing different terms for items that have only subtle differences will confuse the user.

Defaults

  • Save and restore user selectionsA program should restore itself to the state it was in when last quit. MDI programs should restore the size and location of document windows. Dialog boxes should generally use the last input values for defaults.
  • Provide appropriate defaultsHelp users get their work done by eliminating unnecessary effort through appropriate defaults. Give the default value that is most likely to be right, given how the setting is actually used. Often the best default is the last setting that the user input.
  • * Consider safety when selecting default valuesIrreversible or destructive actions should never be the default. Never use a default value that would surprise the user.

Dialog boxes

  • Dialog boxes should display correctly in all video modesWhen displayed in VGA mode (640 x 480), a dialog box should be no larger than 640 x 460 (saving 20 pixels for the taskbar). This will guarantee that the dialog box can be displayed in all video modes.
  • Make modal dialog boxes modalMake sure that all modal dialog boxes that have parent windows supply the correct parent window handle instead of a NULL handle. (Note that the correct parent handle is automatically supplied when using MFC.) If the parent window handle isn’t supplied, the parent window is still active, so the dialog box really isn’t modal.
  • Never use scrollable dialog boxesThat is, never use dialog boxes that require the use of a scroll bar to be viewed completely. Such dialog boxes are difficult to use and completely unnecessary. Redesign the dialog box instead.
  • Never use menu bars in dialog boxes used as secondary windowsSuch dialog boxes require too much effort to use. Note that menu bars are acceptable in dialog boxes used as primary windows (such as the Find utility). Also note that context menus and menu buttons are acceptable in all dialog boxes:

Secondary windows should not have menu bars but can have menu buttons

  • Never use title bar icons in dialog boxes used as secondary windowsTitle bar icons are used as a visual distinction between primary windows and secondary windows.
  • Never display dialog boxes used as secondary windows on the taskbarNote that clicking on a primary window taskbar button also activates any secondary windows.
  • Between similar dialog boxes, use control locations to emphasize similarityIf the same control with the same meaning appears in several similar dialog boxes, it should appear in the same location. On the other hand, avoid placing different controls that could be confused in the same location.
  • Prefer dockable toolbars to modeless dialog boxesDockable toolbars are functionally equivalent to modeless dialog boxes but allow for more flexible placement.
  • Set input focus strategicallySet the initial input focus on the control that is most likely to be used first.
  • Don’t put ellipses in dialog box title textFor example, a dialog box that is displayed as the result of choosing the Print Options… command should have the title Print Options. An exception is to indicate that a command is in progress, such as with “Connecting To The Internet…”
  • Assign access keys to all controls that can handle access keysAccess keys help users keep their hands on the keyboard and make a program more accessible. You can assign access keys to controls such as command buttons, radio buttons, and check boxes directly in their captions. You can assign access keys to controls such as edit boxes, list boxes, and combo boxes by supplying a static text label or group box with an access key that precedes the control in tab order. Don’t assign an access key to a group box in other circumstances—this is confusing. An OK button doesn’t have an access key, since it is selected with the Enter key when it is the default button. A Cancel button doesn’t have an access key, since the Esc key is used to dismiss a modal dialog box. If possible, avoid assigning an access key to a lowercase g, j,p, q, or y, or to a character immediately preceding or following one of these characters. The underline doesn’t look right against the character’s descender. Of course, the access keys must be unique.
  • Avoid using bold textUse bold text sparingly. Bold text was used in Windows 3.1 dialog boxes to draw disabled text on old video hardware (that is, dithered gray). Since modern video hardware can draw gray text without dithering, Windows now uses normal text in dialog boxes for a much cleaner look. Use bold text only for emphasis. Most dialog boxes should not use any bold text.
  • Provide context-sensitive helpFor more complicated dialog boxes, supply context-sensitive help for the entire dialog box (accessed with a help button or the F1 key), control-specific help for individual controls (accessed with the What’s This? button or the Shift+F1 key), or both.

Dialog box main command buttons

  • Separate main command buttons from the main body of a dialog boxMain command buttons are command buttons such as OK, Cancel, Close, Help, Stop, Hide, and other related buttons. This separation makes the main command buttons easier to find and identify.
  • Choose the dialog box orientation carefullyIn Western cultures, people read from left to right and from top to bottom, so main command buttons are easier to find if they are across the bottom or on the right. You should chose the orientation that makes the aspect ratio of the dialog box more similar to the aspect ratio of the screen, which is typically 3 units high to 4 units wide. This makes the dialog box appearance more comfortable and easier to position on the screen. Put the buttons across the bottom if they have different sizes. When in doubt, put the buttons across the bottom, since this orientation is more common and easier to read.
  • Right-align main command buttons placed across the bottomRight-aligned main command buttons follow the left-to-right flow. You might want to make an exception by centering the main command button when there is only one.
  • Avoid multiple rows or columns of main command buttonsMultiple rows or columns of main command buttons will overwhelm the user. If you have many main command buttons, note that you can usually place more buttons in a single column on the right than in a single row across the bottom. Alternatively, consider using a command menu instead. If you must have many buttons, note that multiple rows are preferred to multiple columns.
  • For modal dialog boxes, always provide OK and Cancel buttonsTo use a dialog box, the user needs to be able to easily identify how to move forward (with the OK button) and backward (with the Cancel button). You can replace OK with a more specific command, but never replace Cancel in a modal dialog box, except with Stop to indicate that the effect of an operation in progress cannot be cancelled.
  • For modeless dialog boxes or dialog boxes used as primary windows, provide a Close button but do not provide OK and Cancel buttonsUsing OK and Cancel for a modeless dialog box or primary window makes the dialog box appear to be a modal dialog box. Furthermore, OK and Cancel are not meaningful when used in a modeless context. Use Close instead to eliminate any confusion.
  • Always put the OK button first, Cancel second, Help lastOK or its equivalent should always be the first main command button. Cancel should be to the right of or below OK. Place the OK and Cancel buttons next to each other. The Help button should be the last button. If there is no OK button, place the Cancel button just before the Help button. This makes the main command buttons easier to find and identify.
  • Label the OK and Cancel buttons correctlyThe OK button should be labeled OK, not Ok or OK. The Cancel button should be labeled Cancel, not Cancel or CANCEL.
  • Make sure the Cancel button really cancelsWhen cancelled, the program state should be exactly the same as it was before the modal dialog box was displayed. If not, the Cancel button should be replaced with a Stop button. The Cancel button in the body of a modal dialog box should have the same effect as the Close button on the title bar. Property sheets are an exception, since the Cancel button doesn’t cancel or undo changes that have already been applied.

Property sheets and property pages