Prefilled form fields make people agree to things they never read

The show director approves the 2027 brief in nine minutes. She is thorough, she has run the event for six years, and when the audit trail is pulled later it shows she opened the document, scrolled to the bottom, changed two words in deliverables, and clicked approve.

Thirty nine of the forty one fields were untouched. Nineteen of those thirty nine had arrived prefilled from the 2026 edition. Nobody was careless. Prefilled form fields produce exactly this outcome in every organisation that uses them, and the effect is well enough documented outside our industry that it should be treated as a design property rather than a people problem.

A default is a decision somebody else already made

Every prefilled field carries an implicit claim: this answer is fine, and if you disagree, do something about it.

That asymmetry is the entire mechanism. Accepting a default costs nothing. Changing it costs attention, a judgement, and sometimes a conversation with the person who set it. Faced with forty one fields and nine minutes, a reviewer spends the attention where something looks wrong, and a plausible sentence from last year does not look wrong. It looks finished.

The same asymmetry appears wherever defaults exist, at magnitudes that surprise people the first time they see them.

What the organ donation numbers actually show

Eric Johnson and Daniel Goldstein published a short paper in Science in 2003 titled "Do Defaults Save Lives?". Their online experiment asked people whether they would be an organ donor, with three versions of the same question. Under an opt in default, where the starting position was not a donor, about 42 per cent agreed. Under an opt out default, where the starting position was donor, about 82 per cent agreed.

Same question. Same population. The agreement rate roughly doubled on the basis of which box arrived ticked.

They paired that with cross country data on effective consent rates, where nations running opt in systems sat in the low tens of per cent while nations running opt out systems sat close to universal. The country comparison carries confounds, and the authors were careful about them. The experiment does not, and the experiment is the part that transfers to a brief template, because it holds everything constant except the starting state of the field.

Now apply that to a document where the fields hold positioning, target audience and the single success measure for a show with a seven figure production budget. A mechanism that moves organ donation consent by forty points is being used, unintentionally, to set the strategy of the 2027 edition.

Measuring the default effect on your own briefs

You do not have to take the analogy on faith. The measurement runs on data most brief systems already store.

Take twelve briefs from the last four quarters. Each has 41 fields, so 492 field instances in total. Classify each instance by whether it arrived prefilled or empty, then count how many were changed between the brief opening for review and the approval.

In the portfolio I am describing, 318 of the 492 instances arrived prefilled and 174 arrived empty. Of the 318 prefilled, 47 were edited before approval, which is 14.8 per cent. Of the 174 empty, 151 were filled, which is 86.8 per cent.

So a field arriving empty gets an answer nearly six times as often as a field arriving full gets a change. Nothing about the questions differed. The only variable is whether somebody had to act to leave the field alone.

Then do the qualitative half, which takes fifteen minutes and lands harder than the arithmetic. Print the 271 prefilled fields that were never edited, pick the ten that carry decisions, and read them aloud in the next review. In this exercise four of them described an audience segment the portfolio had stopped selling to eighteen months earlier, and all four had been approved twice.

Two things about that 14.8 per cent are worth holding separately. It is not a measure of how often the prefilled values were wrong, since most of them were facts and most facts were correct. It is a measure of how often anybody checked. Those two quantities look identical in a system that records only the approval, which is precisely why the edit event has to be stored as its own fact.

If your platform does not log edits at field level, a cruder version works. Diff the brief at review open against the brief at approval and count changed characters. A brief that gained fewer than a hundred characters across a two week review window had one reader making small corrections, whatever the sign off block says about the six people who approved it.

Why does nobody edit a field that is already full?

Three reasons stack, and only one of them is about laziness.

The first is the cost asymmetry already described. Leaving it costs zero keystrokes.

The second is that a full field reads as somebody else's work. There is a strong social signal in finished prose: it implies an author, and overwriting another person's sentence feels like a bigger act than writing your own into a gap. Where the prefilled text came from a previous edition, that implied author may be the reviewer herself, twelve months ago, which is roughly the hardest person to contradict.

The third is that reviewers are looking for errors, and a prefilled decision field contains no error. It is fluent, internally consistent, and describes a real thing. Its defect is that it describes last year, which is invisible on the page. This is why review checklists that ask "is anything wrong?" catch nothing here, and why the useful question is "was this decided this cycle?".

The legal version of the same finding

Regulators reached the same conclusion from a different direction, and their reasoning is worth borrowing because it is unusually clean.

The Court of Justice of the European Union held in Planet49, Case C-673/17, decided on 1 October 2019, that consent is not validly given by a pre ticked checkbox which the user must deselect to refuse. The court's reasoning was about action: consent has to be an active, unambiguous indication, and inaction cannot supply it. A user who left the box alone may have read it and agreed, or may never have seen it, and the design makes those two states indistinguishable.

That last sentence is the one to keep. A prefilled brief field that survives review is in exactly the same position. It might have been read, considered and endorsed. It might have been scrolled past. The system recorded an approval either way and stored no evidence about which happened.

Nobody is claiming a brief template is subject to data protection law. The design principle stands on its own: where you need evidence that somebody decided something, an unchanged default is not that evidence, and building a workflow that treats it as such is a choice with consequences you can measure.

What should a brief prefill and what should it leave empty?

Prefill facts. Leave decisions empty.

Venue, hall, dates, capacity, prior registrations, prior exhibitor count, the mandatory legal line, brand asset locations, the budget envelope. All of these have a correct value that exists somewhere else, and typing them by hand introduces errors that prefilling removes. Prefill them, and where possible pull them from the system of record with the source shown beside the value.

Positioning, audience, the single success measure, non goals, tone. These arrive empty, every cycle, with the previous edition's answer visible somewhere the reviewer can see it and cannot approve it. A side panel showing "2026 said: ..." gives the reviewer the benefit of continuity and still requires an action to adopt it. That single design change converts an implicit acceptance into an explicit one, and the audit trail then records something real.

Two implementation details make the difference between this working and not. The old value has to be visible, otherwise teams retype from memory and the brief gets worse. And the empty field has to block approval, because a field that can be left blank will be, which turns the whole scheme into a slower version of the same problem. Where the prior text is carried across wholesale, the mechanics of marking it as inherited belong with the roll over problem.

Where this stops

Emptying the decision fields raises the cost of every cycle, and that cost is real. Five decision fields, written properly, is perhaps forty minutes of somebody's genuine attention per edition, times eight editions, times however many revisions. Teams under pressure will fill them with something to clear the block, and a field filled to clear a block is worse than a prefilled one, because it looks like this year's thinking and is not even last year's.

The defence against that is not more process. It is keeping the number of empty decision fields small enough that filling them honestly is achievable in the time available, which is the argument for five and against twelve.

The second limit is that this only works if the system knows which fields are decisions. That classification is a human judgement, it drifts as a portfolio changes, and a field mis tagged as a fact will be prefilled for ever without anybody noticing. Recording who tagged it and when is a provenance problem, and the same infrastructure that answers it also tells you whether a value was typed, inherited or generated, which matters even more once machine written text enters the approval path. A brief and review workspace of the kind described on the publishing engine page is where that state has to live, since a document format has nowhere to put it.

This week, open the last brief your team approved and count two numbers: how many fields it has, and how many were edited between the review opening and the approval. If the second number is under a fifth of the first, read the untouched decision fields out loud to the person who approved them.