---
title: Minimal Form
slug: minimal-form
kind: pattern
summary: Ask only for what is needed to create the thing, and collect everything else later in the context where it matters.
problem: >-
  A create form asks for every field the model has, because the model has them.
  The person faces twenty decisions before they have seen any value, and most of
  those decisions cannot be made well yet — so they guess, or abandon.
family: [capture]
data_shape: [record]
principles: [friction, progressive-disclosure]
interaction: [editing]
density: low
complexity: low
status: stable
visibility: public
use_when:
  - Creating a record is the start of working with it, not the end.
  - Most fields become obvious later, in a context the form does not have.
  - You want people to actually create things rather than plan them.
avoid_when:
  - The record is invalid or dangerous when incomplete — a payment, a contract, a booking.
  - A regulator or an external system requires completeness at creation.
  - The information is only available now, from a person who will not be back.
alternatives:
  - slug: wizard
    when: All the information really is required, and the honest fix is to sequence it rather than shorten it.
  - slug: quick-add
    when: Even a short form is too much and creation should happen inline, from one field.
ask_leo: |
  Cut this create form down to the minimum.

  - Keep only the fields without which the record cannot exist or be found again
    — usually a name, and sometimes one relationship. Everything else moves off
    this form.
  - For each removed field, decide where it WILL be asked: on the record after
    creation, at the step where it first matters, or never, because a default is
    fine.
  - Give the remaining fields real defaults where a sensible one exists, and let
    people change them later.
  - Label the button with the outcome — "Create invoice", not "Submit".
  - After creating, land the person on the new record ready to continue, not
    back on a list. Creation is the start of the work.
  - Do not hide the removed fields behind an "Advanced" toggle on the same form.
    That is the same twenty decisions with an extra click.
  - Validate on the way out of each field, not only on submit, and never clear
    what someone typed because of a validation error.
related:
  - title: Eliminating friction
    url: /patterns/friction
    summary: The principle — ask for less up front, and defer what context will answer later.
  - title: Wizard
    url: /patterns/wizard
    summary: What to build when the information genuinely is all required.
---

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