Top Rules for the Windows Vista User Experience

This article summarizes the top rules for creating high-quality, consistent Windows Vista® user interfaces (UIs).

  1. Use the Aero Theme and System Font (Segoe UI)
  2. Use common controls and common dialogs
  3. Use the standard window frame, use glass judiciously
  4. Use icons and graphics consistent with the Windows Vista style and quality
  5. Use task dialogs for new or frequently used dialog boxes and error messages
  6. Use Aero Wizards
  7. Use Windows Explorer-hosted, navigation-based user interfaces, provide a Back button
  8. Use the Windows Search model
  9. Use the Windows tone in all UI text
  10. Clean up the UI
  11. Use notifications judiciously
  12. Reserve time for "fit and finish"!

Rule 1: Use the Aero Theme and System Font (Segoe UI)

Bring the Windows Vista User Experience design into your application by using themes and the standard system font.


  • Use the Themes application programming interface (API) to enable visual styles in your application. On Windows Vista, the application UI is automatically rendered with the new Aero visual style. Ensure your UI is correctly using the Windows Vista common controls (ComCtl32 v6). Developers can draw Theme parts by using the DrawThemeBackground API. Use the Aero Theme XML documentation.
  • Use Segoe UI, the new Windows Vista system font.
  • Respect the user's settings by always referencing the system font, sizes, and colors using the Windows Theme APIs. Don't use fixed values for fonts, sizes, or colors.
  • Use theme painting APIs to owner-draw any elements that look like standard system elements.

For more information, see What's New: Aero Aesthetics, What's New: System Font (Segoe UI).

Rule 2: Use common controls and common dialogs

Use common controls and common dialogs to achieve an accessible, high-quality, and consistent UI in your application. Don't spend time rebuilding standard UI components; use that time instead to innovate in meaningful ways based on your core competencies and understanding of your customer needs.


For detailed guidelines, see Common Controls and Common Dialogs.

Rule 3: Use the standard window frame, use glass judiciously

To get the Windows Vista glass borders automatically, all you have to do is use the standard window frame.


  • Use the standard window frame. Glass, as seen in Windows Vista translucent window frames, is an important part of the new aesthetic, aiming to be both attractive and lightweight. By running on Windows Vista, this aspect of Aero design is integrated with every application.
  • Don't create your own nonstandard window frame by drawing in the non-client window region.
  • Optimize for resizable windows using a standard screen resolution of 1024x768 pixels. Support the minimum Windows Vista screen resolution of 800x600 pixels. Layouts may use glass on small interface surfaces where it contributes to better focus on what matters to users in your application window.
  • If an application's design calls for additional glass surfaces, developers can use the glass API. Using glass in your application is not something everyone should do. You don't need to have glass in your UI to make a great Windows Vista-based application. Glass is best used on small regions without text or interactive UI. The objective is to reduce the "weight" of the surface of the application to focus on the most important parts of the UI. Preferably use glass in surfaces touching the window frame, visually integrating your application with the window border for a more cohesive "look and feel."

For detailed guidelines, see Window Frames, Window Management, and Layout.

Rule 4: Use icons and graphics consistent with the Windows Vista style and quality

Icons are visual representations of applications, items, actions, real-world objects, or concepts in the system (such as control panel items or network connection). Icons help users recognize and learn meaning and purpose in your UI, identifying places and items, and finding their way through the system by way of "visual landmarking."


  • Make your application icon the star! Ensure it is meaningful, and reflects its function and your brand. Make it distinct, make it special, and ensure it renders well in all icon sizes and on all surfaces. Spend the time necessary to get it right. If you do not have an in-house graphic designer, outsource the task to experts at one of the many design agencies.
  • All icons used in Windows Vista client (for items such as applications, devices, document types, and control panel items) must adhere to the Aero-style icon guidelines. You must replace all graphics designed for Windows 3.1, Windows 95, and Windows 98 operating systems. Windows XP-style graphics can be used in Windows Vista, but preferably should be updated.
  • Select icons based on meaning, not appearance. Make sure that your icons have consistent meaning throughout your application and don't conflict with existing icons or conventions in the system, or in other commonly used Windows-based applications.
  • Render icons in all sizes needed, but optimize their design for the sizes most often seen by users. For example, Windows Explorer can display icons up to 256x256 pixels, but toolbar icons are limited to 24x24 pixels.
  • For the main file types of your application that users interact with in Windows, consider using the Windows Thumbnailing API to get live previews of those files in Windows Explorer views.
  • Use the .png file format for large icons to reduce their size.
  • Use the standard system icons where appropriate.

For detailed guidelines, see Icons, Standard Icons, and Graphic Elements.

Rule 5: Use task dialogs for new or frequently used dialog boxes and error messages

