Anatomy
BEFORE (14 fields) AFTER (2 fields)
┌──────────────────┐ ┌──────────────────┐
│ Client * │ │ Client * │
│ Reference │ │ Amount * │
│ Issue date │ │ │
│ Due date │ ───▶ │ [ Create invoice ]
│ Terms │ └──────────────────┘
│ Tax rate │ ↓ lands on the record,
│ Currency │ where the other 12 live
│ …8 more │ with sensible defaults
└──────────────────┘
The discipline is one question per field: can this be answered better later?
- Issue date defaults to today.
- Terms default to the client's usual terms.
- Reference is often not known until the client sends a PO.
- Tax rate is derived.
Twelve fields, and none of them needed a decision at this moment.
Why it works
It moves each question to the moment when the answer is knowable. A field asked too early does not just cost time — it produces a worse answer, because the person guesses rather than knows, and a guessed value is harder to fix than an empty one because it looks decided.
It also changes what creation means. A short form makes the record cheap to create, so people create records at the moment the real-world thing happens rather than batching it for later. That is usually a bigger data-quality win than any amount of validation.
Where the fields go instead
Removing a field is not the same as deleting it. Every one needs a home:
| Fate | When |
|---|---|
| On the record | It matters, but any time after creation is fine |
| At the step where it matters | Ask for the PO number when raising the invoice, not when creating it |
| A default | There is an obviously right value nine times in ten |
| Derived | The system can compute it |
| Deleted | Nobody has read it in a year — check before assuming otherwise |
If a field has no home, that is worth knowing: it may not be a real requirement.
Getting it wrong
- An "Advanced" section on the same form. The twenty decisions are still present, now with an extra click and an implication that you are skipping something.
- Removing a field with no plan for it, so the data is simply never collected and someone discovers that at month end.
- Landing on a list after creation, so the person has to find the thing they just made in order to continue.
- Requiring what could be defaulted, which is the most common single cause of long forms.
- Clearing the form on a validation error, which is unforgivable at any length.
Exemplars
Linear's issue creation is a title and nothing else required. Everything else — assignee, estimate, project, labels — is set on the issue afterwards, in the view where the context exists.
Stripe's customer object can be created with an email alone, which is what makes it practical to create customers at the moment of first contact rather than after a data-gathering exercise.
Google Calendar's quick event takes a title and a time, and expands to the full form only if you ask. The full form still exists; it is simply not the default.
The extractable rule: every required field is a bet that the person can answer it now. Count the fields on your create form and ask how many of those bets you would actually take.