User Interface Text

User interface text in your application is text that appears on screen in both primary windows and secondary windows, such as dialog boxes, property sheets, wizards, message boxes, or controls. Clear, consistent, informative, and well-written text in these elements is essential for a usable interface. This section provides guidelines for writing and displaying interface text.


The variation in size and weight of the fonts helps to discriminate more or less important text and perceives the order in which it should be read.

At conventional resolutions of computer displays, fonts are generally less legible than on a printed page. Avoid italic and serif fonts, as these are often hard to read, especially at low resolutions.

Limit the number of fonts and styles. Using too many fonts usually results in visual clutter.

Use bold fonts sparingly. While bold text attracts attention, overusing it can distract the user and make it difficult to focus on what is important. Too much bold text also lessens its impact. Limit its use to titles, headings, and key items that should have the user’s attention.

Similarly, limit your use of italic text. Used in isolation, italics may attract attention, but in general, it can decrease the emphasis on the information and make the text less readable.

Wherever possible, use the standard system font for common interface elements, such as your application window content, make the fonts adjustable so that users can change them to suit their preferences.

Font and Size

The default system font is a key element in the presentation of visual information. The default font used for interface elements in the U.S. releases of Windows 98 and Windows NT 4.0 is MS® Sans Serif 8 point. For applications that will run on Windows 2000, it is recommended you use Tahoma 8 point. For compatibility reasons, this font is not set by default in Windows 2000; you must explicitly select it. The Tahoma 8 point font offers improved readability and globalization support; in Windows 2000, it is the default font used by most of the interface elements in the operating system.

The menu bar titles, menu items, control labels, and other interface text in each operating system use one of these two fonts. The title bar text also uses the bold setting for these fonts. However, because the user can change the system font, make sure you check this setting and adjust the presentation of your interface appropriately rather than assume a fixed size for fonts and other visual elements. Also, adjust the presentation when the system notifies your application that these settings have changed.

The system provides settings for the font and size of many system components including title bar height, menu bar height, border width, title bar button height, icon title text, and scroll bar height and width. When you design your window layouts, take these settings into account so that your interface will scale appropriately. In addition, use the standard system settings to determine the size of your custom interface elements.

The Basics of Writing Interface Text

The wording you use in your interface is a primary form of communication with the user. This section provides basic guidelines for writing effective user interface text.


Avoid using abbreviations unless the abbreviated form is as familiar to your users as the full word or phrase. If you use an abbreviation, follow these guidelines:

  • Always use the spelled-out term the first time it appears in any part of the user interface and include the abbreviation in parentheses. Use the abbreviation alone in subsequent references; within the same screen, on subsequent pages of a wizard, or in nested dialog boxes that the user can get to only after seeing the screen, page, or dialog box where the term is spelled out.
  • Avoid using abbreviations in headings.
  • Do not abbreviate product or feature names without approval from your legal and marketing representatives.
Access Keys

Always define an access key for the label of any control or menu item. The only exceptions are the OK and Cancel buttons because the ENTER and ESC keys typically serve as the access keys to these buttons. Also, avoid having the same access key used by more than one control in a single context or more than one item on the same menu.


You can use an acronym for a term that is not trademarked or for a well-known industry standard. At its first mention, if a term is an industry standard acronym — for example, HTTP — there is no need to spell it out. But for the first mention of most other acronyms, spell out the full term with the acronym in parentheses directly following — for example, Internet Control Message Protocol (ICMP). You can then use just the acronym in subsequent references on the same screen, on subsequent pages of a wizard, or in nested dialog boxes that the user can get to only after seeing the screen, page, or dialog box where the term is spelled out.

If you use an acronym in a heading, do not spell out its meaning. Instead, use and spell out the full term in the first sentence after the heading, if it has not been spelled out previously. You may be able to link to a separate glossary entry or spell out the term in the status bar instead of using the spelled-out term in the text.

Check with your marketing and legal representatives before you create acronyms specific to your product. Also, search your intranet and the Internet for the acronym to make sure it is not already used for another purpose in your customers’ industry.


Correct capitalization helps readers identify important words and breaks in text. Two styles of capitalization are used for interface text: book title capitalization (also referred to as title caps) and sentence-style capitalization (also known as sentence caps).

