Design Specifications and Guidelines - Visual Design


Size, spacing, and placement of information are critical in creating a visually consistent and predictable environment. Visual structure is also important for communicating the purpose of the elements displayed in a window. In general, follow the layout conventions for how information is read. In Western countries, this means left-to-right, top-to-bottom, with the most important information located in the upper left corner.

The system defines the size and location of user interface elements in a window based on dialog units (DLUs), not pixels. A dialog unit is the device-independent measure to use for layout. One horizontal dialog unit is equal to one-fourth of the average character width for the current system font. One vertical dialog unit is equal to one-eighth of an average character height for the current system font. The default height for most single-line controls is 14 DLUs. Be careful if you use a pixel-based drawing program, because it may not provide an accurate representation when you translate your design into dialog units. If you do use a pixel-based drawing tool, you may want to take screen snapshots from a development tool that supports dialog units and use those images.

Cross ReferenceMore Information

Your application can retrieve the number of pixels per base unit for the current display using the GetDialogBaseUnits function. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site.


The following table lists the typical height and width of common dialog box controls.

Size of Common Dialog Box Controls
Control Height (DLUs) Width (DLUs)
Dialog boxes and property sheets 263 max. (for 640 x 480 screen resolution)
263 max. (for 640 x 480 screen resolution)
(For property sheets, heights include 25 DLUs for property sheet button bars.)
Command buttons 14 50
Check boxes 10 As wide as needed
Drop-down combo box and drop-down list 10 Size to match other drop-down combo boxes and text boxes
Option buttons 10 As wide as needed
Text boxes 14 Size to match other drop-down combo boxes and text boxes
Text labels 8 per line of text As wide as needed
Other screen text 8 per line of text As wide as needed

Cross ReferenceMore Information

To support localization, you should make controls wider than just enough to display the labels. For more information, see Chapter 15, "Special Design Considerations."

Toolbars and their buttons use pixels instead of dialog units for their measurement. The recommended sizes are shown in the following table.

Size of Toolbars and Toolbar Buttons
Control Height (pixels) Width (pixels)
Toolbars in small button mode 23 Width of toolbar area or window
Toolbars in large button mode 28 Width of toolbar area or window
Small toolbar buttons 21 Depends on content; 22 if the button includes only an image
Large toolbar buttons 26 Depends on content; 28 if the button includes only an image

When you cannot reasonably apply the size guidelines for secondary windows, try to maintain a width within a task. This can provide a smooth transition, making it easier for a user to focus on the task. Also, always check to make sure that the window will fit in the minimum screen resolution set by your application's users. Typically, this means using a 640 x 480 resolution screen to ensure that it fits completely. You must also take into account the possible space taken up by the task bar and other desktop toolbars.

Make buttons a consistent length for readability. However, if maintaining this consistency greatly expands the space required for a set of buttons, it may be reasonable to have one button larger than the rest.

Similarly, if you use tabs, try to maintain a consistent width for all tabs in the same window (and in the same dimension). However, if a particular tab's label makes this unworkable, size it larger and maintain a smaller, consistent size for the other tabs. If a tab's label contains variable text, you can size the tab to fit the label, up to some reasonable maximum, after which you truncate the text and add an ellipsis.

Try to maintain a consistent width between text boxes and the list boxes they appear near, using only one or two different widths per group or window. If you localize your application, you should extend text, option button labels, and check box labels to be as wide as the group or window, where possible. This will reduce the work necessary to localize your interface.

Spacing and Positioning

Maintain a consistent margin from the edge of the window — seven dialog units is recommended. Use spacing between groups within the window, as shown in Figure 14.27.

Recommended layout and spacing of controls and text

Figure 14.27 Recommended layout and spacing of controls and text (click to enlarge image)

The following table lists the typical items found in an interface and the recommended spacing between them.

Spacing Between Interface Items
Interface items Use this spacing (DLUs)
Dialog box margins 7 on all sides
Between paragraphs of text 7
Between text labels and their associated controls (for example, text boxes and list boxes) 3
Between related controls 4
Between unrelated controls 7
First control in a group box 11 down from the top of the group box; align vertically to the group box title
Between controls in a group box 4; align vertically to the group box title
Between horizontally or vertically arranged buttons 4; align vertically to the group box title
From the left edge of a group box 9; if the group box is left-aligned, controls are 16 from the left edge of the dialog box or property page
Last control in a group box 7 above the bottom of the group box
Smallest space between controls 2
Text label beside a button 3 down from the top of the button
Check box, list box, or option button beside a button 2 down from the top of the button

Toolbars and their buttons use pixels instead of DLUs. The following table provides spacing for toolbar buttons.

