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:
- Real values, not placeholders. A grey hint that disappears on focus is not a default — it is an empty required field wearing a disguise.
- 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.
- 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, 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.