Settings management

Problem Context

• Users need to change persistent app behavior, account behavior, workspace policy, notification preferences, privacy choices, display preferences, integrations, devices, permissions, or system-like configuration.
• Settings may affect one device, one workspace, one account, all users, a role, an integration, or downstream surfaces.
• Some settings apply immediately while others require Save, approval, restart, sync, or system permission changes.
• Users may revisit settings rarely and need clear labels, categories, current status, search, and reset paths.
• Settings may have dependencies, unavailable states, admin ownership, inherited values, conflicts, audit implications, or high-risk consequences.

Selection Rules

• Choose settings management when users need a durable place to inspect and change persistent preferences or configuration.
• Use toggle switch when the task is one immediate, reversible binary setting rather than a whole settings surface.
• Use complete complex form when many related configuration fields require one edit-and-review form with dependency validation before save.
• Use progressive disclosure when a primary task needs optional advanced controls, not a revisitable settings center.
• Use profile setup when the work is completing an existing profile's readiness, visibility, or enrichment.
• Use onboarding when the work is first-use orientation or activation, not persistent configuration management.
• Separate account, workspace, device, and system-level scope with explicit labels before users change values.
• Make immediate-apply settings visually and verbally distinct from settings that require Save, Apply, Restart, Sync, or admin approval.
• Show current values, unavailable reasons, inherited defaults, and reset routes close to the setting they affect.

Required States

• Settings overview with categories and current values
• Focused section or detail state
• Immediate setting applied state
• Unsaved changes state
• Saved or applied confirmation state
• Unavailable or permission-blocked setting state
• Inherited or admin-managed setting state
• Reset to defaults state
• Search or filter no-result state for larger settings sets
• Failed save or conflict state with preserved changes

Interaction Contract

• Opening settings management shows current persisted values, not empty defaults or stale cached assumptions.
• Each setting communicates its scope, effect, and save model before the user changes it.
• Immediate settings reconcile applied, pending, failed, and reverted states without requiring a hidden Save action.
• Explicit-save settings preserve edited values, show unsaved changes, and let users save, discard, or review before leaving.
• Disabled, inherited, managed, or permission-blocked settings explain who owns the value and where to change it.
• Reset restores only the named settings group or clearly listed defaults, never unrelated account or product data.
• Search and section navigation move users to the owning setting while preserving unsaved-change warnings.

Implementation Checklist

• Inventory settings by scope, owner, data source, dependency, effect timing, risk, default value, and reset behavior.
• Decide whether each setting is immediate, staged with Save, inherited, admin-managed, system-owned, or approval-gated.
• Group settings by user mental model such as Account, Notifications, Privacy, Display, Integrations, Workspace, Billing, or Devices.
• Show current values and short effect descriptions for settings whose labels alone are ambiguous.
• Provide search, section navigation, or deep links when the settings set is large enough that scanning is unreliable.
• Design unsaved-change warnings, failed-save recovery, conflict handling, inherited values, unavailable permissions, and reset defaults.
• Test keyboard navigation, screen readers, mobile layout, high zoom, long labels, localized strings, search no results, permission denial, admin-managed values, and stale server data.

Common Generated-UI Mistakes

• Using settings as a dumping ground for unrelated navigation, billing, help, profile setup, onboarding, or destructive account actions.
• Mixing immediate and explicit-save settings without clear status or grouping.
• Hiding current values behind edit buttons so users cannot inspect configuration quickly.
• Making settings available in multiple places with contradictory values or labels.
• Changing account-wide or workspace-wide behavior from a local page without scope warning.
• Letting disabled or inherited settings appear broken instead of explaining dependency, permission, or admin ownership.
• Resetting too broad a scope from a small reset action.
• Failing to warn about unsaved setting changes before navigation.

Critique Questions

• What scope does each setting affect: device, account, workspace, organization, integration, or system?
• Does the user know whether the change applies immediately or waits for Save, restart, sync, approval, or another device?
• Can users inspect current values without entering edit mode?
• Which settings are inherited, managed, permission-blocked, or dependent on other settings?
• How do users find a rarely changed setting months later?
• What happens to unsaved, failed, conflicting, or reset settings?