"An efficient system minimizes the amount of user input while maximizing the amount of automated output."

Every field on a form is a bill somebody else pays.

That is easy to say and hard to feel until you watch the person paying it. A customer calls because something is wrong with what they bought. They are not delighted. Before anybody can help them, a form wants to know who they are, where the building is, which unit, when it was installed, what the problem is, and who to call back. Six questions, each of them reasonable, each of them necessary to somebody downstream, and every one of them asked of a person whose entire interest is in being finished with this phone call.

Two of those six do not have to be asked at all. If the caller's number is known, the account is known. If the account is known, the buildings are known, and if there is only one, the building is known. The form can arrive with two fields already filled and four to go, and the person on the phone experiences that as competence.

Two more of them can be narrowed rather than asked open. Which unit becomes a list of the units at that building instead of a blank box that will receive whatever the caller happens to call it.

That is the rule working, and it works. Fewer questions, faster call, better data, because a selection from a list of real units is worth more than a phrase somebody typed.

Now here is the version that taught me the rest of this chapter. The caller's number matched an account, and it was the wrong account, because the number belonged to a general contractor who works for several of our customers. The form arrived pre-filled with a building nobody on the call was talking about. The person taking the call did not notice, because the field was already filled and filled fields are not read. The request went to the wrong place and sat there for nine days.

Nobody made an error. Somebody accepted a default, which is not an error, which is precisely the problem. The system minimized user input. It also minimized user attention, on the same stroke, and those are not the same thing and I had been treating them as one.

Stated as a rule:

The variables are the facts a system needs and where each one comes from. A fact is either supplied by a person or derived by the system from something it already has. Every fact is one or the other, and an efficient system minimizes the amount of user input while maximizing the amount of automated output says to move as many as possible from the first column to the second.

The quantity minimized is the number of things a person must know, remember, and type correctly. Not the number of fields on the screen. The number of separate acts of recall.

The quantity maximized is derivation: facts computed from other facts rather than collected twice. If the system knows the account and the account knows the buildings, then asking for the building is asking a person to repeat something already recorded, which is the same defect as storing it twice.

The failure signal is a person retyping something the system already has, and its uglier twin, a person accepting a derived value without checking it.

The domain of validity is where derivation is reliable and where its errors are visible. Both conditions, not one.

The word efficient is the one hiding the problem. Efficiency for whom, measured how? The original sentence prices the user's effort and prices nothing else. It does not price the user's attention, the system's confidence in things it inferred, or the cost of an error that no longer has a human being standing in front of it.

The constructive case draws on three separate traditions that all arrive at the same instruction.

The first is error-proofing, which the Toyota tradition calls poka-yoke. The principle is that the best way to prevent a mistake is to make it physically impossible rather than to ask people to be careful. A connector that only fits one way. A fixture that will not close if the part is backwards. A count that will not complete if a piece is left in the tray. Every one of those removes a class of error by removing a choice, and the reason it works is that it does not depend on anybody's diligence, including on a bad day.

Read against the rule, error-proofing is the same move with a different motive. Removing an input removes the error that input could carry.

The second tradition is cognitive load. John Sweller's work established that working memory is sharply limited and that anything occupying it which is not the task itself is taxing the same narrow resource the task needs. A form is a working-memory device. Every field a person has to interpret, every value they have to go find, every ambiguity they have to resolve, is spending capacity that is not then available for the thing the form is about, which is usually a problem somebody needs solved.

That reframes the claim usefully. Minimizing user input is not about saving keystrokes. Keystrokes are cheap. It is about not consuming the user's thinking on the interface, so that it can be spent on the situation.

The third is James Reason's taxonomy of error, which sorts errors into the ones design can remove and the ones it cannot. He separates execution failures from planning failures. A slip is when a step of the plan is carried out incorrectly: the right intention, the wrong action, like selecting the wrong item from a list. A lapse is when a step is omitted or forgotten. Both of those are execution failures, and both are exactly what removing an input removes. A field you do not have to fill is a field you cannot slip on or forget.

