The production admin screen looked almost the same as the staging one. Same table, same filters, same blue primary button. The only difference was a small environment label in the corner. Late in the afternoon, after several support interruptions, someone ran an action in the wrong place. The incident report could have said “operator error.” It would not have been completely false, but it would have been too small.
The Design of Everyday Things keeps returning to this point: people make errors, but errors rarely belong only to the person. They happen inside systems of cues, constraints, habits, interruptions, pressure, and recovery paths. If the system quietly invites the wrong action, then “be more careful” is not enough of a fix.
This article is a second reflection from Don Norman’s The Design of Everyday Things, focused on human error, constraints, forcing functions, checklists, root-cause thinking, and human-centered design. It should be read as a product and engineering reflection, not a full summary of the book.
Start with the system, not with blame
One phrase that often hides learning is “human error.” It can be true at the surface and still unhelpful. A person clicked the wrong button, entered the wrong amount, skipped a step, or misunderstood a message. But the more useful question is: why did that action make sense to them at that moment?
Maybe the button looked like the safe path. Maybe two actions were placed too close together. Maybe the warning appeared so often that everyone learned to dismiss it. Maybe the user was interrupted in the middle of a multi-step task and the system gave no way to recover context. Maybe the rule was correct on normal days but dangerous in an emergency.
This is not about removing responsibility. It is about finding the level where improvement is possible. Telling one person to be more careful may help one afternoon. Changing the workflow, state, copy, constraints, and recovery path can help every future user.
In the production-versus-staging example, a system fix could be concrete: keep production on a separate route, make the environment name part of the page title and button label, default risky tools to staging, require a short production lock before destructive actions, and show a preview of the exact records affected. None of those changes depends on one tired person having perfect attention at 5:40 p.m.
Slips and mistakes need different design
Norman distinguishes slips from mistakes. A slip happens when the goal is right but the action goes wrong. A mistake happens when the goal or plan is wrong from the start. Software teams need this distinction because the fixes are different.
A slip may be a support agent intending to refund $10 but typing $100, or an engineer intending to deploy staging but choosing production from a similar dropdown. The design response is usually about constraints, visibility, spacing, confirmation with meaningful detail, undo, defaults, and separating risky actions.
A mistake may be a product manager choosing the wrong metric because the dashboard’s model is unclear, or a finance user applying a normal refund process to a fraud case where the rule should be different. The design response is more about conceptual model, examples, decision support, training material inside the flow, and making exceptions visible.
| Error type | Office or product example | Better design response |
|---|---|---|
| Slip | User clicks “archive” while intending to click “open” because actions sit side by side. | Separate risky actions, add undo, improve spacing and visual hierarchy. |
| Slip | Engineer deploys the right branch to the wrong environment. | Make environment visually distinct, require version review, use lockout for production. |
| Mistake | Manager reads “active users” as paying customers because the dashboard term is ambiguous. | Define terms near the chart, show metric lineage, link to examples. |
| Mistake | Support applies the normal refund flow to a chargeback case. | Detect special cases, explain rule differences, route to a safer workflow. |
If the team treats every error the same way, it reaches for the same tool every time: a confirmation dialog. That is rarely enough. A confirmation that says “Are you sure?” can become background noise. A better confirmation says exactly what will happen, what cannot be undone, and why this action is unusual.
Constraints are kindness when they protect the work
Constraints sound restrictive, but good constraints protect people from predictable trouble. Physical design uses shape, size, and fit. Software uses validation, disabled actions, safe defaults, permissions, staged rollout, required review, rate limits, and workflow order.
A good CSV import flow is a small example. Instead of allowing upload, failing halfway, and leaving the database in a strange partial state, the system can constrain the sequence: upload, validate, map columns, preview errors, commit, then show a rollback path. The constraint is not bureaucracy. It keeps the user from discovering structural problems after the risky action has already happened.
Forcing functions are a stronger kind of constraint. A system may refuse to continue until a missing step is complete. In a medical or aviation context, that can be life-critical. In software teams, a forcing function may be more ordinary: production deploy cannot proceed while migrations are unreviewed, a payout batch cannot be approved by the same person who created it, or a feature flag cannot target all users until it has passed a smaller percentage rollout.
If a mistake is common, do not only add a warning. Ask whether the system can make the wrong action impossible, harder, more visible, reversible, or less damaging.
Undo is often better than interrogation
Many interfaces ask users to confirm destructive actions. Sometimes that is necessary. But Norman’s point about error recovery is practical: people often confirm by habit, especially when dialogs appear too often. A system that only asks “Are you sure?” may be protecting itself more than protecting the user.
Undo changes the conversation. Instead of demanding perfect attention before every action, the system accepts that ordinary people will make ordinary mistakes and gives them a way back. Moving a file to trash is safer than deleting it permanently. Archiving a customer record with restore is safer than destroying it. Saving versions of a document is safer than treating every save as a point of no return.
This matters in business tools. A merchandiser should be able to roll back a pricing change. A content editor should be able to restore a previous version. A support agent should be able to cancel a queued email before it is sent. When undo is impossible, the interface should say so clearly and slow the action down with specific review, not generic fear.
Checklists help when attention is fragile
People forget steps when they are interrupted. That is not a character flaw. It is a property of attention. Checklists are valuable because they move fragile memory into the world. They are especially useful for repeated workflows where one skipped step can create expensive cleanup.
A release checklist does not need to be theatrical. It may include migration reviewed, rollback plan tested, alert thresholds checked, support note prepared, feature flag owner named, and customer-facing copy approved. The point is not to make the team feel controlled. The point is to let tired people resume a complex workflow without reconstructing it from memory.
Digital checklists can do even more when they are connected to system state. If the migration is not reviewed, the deploy button stays locked. If the support note is missing, the launch task remains incomplete. But the checklist must stay small and real. A long checklist full of ceremonial items teaches people to click through it.
Root-cause work should keep going past the first answer
The book’s discussion of root-cause thinking connects naturally to software incidents. The first answer is usually only the nearest cause. “The user selected the wrong environment.” Why was the wrong environment easy to select? “The dropdown defaulted to production.” Why did it default that way? “The screen remembers the last used environment.” Why is that unsafe? “The same user works across production and staging during support.” Now the team is learning something useful.
Five Whys is not magic, and it can be misused if people already know whom they want to blame. But used carefully, it keeps the team from stopping at the nearest human action. It points toward system changes: defaults, permissions, visual separation, workflow order, logs, education inside the product, and recovery paths.
| Surface incident | Deeper design question | Possible system fix |
|---|---|---|
| Duplicate payment captured | Why did retry feel safe while the first request was still uncertain? | Idempotency key, visible pending state, disabled repeat action, clearer final status. |
| Wrong customer emailed | Why was recipient review weak in a high-impact workflow? | Recipient preview, segmented send, undo window, sample send before bulk action. |
| Production data changed by mistake | Why did production look and behave like staging? | Distinct environment styling, explicit lock-in, permission boundary, audit preview. |
Human-centered design is not soft work
Human-centered design can sound soft if it is reduced to empathy posters. In Norman’s book, it is much more operational. Observe real behavior, find the real problem behind the requested problem, prototype cheaply, test with people, and iterate. The point is not to make everyone happy. The point is to make the system fit human limits and real activity better.
This matters because teams are often asked to solve the wrong problem. “Add a confirmation dialog” may be the request. The real problem may be that the workflow makes two dangerous actions look equal. “Add a training page” may be the request. The real problem may be that the product uses three different words for the same concept. “Add more dashboard filters” may be the request. The real problem may be that the decision itself is unclear.
A small prototype can reveal this faster than a long argument. Put the risky workflow in front of five users, ask them to do the task, and watch where they hesitate. The team may learn that the missing piece is not a feature at all. It may be a state label, a preview, a safer default, or a better recovery path.
Complexity is not the enemy; confusion is
Another idea from the later part of the book is useful for product teams: complexity is not always bad. Some work is genuinely complex. Finance, healthcare, infrastructure, education administration, and developer tools all contain real complexity. Removing every advanced control can make the product prettier and less capable.
The enemy is confusion. Complexity becomes manageable when the system has a clear conceptual model, progressive disclosure, good defaults, visible state, and recovery paths. A Kubernetes dashboard can be complex. A payroll configuration tool can be complex. A tax workflow can be complex. The question is whether the product helps people understand the complexity or leaves them alone inside it.
This is also how teams resist feature creep. More features are not automatically better, and fewer features are not automatically simpler. The better question is whether each feature strengthens the core activity or only adds another disconnected option. A product can become harder to use not because one feature is bad, but because each small addition makes the whole model less coherent.
Key takeaways
- “Human error” is usually too small as an explanation. Ask what cues, defaults, pressure, and recovery paths shaped the action.
- Slips and mistakes need different fixes. Slips need better constraints and recovery. Mistakes need better models and decision support.
- Constraints can be protective. Validation, staged workflows, permissions, and lockouts help users avoid predictable harm.
- Undo often protects better than generic confirmation. Recovery paths accept ordinary human limits instead of pretending attention is perfect.
- Checklists move memory into the world. They are useful when repeated work is complex and interruptions are normal.
- Complexity is not the enemy. Confusion is. Good design organizes complexity so people can act with more control.
The calmer way to read Norman is not as a set of UX tricks, but as an ethical habit for teams: when people struggle, inspect the system. Not because users are never responsible, and not because design can prevent every problem, but because many future mistakes can be made less likely, less severe, or easier to recover from.
That is steady product work. It does not always look impressive in a roadmap. A safer default, a clearer distinction between staging and production, a smaller checklist, an undo window, a better state label. But these are the details that let ordinary people do important work without needing perfect memory, perfect attention, or perfect timing every day.