Overview
Enterprise settings pages should keep unrelated controls separated by section while preserving a coherent hierarchy.
A strong settings floorplan improves discoverability for infrequently used controls.
Configure the workspace safely
Navigate owned and managed settings, create a dirty state, confirm a high-risk security change, and save or reset with explicit audit feedback.
Settings
Configure workspace behavior with clear ownership, inheritance, and safe save boundaries.
General settings
Changes apply to every member unless a policy owner manages the value.
Workspace identity
Visible name and regional defaults.
Anatomy
Use each piece in this order to keep interpretation and automation consistent.
- 1Section shell
Primary grouping by domain: account, security, integrations.
- 2Preference controls
Inputs with clear defaults and restore options.
- 3Safety prompts
Confirmation dialogs for irreversible preferences.
- 4Save state
Draft/saved indicators to prevent accidental loss.
- 5Rollback action
Reset path for mistakes and stale defaults.
The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.
When to use
Use this pattern when the user needs guided consistency, state, and reuse at scale.
Recommended
- Complex applications
Many settings categories and role restrictions.
- Compliance configurations
Settings with policy or security impact.
- Self-service admin
Where support load drops with clear grouped controls.
When not to use
Avoid forcing this pattern where simpler, direct interactions are sufficient.
Avoid
- Onboarding micro-settings
Use compact forms for initial setup.
- Single-purpose screens
Use dedicated workflows for rare actions.
- High-frequency changes
Use faster command surfaces for repeated toggles.
Variants
A small number of variants helps teams choose correctly without adding complexity.
Tabbed
Category sections with deep-linking and stable order.
Accordion
Progressive discovery for dense options.
Security-first
Additional confirmation for sensitive operations.
States
States communicate readiness, risk, and expected user behavior.
| State | Trigger | Visual response | Interaction |
|---|---|---|---|
| Draft | Changes in progress | Unsaved marker and secondary save option | Prompt on navigation if unsaved. |
| Saved | Submit successful | Confirmation toast and sync summary | Continue to other settings. |
| Risk change | Critical toggle | Explicit warning modal | Require explicit confirmation step. |
Behavior
Behavior should remain predictable across devices, permissions, and async edges.
Explicit save model
Separate draft and publish steps when risk is non-trivial.
Reset paths
Offer reset to defaults and section resets.
Audit capture
Log critical preference changes.
Accessibility
Keep interaction clarity high and ensure assistive technologies get the same meaning.
| Key | Action |
|---|---|
| GS | Save setting changes quickly when supported. |
| Esc | Cancel edited section and return to saved state. |
| Tab | Move through grouped controls in logical order. |
- Pair toggle controls with explicit labels and explanatory text.
- Avoid modal-only confirmation for safety actions without focus return.
- Keep section headings and error text discoverable in flow.
Content guidelines
Consistency is achieved by language standards, not by design only.
Confirmation language
Use plain language for critical risks.
Turning off 2FA disables login protection.
Grouping
Keep related controls in one section.
Security → Access methods.
Default labels
Indicate when a control is inherited or managed.
Managed by your organization
Examples
Reference implementation style, payloads, and practical behavior.
Production use
- Use side-by-side layout for dense settings to reduce scroll.
- Add a visible unsaved state with one exit confirmation.
- Lock destructive controls behind explicit confirmation and audit event.
Props / API
Use these API entries as a baseline contract and validate them against your domain layer.
These names are implementation-oriented and should map to your local contracts.
Props