For book title capitalization, capitalize the first letter of the first and last words. Also capitalize all words in between, with the exception of articles (such as a, an, and the); coordinate conjunctions (such as and, but, for, not, or, so, and yet); and prepositions of four letters or fewer (such as at, for, with, and into). For example:

  • Insert Object
  • Paste Link
  • Save As
  • Go To
  • Always on Top
  • By Name

Use book title capitalization for the following elements:

  • Column headings
  • Command button labels
  • Icon labels
  • Menu names and menu commands
  • Palette titles
  • Tab titles
  • Title bar text
  • Toolbars and toolbar button labels
  • ToolTips
  • Web page titles and Web navigational elements (unless otherwise defined by your page design)

For sentence-style capitalization, capitalize only the first letter of the initial word and other words normally capitalized in sentences, such as proper nouns. For example:

  • Working folder
  • Print to
  • Use Postscript driver

Use sentence-style capitalization for the following elements:

  • Alternate text (alt text) used to describe images on Web pages
  • Check box labels
  • File names
  • Group box labels
  • List box entries
  • Messages
  • Option (radio) button labels
  • Status bar text
  • Text box labels

If the user supplies a name for an object, always display the name as the user specifies it, regardless of case, wherever the name appears, including in the title bar for a window.


Contractions lend an often-desirable informal tone to the user interface and also save space. However, never form a contraction from a subject and its verb:

Windows 2000 Professional is the latest version of the operating system. Windows 2000 Professional’s the latest version of the operating system.
The company will develop a new product line. The company’ll develop a new product line.

If a command requires additional information to complete its intended action, and you use a dialog box to supply that information, follow the command with an ellipsis (…). The ellipsis provides a visual cue that the command requires additional information.

Here are examples of when to use an ellipsis as part of a command’s text:

  • Include an ellipsis for a Save As command because the command is not complete until the user supplies or confirms a file name. Similar common examples include Browse, Open, Find, Add, and Customize.
  • Include an ellipsis for a Print command when it opens the Print dialog box, where the user must confirm the print settings before printing.

However, not every command that results in the display of a window should include an ellipsis. Do not include an ellipsis for commands that simply display a window or view or change the existing view within a window. Similarly, do not use ellipses for commands that display a collection of objects or options, unless the intended action requires that the user select or confirm the selection of one or more elements of the collection. Also, do not include an ellipsis for commands that may result in a confirming message box.

Here are examples of when not to use an ellipsis as part of the command’s text:

  • Do not include ellipses for commands such as Cut, Copy, Paste, Undo, or Refresh. These commands perform direct actions; the user is not required to supply any information.
  • Do not include ellipses for viewing commands such as Details, Outline, Print Preview, and Show Toolbar. Even if these views offer options, the intended action is complete when the view changes.
  • Do not include ellipses for Help commands such as Index or Contents. The user can use these commands to select a Help topic, but the intended action is to display the HTML Help Viewer using a particular view.
  • Do not include an ellipsis for an About command. This command typically displays copyright and version information about an application. Therefore, its intended action is complete when the window containing this information is displayed.
  • Do not include an ellipsis for a Properties command. The user does not have to indicate what object to show properties for or what property to show. Even though the user can use this command to change options, the command’s intended primary action is to display those options. Similar common examples include Options, Settings, Advanced, and Preferences.
  • Do not include ellipses for commands such as Macros, Help Topics, and Fonts. The dialog boxes that display these collections may support additional actions, but the primary intended action of the command is to display the collection.
  • Do not include an ellipsis for a Toolbox command or similar commands that display a palette of tools or options. The command’s intended action to display the palette window is complete when the window appears.
  • Do not include an ellipsis for a Close command, even though it may result in the display of a message box that prompts the user whether to save changes.

Keep in mind that the decision about whether or not to use an ellipsis can depend on the context of the command. You must take into consideration the command’s intended action, the wording of the command, or, for menu items, the wording of the command’s parent menu item. For example, a Print command that prints a document without displaying the Print dialog box should not include an ellipsis. A Font command on a Format menu should include an ellipsis because its intended action is to format the current selection with specific font settings, and the user must use the dialog box to define those settings.

