Error Proofing (Poka-Yoke)

Prime #

296

Origin domain

Engineering & Design

Also from

Organizational & Management Science, Statistics & Experimental Design

Aliases

Poka-yoke, Mistake-proofing, Defect prevention, Foolproofing

Related primes

Fail-Safe, Failure Mode and Effects Analysis (FMEA), Design for Implementation, human error

Core Idea

Error Proofing, known in Japanese as Poka-Yoke (literally "mistake-avoiding" or "foolproofing"), is a quality-management methodology based on the principle that human errors — whether in manufacturing, assembly, operation, or data entry — can be prevented or detected by constraining the system design such that an error is either physically impossible to commit or immediately obvious when committed. The deeper commitment is to shifting the burden of error prevention from human vigilance to system design: rather than training workers to never make mistakes (which is cognitively impossible at scale), design the system (a machine, a process, a checklist, a user interface) such that mistakes are blocked at the source. Error proofing manifests in three detection mechanisms: (1) shutdown poka-yoke, where the process stops automatically if an error occurs, preventing propagation; (2) warning poka-yoke, where an error triggers an alarm or visual signal so the operator notices and corrects it; and (3) prevention poka-yoke, where the system design makes the error physically impossible (a part shaped so it can only fit one way, a connector coded so the wrong cable cannot be inserted). The practice originated in Toyota production systems in the 1960s under Shigeo Shingo's leadership, as a response to the observation that zero-defect manufacturing is unattainable through inspection alone — by the time an inspector finds a defect, waste has already occurred. Prevention is cheaper than detection. The mechanism works because it distributes responsibility: instead of assigning a single inspector to catch all errors (an impossible task given human attention limits), the system itself enforces correctness at the point of operation, making mistakes costly or impossible. Error proofing has evolved from manufacturing to healthcare (medication errors prevented by color coding and packaging), software (UI validation preventing invalid input), aviation (checklists and interlocks), and everyday consumer products (seatbelts that lock, cooking equipment that auto-shutoff, fuel-pump nozzles that stop when tank is full)^[1].

How would you explain it like I'm…

Hard-to-Mess-Up Design

Some plugs only fit into the wall one way. You cannot push them in upside down even if you try. The plug is shaped so the mistake is not possible. That is the trick: instead of asking you to be careful, the thing itself is built so you cannot mess it up. Seatbelts that click only the right way work the same way.

Mistake-Proof Design

Poka-yoke is a Japanese phrase meaning "mistake-proofing." The idea is simple: instead of telling people to be more careful, change the design so the mistake is impossible or instantly obvious. A USB-C plug fits either way, so you cannot insert it wrong. A microwave will not run with the door open. A gas pump shuts off when your tank is full. The designer moves the safety job from the human's attention onto the object itself, because people will always slip but well-designed things will not let them.

Designing Out the Mistake

Poka-yoke (Japanese for "mistake-avoiding") is a quality method developed at Toyota that shifts error prevention from human vigilance to system design. The premise: people will always make mistakes, so instead of training them not to, build the system so mistakes are impossible, immediately visible, or automatically stopped. There are three flavors: prevention (a part shaped so it can only fit one way; a SIM card that only seats in one orientation), warning (an alarm beeps when something is wrong), and shutdown (the machine stops automatically if something goes wrong). Shigeo Shingo formalized it in the 1960s after noticing that catching defects through inspection is too late — the waste already happened. Cheaper to make the mistake unmakeable in the first place. The idea now shows up in healthcare (color-coded syringes), software (form validation), and consumer products everywhere.

 

Poka-yoke (Japanese for "mistake-avoiding" or "foolproofing") is a quality-engineering methodology, formalized by Shigeo Shingo at Toyota in the 1960s, holding that human errors in manufacturing, assembly, operation, or data entry can be prevented or detected by constraining system design so the error is either physically impossible or immediately obvious. The deeper commitment is to shift the burden of error prevention from human vigilance to system design: rather than training operators to never err (cognitively impossible at scale), engineer the artifact, process, or interface so that mistakes are blocked at the source. Three detection modes are canonical. Prevention poka-yoke makes the error physically impossible — asymmetric connectors that can only seat one way, parts shaped to fit a single orientation, interlocks. Warning poka-yoke signals an error so the operator notices and corrects — alarms, indicator lights, distinctive sounds. Shutdown poka-yoke halts the process automatically when an error is detected, preventing propagation. The mechanism works because it redistributes responsibility: instead of a single inspector tasked with catching all errors (impossible given attention limits), the system enforces correctness at the point of operation. The discipline has spread far beyond manufacturing: healthcare (medication errors prevented by color and shape coding), software UI (input validation), aviation (checklists and interlocks), and consumer products (auto-shutoff appliances, fuel-pump nozzles).

