Skip to main content
Guidelines for app settings

App settings are the user-customizable portions of your app. For example, a news reader app might let the user specify which news sources to display or how many columns to display on the screen. This article describes best practices for creating and displaying app settings.

Should I include a settings page in my app?

Here are examples of settings that belong in a settings page:

  • Configuration options that affect the behavior of the app and don't require frequent readjustment, like choosing between Celsius or Fahrenheit as default units for temperature in a weather app, changing account settings for a mail app, or accessibility options.
  • Options that depend on the user's preferences, like music, sound effects, or color themes.
  • App information that's not accessed very often, such as privacy policy, help, app version, or copyright info.

Commands that are part of the typical app workflow (for example, changing the brush size in an art app) shouldn't be in a settings page. To learn more about command placement, see Command design basics.


It's best to keep settings pages simple and make use of binary (on/off) controls, such as this one that uses a toggle switch.

Example of a settings pane


Another example of a settings page. In this case, there's a link ("Properties") to more detailed settings.

Example of app settings pane with Wi-Fi


General principles

  • Create entry points for all of your app settings in your app setting's page.
  • Keep your settings simple. Define smart defaults and keep the number of settings to a minimum.
  • When a user changes a setting, the app should immediately reflect the change.
  • Don't include commands that are part of common app workflow, like changing the brush color in an art app, in an app settings page. (For more info, see Command design basics.)

Entry points

Entry points are the labels that appear at the top of your setting's page. Once you have a list of settings you want to include, consider these guidelines for the entry points:

  • Group similar or related options under one entry point.
  • Avoid adding more than four entry points to your Settings pane.
  • Display the same entry points regardless of the app context. If some settings are not relevant in a certain context, disable them in the Settings flyout.
  • Use descriptive, one-word labels for your entry points when possible. For example, for account-related settings, name the entry "Accounts" rather than "Account settings." If you only want one entry point for your settings and the settings don't lend themselves to a descriptive label, use "Options" or "Defaults."
  • If an entry point links directly to the web instead of to a flyout, let the user know this with a visual clue, for example, "Help (online)" or "Web forums" styled as a hyperlink. Consider grouping multiple links to the web into a flyout with a single entry point. For example, an "About" entry point could open a flyout with links to your terms of use, privacy policy, and app support.
  • Combine less-used settings into a single entry point so that more common settings can each have their own entry point. Put content or links that only contain information in an "About" entry point.
  • Don't duplicate the functionality in the "Permissions" pane. Windows provides this pane by default and you can't modify it.

Add settings content to Settings flyouts

  • Present content from top to bottom in a single column, scrollable if necessary. Limit scrolling to a maximum of twice the screen height.
  • Use the following controls for app settings:

    • Toggle switches: To let users set values on or off.
    • Radio buttons: To let users choose one item from a set of up to 5 mutually exclusive, related options.
    • Text input box: To let users enter text. Use the type of text input box that corresponds to the type of text you're getting from the user, such as an email or password.
    • Hyperlinks: To take the user to another page within the app or to an external website. When a user clicks a hyperlink, the Settings flyout will be dismissed.
    • Buttons: To let users initiate an immediate action without dismissing the current Settings flyout.
  • Add a descriptive message if one of the controls is disabled. Place this message above the disabled control.
  • Animate content and controls as a single block after the Settings flyout and header have animated. Animate content using the enterPage or EntranceThemeTransition animations with a 100px left offset.
  • Use section headers, paragraphs, and labels to aid organize and clarify content, if necessary.
  • If you need to repeat settings, use an additional level of UI or an expand/collapse model, but avoid hierarchies deeper than two levels. For example, a weather app that provides per-city settings could list the cities and let the user tap on the city to either open a new flyout or expand to show the settings options.
  • If loading controls or web content takes time, use an indeterminate progress control to indicate to users that info is loading. For more info, see Guidelines for progress controls.
  • Don't use buttons for navigation or to commit changes. Use hyperlinks to navigate to other pages, and instead of using a button to commit changes, automatically save changes to app settings when a user dismisses the Settings flyout.

[This article contains information that is specific to Universal Windows Platform (UWP) apps and Windows 10. For Windows 8.1 guidance, please download the Windows 8.1 guidelines PDF .]

Related topics

For designers
Command design basics
For developers (XAML)
Store and retrieve app data