10. What Does Free Will Have to Do with System Design?

The Problem: Who Pressed the Button?

At two in the morning, a red warning appears on the operations dashboard. The server’s response time is rising sharply. The on-call operator stares at the screen with tired eyes. Beside it is a button labeled Run automatic recovery. In small type beneath the button, it says, “Rolls back to the most recently deployed version.” A moment later, the operator presses it. The service comes back, but some of the order data accumulated over the previous several hours disappears.

During the postmortem, someone asks, “Why did you approve the rollback?” The question naturally turns toward the operator’s decision. But did that decision truly come from the individual’s free will? There was only one button. The risk was not visible. The time pressure was intense. And the organization had long treated people who ended incidents quickly as competent. The operator made a choice, but the system had already narrowed the space in which a choice could be made.

Free will is often treated as some independent power located inside the mind. In engineering practice, however, free will appears as a much more concrete set of questions. Could the user genuinely have chosen otherwise? Could they understand the consequences of the choice? Were they allowed not to choose? Could they undo their choice? Does the system support the user’s action, or push them toward a particular action?

The Philosophical Question: Choice Does Not Come from the Number of Options Alone

Having ten options does not make a person free. Some options are hidden deep inside the interface. Others are exaggerated through color and placement. Some are already selected as defaults. A user may have clicked “Agree,” but the system may have been designed to make agreement the only practical option because the cost of refusing was too high.

Translated into the language of design, free will is not reduced to the slogan “Give users control.” Control is constituted together with information, time, comprehensibility, and reversibility. Suppose a recommendation system automatically plays one video after another. The user did not actively choose the next video, but doing nothing is interpreted as approval for the next playback. Here, the default is not a neutral blank space. It is an active design decision about the direction in which the user’s time will flow.

Engineers often view systems through the lens of efficiency. Reduce the number of clicks, lower churn, shorten processing time. But fewer clicks may mean less burden for the user—or it may mean that the user has lost the time to think. Autocomplete reduces typos, but there are moments when the suggested sentence becomes the user’s words. A work-breakdown tool divides a complex project into small tickets, but it can also flatten the question of what should be built until that question fits the ticket format.

Philosophy stops and questions the assumptions that otherwise seem obvious: “A faster choice is a better choice.” “The more options there are, the freer the user is.” “The user pressed the button, so they consented.” Engineering must translate that doubt back into structure. This might mean adding intentional delays to dangerous operations, requiring users to confirm important defaults themselves, and clearly distinguishing a recommendation from the user’s final decision.

An Engineering Case: Designing a Little Friction between Recommendation and Automation

Suppose a financial service automatically recommends a borrowing limit. Based on the user’s income and transaction history, the model calculates the “maximum amount available.” A large number appears first on the screen, followed by the explanation, “If you choose this amount, your monthly repayment will be this much.” Most users will naturally begin thinking from the most prominent number. A better design would give equal weight to the maximum amount, the repayment burden, the possibility of interest-rate changes, and the basis for the recommendation. Even adding a line before the application button—“This recommendation was calculated automatically; the final decision is yours”—may not be enough. The system may need a short question to confirm that the user understands, a grace period during which the application can be canceled, and a path to speak with an advisor.

The same applies to incident-response systems. Rather than always executing automatic recovery as quickly as possible, the system could require two approvals when data loss is possible, or switch first to a read-only mode. An emergency does not always make removing human judgment the best option. Separating moments that require judgment from moments that can safely be automated may actually preserve people’s capacity to choose.

Such design can look inefficient. If every user must read warnings and confirm every decision, the service becomes slower. But freedom is not always a state without friction. A brake slows a car, but because of it the driver can choose the speed. Friction in a system works the same way. Well-placed friction is not a wall obstructing action; it can be a handle that returns meaning to the action.

Counterargument and Tension: Can We Protect Users Forever?

Of course, leaving every judgment to the user cannot always be called responsible design. In areas such as air-traffic control, medical alerts, and fire response, where reaction time is directly tied to life and death, automation can be faster and more accurate than people. Requiring confirmation every time may exhaust human attention and bury important warnings among ordinary pop-ups.

The issue, then, is not that a human must always press the final button. More important is that automation must not conceal the fact that it is replacing human judgment. The system should explain under what conditions it acts on its own, whether the user can intervene, and what will happen if the user does not intervene. Free will is not the right to manipulate everything personally. It is the ability to understand the connection between one’s actions and their consequences, and to change direction when necessary.

A Question to End With

In the system you designed, is the button the user pressed really their choice? Or was it the result of pressing the most brightly lit button, the predetermined default, and the pressure of having no time—all at once? When you build the next feature, does increasing the user’s freedom mean adding one more option, or does it mean creating room not to choose and time to go back?