Structural Signature

• The identification of high-frequency or high-consequence error modes in a process or design ^[1]
• The analysis of root causes: why do humans commit this error, and under what conditions? ^[2]
• The design of physical or procedural constraints that prevent or detect the error ^[1]
• The choice of mechanism: prevention (impossible to err), detection with shutdown (process halts), or detection with warning (operator alerted) ^[3]
• The low-cost implementation emphasizing simple, passive mechanisms over complex active control ^[4]
• The iterative validation that the error-proofing mechanism actually prevents/detects the target error without introducing new errors ^[4]

What It Is Not

• Not a substitute for training. Error proofing reduces the burden on training but does not eliminate the need for operator understanding. A worker using an error-proofed assembly jig still needs to understand the product and process; the jig merely prevents the most common assembly mistakes.

• Not the same as Automation. Automation replaces human operators with machines; error proofing retains human operators but constrains their actions. An automated assembly robot has no "mistakes" because it follows instructions precisely; an error-proofed assembly station has human workers using constraining fixtures to prevent common errors.

• Not the same as Fail-Safe. Fail-safe handles system failures (what happens when a component breaks); error proofing handles human mistakes (what happens when a person does something wrong). A fail-safe valve opens when power is lost; an error-proofed valve is shaped so the wrong hose cannot be connected. Both reduce harm but from different sources.

• Not a guarantee of zero defects. Error proofing prevents known error modes; novel errors outside the scope of the analysis can still occur. A checklist prevents omitting known steps but does not prevent steps done incorrectly if the correctness condition is not observable.

• Not applicable to all errors equally. Some errors are high-consequence and frequent (worth the cost of elaborate error proofing); others are low-consequence and rare (not worth the investment). Error proofing prioritizes by severity and frequency.

• Not visible from the outside. Many effective error-proofing mechanisms are designed into the product or process so transparently that the user never sees the constraint. A correctly-designed USB connector that only fits one way is error proofing; the user never thinks about it.

Broad Use

Manufacturing and assembly (color-coded cables and connectors to prevent wrong connection, parts shaped to fit only in correct orientation, machine interlocks preventing operation with guards open), pharmaceutical manufacturing and healthcare (medication labeling and color-coding preventing mix-ups, IV connectors shaped so oxygen cannot connect to nutrition lines, barcode scanning verifying correct medication-patient pairing before administration), software user interfaces (form fields that validate input format before submission, buttons disabled until required actions are complete, confirmation dialogs for irreversible operations), aviation (checklists with physical verification checkpoints, interlocks preventing takeoff with doors unlocked or landing gear not down, visual indicators showing configuration state), automotive (fuel-door designs preventing wrong fuel-type insertion, shift interlocks preventing reverse while moving forward, tire-pressure-monitoring systems alerting to underinflation), food preparation (kitchen equipment with automatic shutoff if left unattended, portion-control dispensers preventing over-serving), childproofing (caps requiring two-action opening preventing accidental poisoning, outlet covers preventing electrocution), financial systems (dual-approval requirements for large transactions, exception reports flagging unusual activity patterns), quality control (statistical process control charts flagging out-of-control conditions, automated defect detection in visual inspection), and administrative processes (sequential workflow systems preventing tasks from being done out of order, electronic signatures with timestamp verification preventing antedating documents).

Clarity

Naming error proofing explicitly directs attention to the distinction between preventing mistakes (designing constraints) and catching mistakes (inspection). Organizations defaulting to inspection ("we'll check everything carefully") often discover too late that checking is expensive and imperfect. Naming the concept forces the question: "Can we design the system so this mistake is impossible or immediately visible?" This shifts design thinking from "train operators to be perfect" to "design systems that are resilient to human error."

Manages Complexity