If the object of the intended action is already defined, the Open command typically does not take an ellipsis. Contrast the command for a selected file icon in a standard folder window with the same command for the File menu in Notepad. In the first case, the user’s selection before choosing the command supplies the necessary parameter of what to open, so no ellipsis is used. However, in the second case, the user must type or select the file to open, so an ellipsis should appear with the command. As a general rule, include an ellipsis if a command requires the user to supply “what,” “where,” or “how" information for the command to complete its intended action.

You can also use ellipses in other forms of interface text. For example, you can use ellipses to abbreviate path names or other information that may extend beyond the size of the field. Do not use an ellipsis in the title bar text of a window when the command that opened it included an ellipsis. Use an ellipsis in the title bar text only when you need to truncate the text. Whenever you use an ellipsis to abbreviate interface text, try to display as much information as possible to still enable the user to identify the item. Also, use other techniques such as ToolTips to display the full text.

Introductory or Instructional Text

Introductory or instructional text helps reduce or eliminate the text for online Help. Use introductory or instructional text in dialog boxes, Web views, and wizard pages to provide additional information about the task that the user wants to accomplish. Follow these guidelines for writing useful introductory or instructional text:

  • Write text that is brief and to the point.
  • Complement and expand on informative control labels but don’t duplicate them.
  • Position the text so that any relationship with a particular control is clear.
  • Use sentence-style capitalization and ending punctuation.

Align numbers at the decimal point (or imaginary decimal point). Right-align a block or column of whole numbers or of whole numbers and text.


Follow normal rules of punctuation for your interface text. End a question with a question mark, but avoid phrasing control labels as questions. Separate sentences with one blank space, not two.

In a bulleted or numbered list, introduce the list with a sentence or sentence fragment that ends with a colon. Begin each entry in the list with a capital letter. End each entry with ending punctuation if all entries are complete sentences or complete the introductory phrase. Entries in a list should be parallel (have the same grammatical structure).

Writing Style

Before you begin writing, research your audience to determine the most useful writing style. For example, text in a program intended for novice users should be different from text in a program designed for network administrators. Style, which includes brevity, language, parallel construction, sentence structure, and voice, affects the readability and comprehensibility of text.


Keep text in the user interface as brief as possible. Usability studies indicate that users are more likely to read short blocks of text than long ones. Review your work to eliminate wordiness, and keep user interface text short without sacrificing clarity and ease of localization:

  • Focus on what the user must know. Do not include extraneous or optional information.
  • Use simple and direct words and phrases, especially for the most prominent and often-used interface elements. Introduce more specific and advanced technical terms in dialog boxes.
  • Use specific verbs. Watch for helping verbs, such as “make” and “be”. These terms may indicate that a more specific verb is available. For example, instead of “…to make the window appear,” say “…to display the window”.
  • Try to limit instructions for correcting an error to three simple steps.
  • Replace several words with one whenever you can. Some examples are shown in the following table.
    Table 1 Sample Simplified Phrases
    By means of By
    For the purposes of For
    In many cases Often
    In the event that If
    Is able to Can
    On the basis of Based on
    The way in which The way how
    In order to To
    Prior to Before
    Is required to Must
  • Eliminate words that do not add value. For example:
    • Actually
    • Basically
    • More or less
    • To a certain degree
    • Various

Clear and consistent use of language can improve usability and ease localization. Use good standard grammar. Grammar provides important clues to the meaning of terms in a sentence. Keep the following guidelines in mind:

  • Write positive statements. Avoid using negative words, such as problem, bad, wrong, fail, error, fatal, terminate, and trouble. Instead, tell the user what the problem is, what to do, and why.
  • Avoid redundancy. For example:
    • Surrounding environment
    • Absolutely complete
    • Exactly identical
    • Repeat again
    • Final conclusion
    • Basic and fundamental
    • Knowledge and awareness
    • Each and every
    • Complete overview
    • Advance planning
    • Full and complete
    • Informative message
  • If you state the correct condition, do not also state that the incorrect condition should not exist. For example, if you say “The computer must be running,” do not also say “It must not be shut off”.
  • Use consistent phrasing for similar situations. This avoids users assuming that a different meaning may be intended by a change in wording.
  • Use the plural form of a word rather than using “(s)” (or use both the singular and plural forms).
    File names File name(s)
Parallel Construction

Use the same grammatical structure for elements of sentences or phrases that provide the same kind of information. For example, use parallel construction for items in lists and groups of check box labels or option button labels. In the following example, all the items in the Correct list begin with verbs in the active voice and are phrased in the imperative mood. Items in the Incorrect list are in a mix of voice and mood.

