{"slug":"smart-defaults","meta":{"title":"Smart Defaults","slug":"smart-defaults","kind":"pattern","summary":"Fill the field with the answer that is right most of the time, from context you already have — so the common case needs no decision and the exception is still easy.","problem":"A form asks for values the system could work out — today's date, this client's usual terms, the currency of the account. The person answers them anyway, every time, and sometimes answers wrongly because they were guessing at a field they had no opinion about.","family":["capture","edit"],"data_shape":["record"],"principles":["friction","progressive-disclosure"],"interaction":["editing"],"density":"low","complexity":"low","status":"stable","visibility":"public","use_when":["One value is right in the large majority of cases.","The right value can be derived from context — the client, the user, the time, the last one.","The field is required, so the person cannot simply skip it."],"avoid_when":["The choice has real consequences and no clear majority — a payment amount, a recipient, a permission level.","A wrong default would be silently harmful and hard to notice.","The distribution is genuinely even, where a default is a nudge dressed as a convenience."],"alternatives":[{"slug":"minimal-form","when":"The stronger move is to not ask at all yet."},{"slug":"validation-errors","when":"The value cannot be defaulted and must be explained when wrong."}],"ask_leo":"Give these fields sensible defaults instead of leaving them empty.\n\n- Derive each default from context you already have: the current user, the\n  selected client, today's date, the account settings, or the value used last\n  time for this kind of record.\n- Show the default as a real, editable value — never as greyed-out placeholder\n  text that vanishes and leaves an empty required field.\n- Say where a non-obvious default came from, briefly, next to the field:\n  \"30 days — this client's usual terms\".\n- Make changing it exactly as easy as accepting it. A default must never be a\n  lock.\n- Never default a field whose wrong value would be harmful or hard to notice —\n  amounts, recipients, permissions, anything that sends or charges.\n- When you cannot pick a good default, leave it empty rather than guessing.\n  A confidently wrong default is worse than a blank, because it looks decided.\n","related":[{"title":"Minimal Form","url":"/patterns/minimal-form","summary":"The stronger version of the same instinct — defaulting is what lets a field leave the form."}]},"body":"## Anatomy\n\n```\n  Issue date     [ 6 Sep 2026            ]  today\n  Payment terms  [ 30 days               ]  Riverside's usual terms\n  Currency       [ USD                   ]  account default\n  Owner          [ Dana Whitfield        ]  you\n  Amount         [                       ]  ← deliberately NOT defaulted\n                                              wrong value here is harmful\n```\n\nThree properties:\n\n1. **Real values, not placeholders.** A grey hint that disappears on focus is\n   not a default — it is an empty required field wearing a disguise.\n2. **Provenance where it is not obvious.** \"30 days\" prompts \"why 30?\". \"30 days\n   — this client's usual terms\" answers it and, more importantly, tells the\n   person when to override.\n3. **Equally easy to change.** The moment a default is harder to change than to\n   accept, it has become a decision the software made for someone.\n\n## Why it works\n\nEvery defaulted field is a decision removed from the common path and left\navailable on the rare one. That is the same economics as\n[asking for less](/patterns/minimal-form), and in fact defaulting is what makes\nthat possible — a field can leave the create form precisely because it has a\nsensible default waiting on the record.\n\nIt also improves data quality, which is the counter-intuitive part. A field\nsomeone must answer with no opinion gets a guess, and a guess looks identical to\na decision afterwards. A derived default is right more often than a distracted\nhuman, and when it is wrong it is wrong *consistently*, which is far easier to\nfind and fix than scattered guesses.\n\n## The line: never default consequence\n\nThe distinction that matters is not how confident you are — it is what happens\nif the default is wrong and nobody notices.\n\n| Safe to default | Never default |\n|---|---|\n| Today's date | An amount |\n| The account's currency | A recipient |\n| This client's usual terms | A permission or role |\n| The current user as owner | Anything that sends, charges or publishes |\n| Last used value | A destructive option |\n\nA pre-filled amount that is wrong looks exactly like an amount someone chose.\nThat is the failure this rule exists to prevent.\n\n## Getting it wrong\n\n- **Placeholders as defaults**, so the field submits empty.\n- **Defaults with no provenance**, which people either trust blindly or\n  distrust entirely.\n- **A default nobody can change** without leaving the screen.\n- **Guessing when you do not know.** An empty field says \"you decide\"; a wrong\n  default says \"this is decided\", and the second is much harder to catch.\n- **Stale derivation** — defaulting from a value that changed, so the record\n  quietly disagrees with its own source.\n- **Defaulting the dangerous thing** because it saved a click in a demo.\n\n## Exemplars\n\n**Stripe's invoice defaults** derive terms, currency and tax treatment from the\ncustomer record, and show which are inherited — so the exception is visible\nrather than buried.\n\n**Calendar applications** default the date and time from where you clicked and\nthe duration from your last event, which is why creating an event is one field\nof typing.\n\n**Expense tools** are the instructive counter-example: they will happily default\nthe category and the project, and never the amount — because a wrong amount is\nindistinguishable from a decision, and that is exactly the line.\n\nThe extractable rule: **default the answer, never the consequence.** If getting\nit wrong would be invisible and costly, leave it blank and let a person decide.\n"}