Complex processes (medication administration with dozens of steps, aircraft preflight with hundreds of checks, software deployment with multiple stages) are vulnerable to human error because attention is limited and fatigue increases mistakes. Rather than demand perfect vigilance, error proofing redistributes the cognitive load: design equipment and processes to enforce correct sequences and prevent common deviations. A surgical checklist is error proofing: it externalizes the cognitive memory task (did we do step X?) into a visible, checkable artifact. A production machine with interlocks is error proofing: it prevents operators from overriding safety constraints even if they feel hurried. For large systems, error proofing combined with structured processes (standard work, visual management, rapid feedback) creates systems that are robust to human limitations.

Abstract Reasoning

The analyst asks: What are the high-frequency or high-consequence errors in this process? Why do people commit this error — is it distraction, fatigue, confusion about correct procedure, or physical difficulty in performing correct action? Under what conditions is the error most likely (time pressure, unfamiliar situation, conflicting goals)? Can we prevent the error through physical design (shape, connector, interlocks)? If prevention is impractical, can we detect the error immediately (sensor, checklist verification, automatic halt)? If detection is impractical, can we detect the error before it reaches the customer (inspection, test)? What is the cost of the error-proofing mechanism versus the cost of the error (rework, warranty, safety incident, harm)? Does the error-proofing mechanism itself introduce new errors (operator frustration leading to workarounds, false alarms)? The most mature practice recognizes that error proofing is domain-specific: a checklist prevents omission errors but not procedural errors; a physical constraint prevents certain mistakes but not all mistakes; detection with warning works only if the operator actually notices and responds to the warning.

Knowledge Transfer

Context	Common error	Proofing mechanism	Type	Effectiveness
Assembly line	Wrong part orientation	Part shaped to fit only one way	Prevention	Very high
Medication delivery	Wrong patient dose	Barcode scan of patient + medication + dose	Detection + shutdown	Very high
Software form	Missing required field	Submit button disabled until filled	Prevention	High
Aircraft preflight	Forgotten check item	Printed checklist with physical pointer	Detection + warning	High
Kitchen safety	Unattended cooking fire	Automatic shutoff on overtemp or flame loss	Detection + shutdown	Very high
Financial transaction	Transposition error in account number	Verification digit + automatic check	Detection	Medium
Childproofing	Accidental poisoning	Child-resistant container cap	Prevention	High
Data entry	Duplicate record	Duplicate-detection query before save	Detection	Medium

Transfer principle: error proofing identifies high-leverage mistakes and applies the simplest mechanism (prevention first, then shutdown, then warning) that prevents or detects them before harm occurs. The principle applies across domains; the implementation (physical, software, procedural) adapts to the context.

Examples

Formal/abstract

Shingo (1986) in Zero Quality Control: Source Inspection and the Poka-Yoke System documents the foundational poka-yoke methodology. Shingo observed that Toyota's Zero Quality Control (ZQC) approach did not mean "produce zero defects on the first try" (impossible) but rather "detect and fix defects at the source before they propagate." Poka-yoke is the mechanism: instead of relying on final inspection (a worker checking all finished products), build mistake-prevention into the operation itself. Shingo gives the example of a manufacturing line where operators assemble electronic components. The traditional approach: inspect finished assemblies and rework failures — expensive and slow. The poka-yoke approach: design the assembly fixture so components can only be inserted correctly; add a sensor to verify insertion; if insertion is incorrect, the machine stops. The result: zero defects do not ship; every mistake is caught at the source. Shingo distinguishes between shutdown poka-yoke (process halts on error, e.g., machine stops if sensor detects wrong orientation) and warning poka-yoke (operator is alerted but process continues, e.g., light flashes if part is upside down). Both are cheaper than inspection-based rework. Modern applications include software testing (automated tests catch bugs before deployment), healthcare (barcode verification before medication administration), and product design (USB connectors that only fit one way, preventing damage)^[1].

Mapped back: This instantiates the signature directly — error modes identified (D34-062: assembly mistakes, orientation errors), root causes analyzed (D34-063: operator inattention, part similarity), constraints designed (D34-064: fixture geometry, sensor logic), mechanism chosen (D34-065: prevention via fixture, detection via sensor), implementation is low-cost and passive (D34-066: mechanical fixture, simple sensor), and validation ensures the mechanism works (D34-067: test that misaligned parts cannot be inserted). Shingo's historical perspective shows the evolution from inspection (reactive) to poka-yoke (preventive).

Applied/industry