Dialog boxes are the most fundamental form of user communication. Dialog boxes with a clear main instruction and explicit, self-explanatory commit buttons make that communication much more effective. The task dialog API allows developers to create well-designed, consistent dialog boxes efficiently. You can also create task dialogs to provide well-written, useful error messages.


  • Use task dialogs for modal dialogs or high-priority error messages, to provide a better, more explanatory UI for these cases, and achieve a look consistent with Windows Vista. Task dialogs require Windows Vista or later, so they aren't suitable for earlier versions. If you can't use a task dialog, follow the Windows Vista layout rules for dialog boxes and reference the Windows Vista Theme File.
  • Use the main instruction to explain what to do with the dialog in clear, plain, concise language. Good instructions communicate the point behind the dialog rather than focusing on the mechanics of manipulating it.
  • Use modal dialog boxes for infrequent and important choices that users must actively make before continuing. Use a delayed commit model so that changes don't take effect until explicitly committed.
  • Consider using modeless dialog boxes for frequent, repetitive, ongoing tasks. Use an immediate commit model so that changes take effect immediately. However, toolbars and palette windows are often better alternatives for such tasks.
  • Don't use dialog boxes just to provide a message to the user. When users don't have to interact, use modeless alternatives such as task panes, balloons, notifications, or status bars instead.
  • Use positive commit buttons that are specific responses to the main instruction instead of generic labels (such as "OK"). Users should be able to grasp the options quickly by reading the button text alone. Always start commit button labels with a verb.
  • When a page has a small set of fixed options, use command links instead of a combination of radio buttons and a commit button. This allows users to select a response with a single click.
  • Consider cleaning up your dialog by using a More Options "expando" button, so advanced or rarely used options remain hidden by default.
  • Use notifications when an event is not related to the current user activity, doesn't require immediate user action, and users can freely ignore it. Don't use dialogs for these cases - they will be seen as highly interruptive.
  • Don't provide an error message at all if users aren't likely to perform an action or change their behavior, or if the problem can be eliminated without causing confusion.

For detailed guidelines, see Dialog Boxes, Task Dialogs, Layout, and Error Messages.

Rule 6: Use Aero Wizards

Aero Wizards replaces Wizard '97 with a cleaner, simpler, better-looking design with theme support. Its page layout is much more flexible and can be resizable.


  • Don't use Welcome pages, but offer functional UI on the first screen whenever possible. Consider using an optional Getting Started page only when:
    • The wizard has significant prerequisites such that proceeding without the prerequisites would be a waste of time.
    • Users may have trouble determining the purpose of the wizard based on its first Choice page and there isn't sufficient room for further explanation.
  • Don't use Congratulations pages at the end of the wizard. If the result of the wizard can be made apparent to users, close the wizard on the final commit and ensure the feedback on completion is clear to users. Consider using an optional Follow-up page only when:
    • There is no other way to provide users with feedback on completion, such as when the results aren't visible.
    • There are related tasks that users are likely to do as follow-up. Avoid familiar follow-up tasks, such as "Send an e-mail."
  • Use the main instruction to explain explicitly what to do with the page in clear, plain, concise language. Good instructions communicate the user's objective with the page rather than focusing purely on the mechanics of manipulating it. Don't repeat the main instruction elsewhere with slightly different wording.
  • For Commit pages, confirm tasks using commit buttons that are specific responses to the main instruction instead of generic labels like Finish. The labels on these commit buttons should make sense on their own. Always start commit button labels with a verb.
  • For Follow-up pages, use Close to close the wizard. Don't use Done or Finish commit buttons to close the Wizard window.
  • Consider using command links to provide descriptive choices with supporting text and an icon, so that the user can efficiently navigate through the wizard.
  • Make your wizard resizable if one of the steps involves presenting a view where a user might benefit from having control over the window size.

For detailed guidelines, see Wizards.

Rule 7: Use Windows Explorer-hosted, navigation-based user interfaces, provide a Back button

Navigation-based UI—characterized by staying in a single window and having a Back button in the upper-left corner—allows users to navigate easily, efficiently, and confidently; they can always "go back." Even traditional applications that don't inherently navigate can often benefit from providing in-frame navigation.


  • Use Windows Explorer windows and wizards for multi-step, sequential tasks that are infrequently used. Doing so allows users to explore with ease, proceed step-by-step through the task, and easily recover if they make mistakes.
  • Provide a Back button to support easy navigation through your application, and to make it easy for people to switch between different views or states in your application.
  • Use multiple windows when the task is likely to be performed in parallel with other tasks the original window provides.

For detailed guidelines, see Window Management and Wizards.

Rule 8: Use the Windows Search model

With the Windows Vista Search box, users can quickly locate specific objects or text within a large set of data by filtering or highlighting matches. In Windows Vista, Search is part of all Windows Explorer windows and appears and behaves consistently, making it easy to find and recognize.


There is no standard search control, but you should strive to make your program's search features consistent with the Windows Search model.

  • For application windows, locate the Search box in the upper right-hand corner.
  • Use the standard Search button graphics. Don't use a label, but do use a prompt within the Search box, such as Type to search.
  • Support "Instant search" wherever possible to show instant results while the user is typing. Provide both regular search and "Instant search" if there are scenarios where regular searching is worth the extra wait time.
  • Where possible, support Back navigation to return to a previous view from a search result list.
  • Regular searches must return relevant results within five seconds and "Instant search" must return within two seconds. After this point, Search may continue to fill in less relevant results over time as long as the program is responsive and users can perform other tasks. Provide feedback on activity with a "busy" indicator, so users know the search is being performed.

