Use the “Settings” label for access to Settings.
- Side navigation
If side navigation exists, place Settings below all other items (except Help & Feedback). Otherwise, place Settings in the toolbar action overflow menu below all other items (except Help & Feedback).
- Navigation drawer
When a navigation drawer is accessible from the current screen, place Settings in the drawer. Otherwise, place Settings in an action overflow menu.
Settings are given low prominence in the UI due to limited usage.
When to use Settings
Settings should be well-organized, predictable, and contain a manageable number of options. If a setting were removed, would it cause harm to the minority who would no longer be able to access it? If so, keeping it as a setting is appropriate.
Controls that belong in Settings:
- Capture a user preference
- Are infrequently accessed
- Are used by the majority of users
For large lists of settings, cluster settings into multiple shorter lists. Arrange them according to the total number of settings in the Settings panel in your app.
7 or fewer
Don’t group at all.
9 to 10
Group related settings under one or two section dividers. For settings that can't be grouped:
- If important, list them at the top without a section divider.
- Otherwise, list them at the bottom with a section divider called "Other," in order of importance.
11 to 15
Group related settings under two to four section dividers. Combine sets of two related settings into a single setting.
For example, two related settings with checkboxes could combine into a single multiple-choice setting.
16 or more
Group four or more related settings under a subscreen. Apply the guidance above to each subscreen.
The initial value for each setting should make sense. Default choices should aim to:
- Represent the default most users would choose
- Be neutral and pose little risk
- Use less battery or mobile data
- Only interrupt when important