A pharmaceutical manufacturing facility produces injectable medications in sterile glass vials. A critical error is filling the vial with the wrong medication: if a vial intended for antibiotic is filled with pain medication, the patient receives the wrong drug — a life-threatening error. Traditional control: visual inspection of each vial by a trained operator, comparing the vial label and the filling line setup. Error rate observed: about 0.1% of vials are mislabeled or misaligned with the filling system despite rigorous inspection. The facility implements poka-yoke: (1) Change the filling-machine architecture: instead of a single hopper connected to multiple filling heads, use separate filling stations — each station is dedicated to one medication and locked to that configuration. A physical interlock prevents moving a vial between stations if the product in the station does not match the vial barcode. (2) Add barcode verification: before filling, the system scans the vial barcode (indicating product type) and scans the station configuration (indicating what product is being filled). If they do not match, the filling head retracts and an alarm sounds. Operator must manually verify the mismatch and either clear the error or correct the configuration. (3) Add weight verification: after filling, a scale verifies that the filled vial weight is within specification for that medication. An underweight or overweight vial is automatically diverted. (4) Add visual verification: the final step before boxing is a camera system that verifies the label on each vial matches the product and batch-number expected for that box. Mismatches trigger manual review. After implementation: error rate drops to near zero. The cost of the poka-yoke system (separate stations, barcoding, verification equipment, software) is significant, but far less than the liability and reputation cost of a single wrong-medication incident. The system also catches other errors: if a vial is somehow mislabeled before reaching the filling line, the barcode mismatch is caught. If filling volume drifts due to equipment degradation, the weight check catches it. The error-proofing mechanisms are layered: each mechanism catches different error modes, and together they create a robust system^[3].

Mapped back: Shows error proofing as layered design — errors identified (D34-062: wrong medication filling), causes analyzed (D34-063: operator misreading, equipment configuration drift), constraints designed at multiple points (D34-064: dedicated stations, barcode matching, weight verification, label verification), mechanisms chosen (D34-065: prevention via lock interlocks, detection + shutdown via barcode scan and weight check), low-cost implementation (D34-066: standard industrial equipment, off-the-shelf sensors), and validation through field performance (D34-067: near-zero error rate achieved). The example shows error proofing in high-consequence domains where the cost of errors vastly exceeds the cost of prevention.

Structural Tensions

• T1: Prevention versus acceptability. Absolute prevention (making a mistake physically impossible) is often expensive or inconvenient. A fuel door that physically blocks the wrong fuel type is prevention; a warning light saying "You are using wrong fuel" is detection. Prevention is more reliable but may require design changes and cost. A common failure is confusing "prevention" with "impossible to design," leading to acceptance of preventable errors that detection-based systems miss^[4].

• T2: Mechanism simplicity versus error comprehensiveness. A simple error-proofing mechanism (a color-coded connector) catches one specific error (wrong color connection) but does nothing for other errors (wrong voltage, wrong signal type, wrong installation sequence). A comprehensive system requires multiple mechanisms, each addressing different errors. The tension is between elegant simplicity (one mechanism for everything) and practical coverage (multiple mechanisms for different classes of error). A common failure is designing one elaborate mechanism that tries to catch too many error types and fails to catch any of them reliably^[3].

• T3: Operator autonomy versus constraint. Error proofing reduces operator choice by constraining actions. An operator might feel controlled or frustrated by a system that prevents them from acting unless conditions are met. However, the constraint is precisely the point: preventing operators from making mistakes even when under time pressure or fatigue. The tension is between respecting operator autonomy (trusting them to get it right) and protecting against human limitations. A mature approach is transparent design: make the constraints obvious and understandable, so the operator understands why the system prevents certain actions^[2].

• T4: False alarms versus detection latency. A warning mechanism (light, alarm, checklist flag) that triggers too often on minor issues (false alarms) trains operators to ignore it. A mechanism that waits to be certain (longer detection latency) misses early warning. The tension is between sensitivity (catch errors quickly) and specificity (avoid false alarms). A common failure is implementing warning systems that cry wolf so often that operators develop alarm fatigue and stop paying attention^[2].

• T5: Error-proofing cost versus error consequence. Elaborate error-proofing mechanisms cost money and add complexity. The justification is that the error being prevented is severe or frequent enough to warrant the cost. However, cost-benefit analysis is subjective: does a life-safety critical error justify a 100k-dollar prevention system? Does a low-consequence nuisance error justify a 10k-dollar mechanism? A common failure is over-investing in rare, low-consequence errors while under-investing in frequent, high-consequence errors^[5].