For detailed guidelines, see Search Boxes.

Rule 9: Use the Windows tone in all UI text

Use the Windows Vista "tone" to inspire confidence by communicating to users on a personal level by being accurate, encouraging, insightful, objective, and user focused. Don't use a distracting, condescending (for example, "Just do this..."), or arrogant tone.

  • Make sure that your text is clear, natural, concise, and not overly formal, and uses terminology that all users understand.
  • Use everyday words when you can and avoid words you wouldn't say to someone else in person. This is especially effective if you are explaining a complex technical concept or action. Imagine yourself looking over the user's shoulder and explaining how to accomplish the task.
  • Because users often scan text, make every word count. Simple, concise sentences (and paragraphs) not only save space on the screen but are the most effective means of conveying that an idea or action is important. Use your best judgment—make sentences tight, but not so tight that the tone seems abrupt and unfriendly.
  • Avoid repetition. Review each window and eliminate duplicate words and statements. Don't avoid important text—be explicit wherever necessary—but don't be redundant and don't explain the obvious.

For detailed guidelines, see Style and Tone.

Rule 10: Clean up the UI

Remove clutter, unify surfaces visually, and make the UI look well organized and thought through.

  • Organize your commands into a simple, predictable, and easy to find presentation, using task-oriented categories and labels.
  • For programs that create or view documents, use the standard menu categories such as File, Edit, View, Tools, and Help.
  • For other types of programs, consider organizing your commands and options into more useful, natural categories based on your program's purpose and the way users think about their tasks and goals. Don't feel obligated to use the standard menu organization if it isn't suitable for your program.
  • Make the most common commands easy to find by putting them in the top level of the command presentation. Don't put frequently used menu items in a submenu. Doing so would make using these commands inefficient. However, you can put frequently used commands in a submenu if they are normally accessed more directly, such as with a toolbar.
  • Provide context menus for all objects and window regions that benefit from a small set of contextual commands and options. Many users right-click regularly and expect to find context menus anywhere.
  • Consider hiding the menu bar if the toolbar or direct commands provide most of the commands needed by most users. Allow users to show or hide with a Menu bar check mark option in the toolbar.
  • Provide menu item icons for the most commonly used menu items, menu items whose icon is standard and well known, and menu items whose icon well illustrates what the command does. However, if you use icons, don't feel obligated to provide them for all menu items.
  • To ensure keyboard accessibility, assign access keys to all menu items. No exceptions.
  • Remove borders, separator lines, boxes, and other visual "noise" that isn't necessary or functional.
  • Remove unneeded text. Eliminate repetition in labels.
  • Use hover states and just-in-time UI in context or on selection.
  • Choose your default UI wisely; don't optimize for unlikely and complicated cases. Instead, design for the most common user scenarios, ensuring they end up as the showcase experiences.
  • Hide complexity in default states; simplify the visual design of elements where possible; show details and functionality on hover.
  • Improve layout—align borders, text, and objects. Provide enough space so items are not touching each other or feel crammed.
  • Ensure consistent use of common elements in your UI. Use standard components and controls unless being nonstandard specifically benefits your customers' or end users' needs.

Rule 11: Use notifications judiciously

When used correctly, notifications are an effective way to keep users informed. Notifications are ideal for useful, relevant, non-critical information because their peripheral, modeless presentation doesn't break users' flow.


  • Use notifications only if you really need to. Good notifications are relevant to the user and actionable. When you display a notification, you are potentially interrupting users or even annoying them. Make sure that interruption is justified.
  • Use notifications for non-critical events or situations that don't require immediate user action. For critical events or situations that require immediate user action, use an alternative UI (such as a modal dialog box).
  • Choose the appropriate length of time to display a notification based on its usage, ranging from 7.5 seconds for FYIs to 25 seconds for interactive notifications.
  • Make notifications clickable so that users can perform an action or see more information. Clicking the notification should display a window in which users can perform the action.
  • Use heading text that briefly summarizes the most important information you need to communicate to users. Users should be able to understand the purpose of the notification information quickly and with minimal effort.
  • Use body text that gives a description (without repeating the information in the heading) and, optionally, that gives specific details about the notification, and also lets users know what action is available.
  • Don't create a custom notification mechanism. Use the standard Windows notification instead.

For detailed guidelines, see Notifications and Notification Area.

Rule 12: Reserve time for "fit and finish"!

To deliver high-quality fit and finish, schedule time to attend to UI details, including visual clean-up at the pixel level and layout corrections (alignment, spacing). Visual "fit and finish" is as important as standard bug fixing and other types of quality control.

Perception is reality, and if your customers don't experience quality in your product throughout, they may conclude there is lack of quality everywhere. A visual bug seen by all your customers might do more damage to your program's reputation than a rarely occurring crashing bug.

Guidelines feedback