Adaptive defaults

Problem Context

• The user repeatedly fills similar fields, chooses similar scopes, opens similar filters, schedules similar work, exports similar data, or applies similar layout and channel choices.
• The product has signals such as recent use, current object, role, locale, device, calendar, organization policy, saved setting, explicit preference, previous correction, or aggregate common value.
• The proposed value affects the current task, but may also touch permissions, privacy, external communication, money, scheduling, compliance, or shared workspace behavior.
• Users need to distinguish a helpful starting value from a saved preference, system requirement, recommendation, or hidden automation.

Selection Rules

• Choose adaptive defaults when the system proposes a starting value inside the current task based on context or learned behavior.
• Use static defaults when the same representative value is best for most users and no personal or contextual signal is involved.
• Use settings management when users need to inspect or change durable configuration that persists beyond the current task.
• Use preference center when the value represents communication, consent, privacy, topic, personalization, language, or required-message choices.
• Use recommendations when the system ranks optional items or actions rather than filling a value the user must review or edit.
• Expose the default source in user-facing terms such as Last used, From your role, From device time zone, From workspace policy, From previous correction, or Most common for this form.
• Show whether the adapted value applies only now, to this object, to this workspace, to this device, or as a remembered future default.
• Require review before accepting adaptive defaults that send data externally, change access, move money, alter legal state, update privacy choices, delete data, or affect other people.
• Capture explicit corrections as feedback only after making the scope clear; do not infer durable preference from one correction in a high-risk context.
• Fall back to a neutral value when signals are stale, low confidence, sensitive, conflicting, permission-restricted, or policy-managed.

Required States

• Neutral default state with no personal signal
• Adaptive default state with proposed value, source, scope, and reason
• User-edited state that distinguishes one-time correction from remember-for-next-time
• Remembered correction state
• Reset to system default or stop adapting state
• Low-confidence, stale, conflicting-signal, or unavailable-signal fallback state
• Policy-managed or inherited default state
• High-impact review state before submit or apply
• Mobile narrow-screen state where source and change controls remain visible

Interaction Contract

• Opening the task shows the proposed value and why it was chosen before the user submits, exports, sends, schedules, or applies anything.
• Editing an adaptive default changes the current task first; remembering the correction is a separate, clearly scoped action.
• Reset restores the named default source or system value without clearing unrelated preferences, saved filters, history, or settings.
• When the source signal changes, the displayed reason and value update together or the UI asks the user to refresh before submit.
• Adaptive defaults never override explicit saved settings, consent choices, policy restrictions, or user-authored preferences without explanation.
• Dismissal, reset, correction, and remember outcomes are confirmed through visible status text and used as feedback only within the stated scope.

Implementation Checklist

• Inventory each adaptable field by default source, confidence, freshness, scope, effect, risk, fallback value, and reset behavior.
• Model adaptive defaults separately from saved settings, user preferences, recommendation items, hidden autofill, validation, and required workflow state.
• Store user-facing reason metadata for each source, including recent use, role, locale, device, policy, current object, prior correction, or common value.
• Define when a correction is one-time, remembered for this field, remembered for this workflow, or ignored because the field is high risk.
• Gate high-impact adapted values behind review, confirmation, or explicit apply before side effects occur.
• Add controls for change, reset, stop adapting, remember correction, and inspect source where risk or surprise is likely.
• Test stale signals, conflicting signals, shared devices, privacy-sensitive history, policy-managed values, low confidence, mobile wrapping, keyboard flow, and screen-reader announcements.

Common Generated-UI Mistakes

• Preselecting values to increase conversion, spend, sharing, or consent rather than to reduce honest user effort.
• Saving an adapted value as a durable setting without asking.
• Using private history, location, or team behavior as a default source on a shared or public surface without explanation.
• Showing an adaptive value with no source label, no reset path, and no distinction from a required value.
• Treating repeated corrections as user error instead of updating the default rule or asking whether to remember the change.
• Letting stale project, recipient, time zone, currency, or permission defaults survive after context changes.
• Replacing clear settings or preference controls with hidden learning behavior.

Critique Questions

• What exact signal or rule produced this default value?
• Can the user see whether this is a one-time starting value, a saved setting, a policy value, or a remembered preference?
• What happens when the user changes the value once, changes it repeatedly, resets it, or asks the product to stop adapting?
• Could this default send data, spend money, expose private activity, change access, or affect another person?
• Is the default source fresh, permitted, and appropriate for shared devices, shared workspaces, and sensitive categories?
• What neutral fallback appears when the signal is weak, stale, conflicting, or unavailable?