---
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.

  - Derive each default from context you already have: the current user, the
    selected client, today's date, the account settings, or the value used last
    time for this kind of record.
  - Show the default as a real, editable value — never as greyed-out placeholder
    text that vanishes and leaves an empty required field.
  - Say where a non-obvious default came from, briefly, next to the field:
    "30 days — this client's usual terms".
  - Make changing it exactly as easy as accepting it. A default must never be a
    lock.
  - Never default a field whose wrong value would be harmful or hard to notice —
    amounts, recipients, permissions, anything that sends or charges.
  - When you cannot pick a good default, leave it empty rather than guessing.
    A confidently wrong default is worse than a blank, because it looks decided.
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.
---

## Anatomy

```
  Issue date     [ 6 Sep 2026            ]  today
  Payment terms  [ 30 days               ]  Riverside's usual terms
  Currency       [ USD                   ]  account default
  Owner          [ Dana Whitfield        ]  you
  Amount         [                       ]  ← deliberately NOT defaulted
                                              wrong value here is harmful
```

Three properties:

1. **Real values, not placeholders.** A grey hint that disappears on focus is
   not a default — it is an empty required field wearing a disguise.
2. **Provenance where it is not obvious.** "30 days" prompts "why 30?". "30 days
   — this client's usual terms" answers it and, more importantly, tells the
   person when to override.
3. **Equally easy to change.** The moment a default is harder to change than to
   accept, it has become a decision the software made for someone.

## Why it works

Every defaulted field is a decision removed from the common path and left
available on the rare one. That is the same economics as
[asking for less](/patterns/minimal-form), and in fact defaulting is what makes
that possible — a field can leave the create form precisely because it has a
sensible default waiting on the record.

It also improves data quality, which is the counter-intuitive part. A field
someone must answer with no opinion gets a guess, and a guess looks identical to
a decision afterwards. A derived default is right more often than a distracted
human, and when it is wrong it is wrong *consistently*, which is far easier to
find and fix than scattered guesses.

## The line: never default consequence

The distinction that matters is not how confident you are — it is what happens
if the default is wrong and nobody notices.

| Safe to default | Never default |
|---|---|
| Today's date | An amount |
| The account's currency | A recipient |
| This client's usual terms | A permission or role |
| The current user as owner | Anything that sends, charges or publishes |
| Last used value | A destructive option |

A pre-filled amount that is wrong looks exactly like an amount someone chose.
That is the failure this rule exists to prevent.

## Getting it wrong

- **Placeholders as defaults**, so the field submits empty.
- **Defaults with no provenance**, which people either trust blindly or
  distrust entirely.
- **A default nobody can change** without leaving the screen.
- **Guessing when you do not know.** An empty field says "you decide"; a wrong
  default says "this is decided", and the second is much harder to catch.
- **Stale derivation** — defaulting from a value that changed, so the record
  quietly disagrees with its own source.
- **Defaulting the dangerous thing** because it saved a click in a demo.

## Exemplars

**Stripe's invoice defaults** derive terms, currency and tax treatment from the
customer record, and show which are inherited — so the exception is visible
rather than buried.

**Calendar applications** default the date and time from where you clicked and
the duration from your last event, which is why creating an event is one field
of typing.

**Expense tools** are the instructive counter-example: they will happily default
the category and the project, and never the amount — because a wrong amount is
indistinguishable from a decision, and that is exactly the line.

The extractable rule: **default the answer, never the consequence.** If getting
it wrong would be invisible and costly, leave it blank and let a person decide.