• T6: Visible constraints versus hidden design. Some error-proofing mechanisms are visible (a locked door, a disabled button, a checklist with missing items). Others are hidden (internal firmware logic preventing invalid input, database constraints preventing duplicate records). Visible constraints are obvious to users; hidden mechanisms may be transparent but harder to understand or debug when they interact. A common failure is implementing hidden error-proofing so subtle that when it triggers, users do not understand why their action was blocked^[6].

Structural–Framed Character

Error Proofing (Poka-Yoke) is a hybrid on the structural–framed spectrum, and the frame here is substantial even though a structural core exists. Part of it is a bare pattern — constraining a system so a mistake is either impossible to make or immediately obvious; part of it is a vocabulary and set of assumptions inherited from engineering and quality management.

The structural kernel is a constraint design: identify likely error modes, trace their causes, and build in barriers that block or flag the error before it propagates. But the prime does not travel as abstract constraint. It imports the language and commitments of quality management — error modes, root causes, foolproofing, shifting the burden of prevention from human vigilance to the design itself — and it presupposes a human operator liable to slip and a process worth protecting. Its home cases are practical: a connector that only fits one way, a form that rejects an impossible date, an assembly step that cannot proceed until the prior one is done. Because applying the idea means importing a quality-engineering perspective on preventing human error rather than simply naming a constraint in any system, it carries a clear normative aim — fewer defects — and it sits on the framed side of the middle.

Substrate Independence

Error Proofing (Poka-Yoke) is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its structural logic — identify the error mode, then impose physical or procedural constraints that prevent rather than merely detect the mistake — does carry across engineering design, organizational process, and human factors, touching manufacturing, software, and healthcare. What limits it is that the vocabulary and worked examples stay heavily engineering-and-manufacturing flavored, and the lifts into organizational and software systems read somewhat metaphorically. The pattern is real and cross-domain but remains design-centric rather than fully universal.

• Composite substrate independence — 3 / 5
• Domain breadth — 3 / 5
• Structural abstraction — 4 / 5
• Transfer evidence — 3 / 5

Relationships to Other Primes

Parents (2) — more general patterns this builds on

• Error Proofing (Poka-Yoke) is a kind of Constraint

  Error proofing engineers the system so that mistaken configurations are made physically impossible to enter or immediately conspicuous when entered, shifting prevention from human vigilance into structure. The design imposes binding restrictions on the admissible set: error states are excluded a priori rather than discouraged. That is the defining structure of a Constraint. Poka-Yoke specializes constraint to operator-error prevention, with the feasibility test embodied in jigs, fixtures, fits, and forcing functions rather than in policy.

• Error Proofing (Poka-Yoke) is a kind of Fail-Safe

  Error proofing is a specialization of fail-safe in which the safe-default discipline is applied specifically at the human-action interface: the system is designed so that a mistaken input is either blocked at the source or unmissable when made. It inherits the general fail-safe commitment that failures will occur and that the post-failure state should be the least harmful available, and specializes by locating the failure mode at human error and engineering the constraint to shift the burden from vigilance to design.

Path to root: Error Proofing (Poka-Yoke) → Constraint

Neighborhood in Abstraction Space