Mistakes are different. A mistake is a planning failure: the action was performed correctly and the plan was wrong, from missing knowledge or a misapplied rule. Removing inputs does nothing about mistakes, and it may make them worse, because a person doing less is a person with less contact with the situation they are supposed to be forming a plan about.

That distinction is the hinge of this chapter. Minimize the amount of user input is an excellent instrument against slips and lapses and has no purchase on mistakes.

And underneath all three sits Ashby's requisite variety, which appeared two chapters ago and applies here in a harsher form. A regulator needs at least as many distinct states as the situations it must handle. An automated derivation is a regulator. If it can produce four answers and the world produces twelve situations, it will answer eight of them with something built for a different case, confidently, and its confidence will be indistinguishable from correctness.

The evidence for reducing inputs is good where the outcome is a slip and much thinner where the outcome is a decision.

Error-proofing has a long industrial record and the mechanism is not mysterious: a thing that cannot be done wrong is not done wrong. Form design has a similarly consistent record on completion and accuracy. Shorter forms get finished more often. Fields with constrained choices produce cleaner data than free text. Values pre-filled from a reliable source are more accurate than values retyped. None of this is controversial.

The trouble is that all of it measures the same class of outcome, which is whether the artifact came out clean, and none of it measures whether the resulting decision was right.

Two specific effects run the other way and both are well documented enough to take seriously.

Automation bias is the tendency to accept what an automated system offers, including when the available evidence contradicts it. It has been studied most in aviation and in clinical decision support, and it shows up in two forms: acting on a bad recommendation, and failing to act because the system did not prompt. The second is harder to see and probably more common.

Default effects are the quieter version. A pre-filled value is accepted far more often than the same value would be chosen from empty, and this holds whether the default is good or bad. The design literature treats this as a feature, because it is: a good default is the cheapest usability win available. It is also exactly the mechanism that put a request in the wrong building for nine days, and the same property produces both results.

What I could not find, and want to be honest about, is any study weighing these against each other in the setting I actually work in. The evidence that reducing inputs improves data quality is solid. The evidence that automation bias and default acceptance degrade decisions is solid. Nobody has told me the exchange rate, and I make that trade constantly.

The design problem that priced it for me was identity resolution on an intake form.

The task: a request arrives, and the system should figure out who it is from and what it concerns without asking. Every fact it derives correctly is a question not asked of somebody who did not want to be on the phone.

The first version derived aggressively. Phone number to account, account to building, building to units, most recent installation to warranty status. On the common case it was excellent. The form came up mostly filled, the call got shorter, the data got cleaner.

What the first version did not have was any representation of its own uncertainty. A match was a match. The general contractor whose number touches four customers produced a match, and the match was presented identically to a match that could only have been one thing.

The second version separated confidence from content, and that turned out to be the whole design. A derived value arrives in one of three states. Certain, meaning only one thing in the world satisfies the lookup, in which case it is filled and not raised. Probable, meaning a most-likely answer exists and alternatives do too, in which case it is filled and visibly marked as an inference with the alternatives one click away. Ambiguous, meaning several candidates are roughly equal, in which case nothing is filled and the person is asked, with the candidates listed.

That third state is the one the rule argues against and the one that makes the system trustworthy. It is an input that did not have to exist. It exists because the alternative is a system that is silently wrong in a fixed percentage of cases, and a person who has stopped reading filled fields because filled fields have always been right.

The other thing that changed was logging. Every derivation records what it inferred and from what, so that when something lands in the wrong place it is possible to ask whether the system guessed or a person chose. Before that, a wrong building looked like somebody's data entry error, and it was investigated as one, which is how a systematic defect stayed invisible for months.

That last point generalizes past this design and it is the one I would keep. Automation changes who is responsible for an error without changing who appears to be. The inference was made by a rule somebody wrote months ago; the name attached to the record belongs to whoever accepted it on a Tuesday. Every investigation starts from the name on the record. So the person gets coached, the rule stays, and the same failure recurs with a different name attached until somebody happens to see the pattern, which requires several instances side by side, which nobody assembles because each one was closed as a training issue.

The log is what makes that visible, and it costs almost nothing to build and is almost never built, because at design time nobody is imagining the investigation. The version of this that I would now insist on is narrow: any field the system fills in on a person's behalf records its source, and any report of an error on that field shows the source next to the name.