Get up-to-date information about upgrades and new products. Up-to-date information about upgrades and new products will be sent to you.
Use Windows Update to download product updates. Using Windows Update you can download product updates.
Receive the best possible customer support. The best possible customer support is available.
Gain access to the latest files and drivers. You can gain access to the latest files and drivers.
Sentence Construction

Use sentences in the interface to explain concepts, introduce features, and discuss controls. Follow these guidelines when writing sentences:

  • Write short, simple sentences. Break long sentences into two or more shorter sentences.
  • Use lists or tables to break up text.
  • Use the present tense.
    Windows cannot find the file. Windows could not find the file.
  • Write affirmative statements, telling the user what to do rather than what to avoid (unless there is a reason the user should not perform a particular action).
    To restart your computer, click Restart. Do not use CTRL+ALT +DEL to restart your computer.
  • When a sentence describes a sequence of actions, describe the actions in the order in which the user performs them.
    Reinstall the program and then restart your computer. You’ll need to restart your computer after you reinstall the program.
  • Avoid using a control within a sentence or phrase if the text will be localized. Instead, place it at the end of the sentence or phrase.
    Number of concurrent connections per server: Control Per server for Control concurrent connections.

Use the active voice to clarify who or what is performing the action in a sentence.

Windows cannot find the configuration file. The configuration file cannot be found.

You can help users learn your product more quickly by using terminology that is familiar to them and by using the same terminology for a particular concept throughout the interface. If your product will be localized, create a list of defined terms to localize.

Use familiar wording on menus, commands, control labels, and toolbars. Avoid technical jargon. Write so that the least skilled user of the application will understand.

Send and receive sound at the same time. Use full-duplex audio.

Define terms that are unfamiliar or are used more narrowly or broadly in your product than in common use. For example, you can sometimes use descriptors to identify a term’s meaning or purpose. This can help users understand the context of the term.

You have to specify the parameter InflD when the option Detect is set to “No”. You have to specify InflD when detect is set to No.
The value CiDialect specification for web hits is not valid. The CiDialect specified for web hits is not valid.

In general, use “click” to describe selecting command buttons, option buttons, hyperlinks, tabs, menus, and menu items. Use “select” to describe selecting items in a list box or gallery.

Click OK. Press OK.
On the Edit menu, click Copy. On the Edit menu, select Copy.
To remove any temporary files, click Remove. To remove any temporary files, choose Remove.

Use “press” to describe pressing a key on the keyboard. Use “type” when referring to typing words.

To continue, press ENTER. To continue, hit ENTER
Type your name in the space provided. Key your name into the space provided.

Use “select” and “clear” in instructions for a check box.

To add a component, select its check box. To add a component, click its checkbox.
To remove the component, clear the check box. To remove die component, uncheck it.
Select the appropriate check boxes. Enable the appropriate options.
Clear the Bookmarks check box. Click to uncheck the Bookmarks option.

However, use “click to remove the check mark” rather than “clear” to describe removing a check mark from a menu item.

Take care to avoid using words or phrases that may offend some I users. The following guidelines can help writers and editors recognize terms that may inadvertently cause offense or convey an inappropriate message:

  • In general, consider the person first, not the label. Use “a person with [kind of disability], not “the disabled person”.
  • When you refer to a user interface element or command, use “unavailable” or use “make unavailable” rather than “disabled” or “disable”. The word “disable” is acceptable in technical documentation in the context of a programmer setting the guidelines for making a command unavailable.
  • Use the following terms to describe people with disabilities or the disabilities themselves.
    Use these termsInstead of
    Blind, has low vision, visually impaired Sight-impaired, vision impaired
    Deaf or hard-of-hearing Hearing-impaired
    Has limited dexterity, has motion disabilities Crippled, lame
    Without disabilities Normal, able-bodied, healthy
    One-handed, people who type with one hand Single-handed
    People with disabilities The disabled, disabled people, people with handicaps, the handicapped
    Cognitive disabilities, developmental disabilities Slow learner, retarded, mentally handicapped
    TTY/TDD (to refer to the telecommunication device) TTY/TDD


Microsoft Windows User Experience, Official Guidelines for User Interface Developers and Designers.