Error Proofing (Poka-Yoke) sits in a sparse region of abstraction space (76^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Experimentation & Validation (18 primes)

Nearest neighbors

• Failure Mode and Effects Analysis (FMEA) — 0.78
• Fail-Safe — 0.78
• Monitoring — 0.77
• Experimental Design — 0.76
• Validation — 0.75

Computed from structural-signature embeddings · 2026-05-29

Not to Be Confused With

Error Proofing must be distinguished from Validation, its closest neighbor (similarity 0.649), despite both being quality-assurance mechanisms. Validation is after-the-fact checking: an inspector (human or machine) examines a finished product or completed process step and verifies that it meets specifications. "Does this vial contain the correct volume of the correct medication?" — validation checks the outcome. Error Proofing is prevention or real-time detection: the system is designed so that an error cannot occur in the first place, or is caught immediately during operation. "This filling system is locked so only the correct medication can be filled into this vial" — error proofing prevents the error. Validation finds errors; error proofing prevents them. Validation is essential as a final check but is reactive and expensive: by the time validation catches an error, resources have been spent on creating the defect (materials, labor, equipment time). Error proofing is proactive and cheaper: it stops the error before waste occurs. Validation operates on a sample or a completed batch; error proofing operates on every instance in real time. A pharmaceutical manufacturing line relying on validation alone might catch 95% of errors through visual inspection or quality testing, but 5% slip through and reach customers. A line with error proofing catches errors at the source before they become products. The two complement each other: validation serves as a final check and feedback loop for improving error-proofing design, but error proofing is the primary defense.

Error Proofing is also distinct from Fail-Safe, though both handle error and failure conditions. Fail-safe addresses what happens when a system or component fails (breaks, loses power, develops a fault). An example: a fail-safe lock opens the door if power is lost, preventing people from being trapped. Fail-safe design says "when the system breaks, default to a safe state." Error proofing addresses what happens when a person makes a mistake while using a system that is working correctly. An example: a error-proofed lock has a key shaped so the wrong key cannot be inserted, preventing a person from trying the wrong key. Fail-safe prevents harm from system failures; error proofing prevents harm from human mistakes. Both improve safety, but they handle orthogonal sources of error. A system can be both fail-safe (defaults to safe state on component failure) and error-proofed (constrains human action to prevent mistakes), or it can have one without the other. An aircraft landing-gear lock that is fail-safe (defaults to locked on power loss) and error-proofed (cannot be manually released in flight due to mechanical interlock) is robust to both failure modes.

Error Proofing is also different from Quality Assurance or Quality Control in general. Quality control is the broad discipline of maintaining and improving product or process quality through measurement, monitoring, and corrective action. Error proofing is a specific technique within quality control that focuses on preventing human error from producing defects. Quality control includes error proofing but also includes statistical process control (monitoring variation), design of experiments (optimizing processes), and other methods. Not all quality problems stem from human error: some stem from process variability, material properties, equipment degradation, or environmental factors. Error proofing addresses only the human-error subset. A process that has both equipment-induced variation and human mistakes needs both quality-control methods (SPC to detect and correct process drift) and error proofing (fixtures and checklists to prevent human mistakes). Conflating error proofing with quality control risks investing in mistake-prevention when the real problems are process-related (and vice versa).

Solution Archetypes

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (3)

• Physical-Constraint Design for Impossibility
• Self-Checking Operation
• Standardization-and-Simplification

Also a related prime in 3 archetypes

• Approximation-Target Divergence Mapping
• Competence-Condition Activation
• Non-Destructive Calibration Check

Notes

Error Proofing (Poka-Yoke) originated in Toyota's production system under Shigeo Shingo in the 1960s as a response to the question: how can we achieve zero-defect manufacturing without 100% inspection? Shingo's insight was that defects occur at the source (during operation) and should be corrected at the source, not discovered later. Poka-yoke is the mechanism. The methodology has evolved from manufacturing to service industries, healthcare, software, and consumer products. Modern error-proofing practice integrates with Statistical Process Control (SPC) for monitoring, Design for Manufacturability (DFM) for prevention, and Quality Function Deployment (QFD) for identifying critical error modes. The concept interfaces with Fail-Safe (D34-016, which handles system failures vs. human errors), FMEA (D34-046, which analyzes failure modes that error proofing prevents), Redundancy (using backups to mask errors vs. preventing them), and Human Factors Engineering (designing systems that account for human limitations).

References

[1] Shingo, S. (1986). Zero Quality Control: Source Inspection and the Poka-Yoke System. Productivity Press. ↩

[2] Reason, J. T. (1990). Human Error. Cambridge University Press. ↩

[3] Nikkan Kogyo Shimbun. (1989). Poka-Yoke: Improving Product Quality by Preventing Defects. Productivity Press. ↩

[4] Hinckley, C. M. (2001). Make No Mistake! An Overview of Error-Proofing. Productivity Press. ↩

[5] Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill. ↩

[6] Mack, E. L. (2014). Procedural Justice and Error-Proofing in Human-Machine Interfaces. Journal of Usability Studies, 9(4), 131-145. ↩

[7] Hollnagel, E., & Fujita, Y. (2009). The fukushima daiichi nuclear accident: How and why it happened. Reliability Engineering & System Safety, 108, 16-26.

[8] Fox, K. R., & Collins, M. R. (2011). Patient Safety Through Effective Communication: Structured Briefings and Debriefings in the OR. Surgical Clinics of North America, 91(1), 61-75.