The boundary is reliability and visibility, and both conditions have to hold.

Derivation is safe where the inference is sound and where its errors announce themselves. A postal code deriving a city is sound and its errors are visible, because a wrong city is obvious to anyone reading. A phone number deriving a customer is unsound in a specific population and its errors are invisible, because a wrong customer looks exactly like a right one.

The dangerous quadrant is a derivation that is usually right and whose errors are silent. It is more dangerous than one that is often wrong, because frequent errors train people to check and rare ones train them not to. A system that is right ninety-nine percent of the time and gives no signal on the other one percent will have its hundredth case accepted without examination, and the acceptance is the correct behavior given everything the user has experienced.

The second boundary is the mistake class from earlier. Where the human's job is judgment rather than transcription, removing inputs removes their contact with the material the judgment needs. A claims adjuster shown a pre-computed recommendation and asked to approve it is not doing the job the pre-computation was meant to support. They are doing a different, smaller job, and the organization is getting a different, smaller thing while its metrics improve.

Three things this rule cannot see.

It cannot see the difference between input that is friction and input that is contact. Both look like a field on a form. The first is a tax and should be removed. The second is the mechanism by which a person stays in touch with the situation, and removing it is not an efficiency.

Telling them apart before you remove one is the practical problem this chapter leaves hardest, and I have three tests that help and do not settle it.

Ask what the person would notice. If filling this field requires looking at the situation, and looking at the situation is how a problem would get caught, the field is contact. Reading a serial number off a unit means standing in front of the unit. Deriving that serial number from the work order is correct, cheaper, and removes the only reason anybody was going to look at the actual thing.

Ask whether the answer could be wrong in a way that matters and that the system cannot check. Where a person is transcribing something the system could verify, the input is friction: the verification makes the human step redundant. Where a person is reporting something only they can observe, the input is contact by definition, because there is no other source.

And ask what happens to the person's model if this goes away for a year. Some inputs are how somebody learns the shape of the work. A dispatcher who assigns jobs by hand builds a map of who is good at what and where they are; a dispatcher handed an optimized assignment to approve does not, and after a year cannot evaluate the optimization, which is exactly when the optimization starts being wrong without anyone noticing.

None of those tests is available as a checkbox and all three are answerable by asking the people doing the work, which is the step most automation projects skip because the answers are inconvenient. The one thing I would say with confidence is that the question has to be asked before the removal rather than after, because after the removal there is nobody left who can answer it.

It collides with the rule holding that you should not make the specific unnecessarily vague, and the collision is direct. That chapter argued for splitting a vague free-text box into the specific questions a reader will have, which adds fields. This one argues for removing fields. Both are correct and they point opposite ways at the same form. The resolution I use is that added fields must be cheap to answer, which means chosen rather than typed and derived where possible, so that specificity rises while effort does not. That works most of the time and it is not a principle, it is a technique.

And it collides with the push ism from the last chapter, because automated output is push. Maximizing automated output means generating more material aimed at people, and the previous chapter established that every unit of that spends a budget nobody is counting. An efficient system by the original's definition can be a system that has moved work off its users and onto their attention, and reported the first without measuring the second.

Here is the case against, and it was made in 1983 by somebody watching this go wrong in control rooms.

Lisanne Bainbridge's argument starts with the designer's own attitude, which she states plainly: the designer's view of the human operator is that the operator is unreliable and inefficient, so should be eliminated from the system, but the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate.

Read that twice. The tasks left to the person are not a random remainder. They are precisely the tasks that resisted automation, which is to say the hardest ones, and they are now being performed by somebody whose remaining role consists entirely of hard cases with nothing easy in between.

From there the ironies compound, and each one lands on the sentence.

The operator's job becomes monitoring, and people are poor at sustained vigilance on a system that almost never needs them. That is not a training problem or a discipline problem; it is a documented property of human attention. A person asked to watch something that is right ninety-nine point nine percent of the time will not catch the exception, and the design assumed they would.