Spacing for toolbar buttons
Button Size Spacing
Small (16 x 16 pixel image) toolbar buttons 3 pixels between a button and its text label
2 pixels above the toolbar image
3 pixels below the toolbar image
Large (20 x 20 pixel image) toolbar buttons 3 pixels between a button and its text label
2 pixels above the toolbar image
2 pixels below the toolbar image

In general, for controls that do not contain their own labels, place the label to the left or above the related control. This makes it easier for users to associate the label with the corresponding control.

When a text box is the first item in the group box, use a smaller measurement so the visual spacing above and to the right looks equal. In cases where there are controls below a group box, align the controls to the edge of the group box above and use seven DLUs between the bottom edge of the group box and the control (or text), as shown in Figure 14.28.

Example of group box spacing

Figure 14.28 Example of group box spacing (click to enlarge image)

Position controls in a toolbar so that there is at least a window's border width from the edges of the toolbar, as shown below.

Minimum border width

(click to enlarge image)

Use at least 4 DLUs between controls, except for between a set of related toolbar buttons. There should be no space between adjacent toolbar buttons, such as a set of related option buttons.

For wizard design, Figure 14.29 shows suggested positioning and spacing.

Positioning and spacing in a wizard

Figure 14.29 Positioning and spacing in a wizard (click to enlarge image)


Group related components — you can use group box controls, separator lines, or spacing. Although you can also use color to visually group objects, it is not a common convention and could result in undesirable effects if the user changes color schemes.

A group box provides a strong visual element for related items. However, avoid using a group box when you have only one set of related items or where the group box may take too much space or add visual clutter rather than structure. Instead, consider using separators to group related items. Property sheets for files and folders are a good illustration of the use of separators rather than group boxes.

Stack the main command buttons in a secondary window in the upper right corner or in a row along the bottom, as shown in Figure 14.30. If there is a default button, it is typically the first button in the set. Place OK and Cancel buttons next to each other. If there is no OK button but there are command buttons that initiate action, place the Cancel button at the end of the buttons but before a Help button. If a particular command button applies only to a particular field, group it with that field.

Cross referenceMore Information

For more information about button placement in secondary windows, see Chapter 9, "Secondary Windows."

Layout of buttons

Figure 14.30 Layout of buttons (click to enlarge image)

Group controls so that their location helps users understand the associated context or scope. For tabbed pages, follow these guidelines:

  • When command buttons and other controls apply only to that page, place them within the border of the tabbed page.
  • When command buttons and other controls apply to the entire window, place them outside the tabbed page.


When information is positioned vertically, align fields by their left edges (in western countries). This usually makes it easier for the user to scan the information. Text labels are usually left-aligned and placed above or to the left of the areas to which they apply. When placing text labels to the left of text box controls, align the top of the text with text displayed in the text box.

In group boxes, controls should be left-aligned with the text label of the group. However, command buttons in the group should be right-aligned.

Align command buttons in most secondary windows at the top right or right-align them with the bottom. The exception is for message boxes, where command buttons should be centered. In toolbar arrangements, buttons and other controls are typically left- or top-aligned, depending on the layout of the area.

Required and Optional Input

For input form design, you may want to require certain input fields or controls and make others optional. To help users distinguish required input from optional input, provide some form of visual differentiation. The best way to do this is to separate the two sets of input into separate windows, panes, or groups and label the fields accordingly. However, this may not always work with the type of information you are presenting. The next best way is to label the individual fields with the words "required" or "optional" in parentheses. You can also use fonts, symbols, or graphics; however, such conventions require the user to learn the convention in order to use the application effectively. In scenarios where you cannot rely on training the user, use a more obvious form of identification. Do not use color unless you are using some other form of feedback as well. Color may attract the user's attention, but the perception of color can vary. Therefore, do not rely on it as the only means of identification.

Preview and Sample Boxes

In some situations, you may want to provide an area for a visual example of changes a user is making to an item, as shown in Figure 14.31.

Preview or sample box

Figure 14.31 Preview or sample box (click to enlarge image)

A sample is a representation of what might show up on screen, but it does not show the actual data that the user is working on. In contrast, a preview shows the user's actual data.

Include text, graphics, or both in your preview or sample boxes. The preview can be illustrative and interactive. If the preview is interactive, include instructions or some visual cue to let the user know that it is interactive.

Include a label for your preview or sample box, and keep the wording for the label brief. A one- or two-word label (often Preview or Sample) is usually sufficient unless the user needs to interact with the preview to update it. Use sentence-style capitalization for the label, but do not include ending punctuation unless the user can interact with the preview, in which case end the label with a colon.