Manual skill degrades when it is not exercised. The operator is expected to take over when the automation cannot cope, which is the worst moment available, requiring the best version of a skill that has been unused for months. Bainbridge's conclusion is that automation increases rather than decreases the training the operator needs, which is the reverse of what every business case for automation says.

And the operator needs a working mental model of the process to intervene at all, and that model was built, in the pre-automation world, by operating the process. Remove the operating and the model does not form. The next generation of operators never had the hands-on period their predecessors were quietly relying on.

Put my sentence next to that. An efficient system minimizes the amount of user input while maximizing the amount of automated output. Every clause of it is an instruction to build the system Bainbridge is describing. Minimize the input, which removes the practice. Maximize the automated output, which converts the person into a monitor. Call the result efficient, which is true on the measures the design was evaluated on and false on the bad day.

The strongest form: an efficient system minimizes the amount of user input while maximizing the amount of automated output describes a system that is efficient in its normal state and defenseless in its abnormal one, and it has no term for the difference, because the abnormal state is where the person was supposed to be and the person is the thing being minimized.

Bainbridge's ironies are right, and the rule needs a term it does not have.

The distinction that saves it is between input and contact. An input is a fact the system needs, which a person happens to be supplying, and which they are supplying because nobody built the derivation. That is pure cost and should go. Contact is a person's engagement with the situation, and some of it happens to arrive through the same channel. Removing an input removes both, and the original only ever priced the first.

So the rule gains a second clause, and it is a constraint rather than a goal. Minimize user input, subject to preserving enough contact that the person can still form a model of what is happening and still exercise the judgment they will be asked for when the system cannot cope.

In practice that has produced three rules I would defend.

Derive the facts, expose the reasoning. A person who sees this is unit 4B because you called from the number on file for that building has been given both the answer and the material to catch it being wrong, at a cost of one line. A pre-filled field with no provenance is an assertion; a pre-filled field with its derivation visible is evidence, and people check evidence.

Never hide uncertainty behind a default. The three-state design above is the operational form of this. If the system is guessing, it says so, and the cases where it cannot choose are handed back even though handing back is an input.

And keep the person in the loop the automation cannot handle, on purpose and on a schedule, before the day it matters. Bainbridge's skill problem has no clever fix. The only answers anyone has are practice and exposure: rotate people through the manual path occasionally, review the automation's own decisions in batches, do something that keeps the model alive. It is an ongoing cost and it is the price of the efficiency, and a business case that does not carry it is not a complete business case.

One more consequence, because it changes what the rule costs rather than what it says. Every derivation is a rule, and a rule that runs unattended is a rule nobody re-reads. The identity resolution described earlier was written against how phone numbers mapped to accounts in a particular year, and that mapping changes: customers consolidate, contractors get absorbed, numbers move. The derivation does not know any of this happened. It keeps producing answers at the same rate and confidence it always did, and its accuracy declines without any signal at all, because a derivation has no way to be surprised.

Which is the fourth time this book has arrived at the same hole. A definition goes stale, a formula outlives its purpose, a standard drifts, and now a derivation decays, and in every case the instrument that would detect it is the one thing the automation removed, which is a person having to look. The only partial answer I have is to sample: pull a handful of derived values a month and check them against the world by hand. It is deliberately manual, it is exactly the kind of work minimize the amount of user input says to eliminate, and it is the price of being allowed to trust the rest.

Where I will not give ground: the alternative is not a world of skilled operators. The alternative is a form with eleven fields, filled wrong by a person who has been asked to retype what the system already knows, with the errors spread invisibly through everything downstream. Bainbridge is describing the failure mode of good automation, and it is a real failure mode with real casualties, and it is still better than the failure mode of no automation. The correct response to her argument is to design for the bad day rather than to stop automating.

What survives:

The original counted the user's effort and nothing else. The revision counts three more things: the attention that a filled field stops receiving, the model that stops forming when the practice stops, and the difference between a derivation that is sound and one that is merely usually right.

Three things go forward. The exchange rate between input reduction and automation bias is unmeasured and I trade on it constantly. The collision with the specificity ism is handled by technique rather than principle, and Chapter 16 has both now. And Bainbridge's skill problem is answered with a cost rather than a solution, which means the honest version of this rule includes a line item most people will not fund.