What Engineers Get Wrong About Human Behaviour

Engineers are trained to admire systems that behave predictably. Give a motor the correct voltage, keep a sensor within its operating range, account for tolerances, and it will generally do the same thing tomorrow. People, rather inconveniently, are not like that.

This is not a complaint about people. It is a complaint about the engineering habit of treating human behaviour as an awkward variable to be eliminated once the proper dashboard, workflow or warning light has been installed. We sometimes design as though users are components with poor documentation and a regrettable tendency to require lunch.

That assumption produces products which are technically impressive and quietly miserable to use.

People are not rational inputs

A familiar engineering model goes something like this: present clear information, offer the sensible option, and a person will choose it. If they do not, the interface needs another reminder, a brighter colour, or perhaps a modal dialogue large enough to be visible from space.

But people make decisions while tired, busy, anxious, embarrassed, distracted, under pressure from colleagues, or trying to get home to their family. They may understand the instruction perfectly and still decide that following it is not worth the immediate cost. That is not necessarily irrational. It may be an entirely reasonable response to the situation we have failed to see.

Consider an alarm in a monitoring system. If it triggers too often, staff learn that most alerts do not demand action. They are not careless for becoming less responsive; they are adapting to the evidence the system gives them. Alarm fatigue is not cured by adding a more insistent beep. That merely makes the system a louder colleague with no sense of proportion.

The engineering question is not only, “Can we detect this condition?” It is also, “What will a person do at 3am, with three other problems competing for attention, when this appears?” Those are different questions, and the second is usually harder.

We mistake instructions for design

When a product needs a four-page procedure, a training session and a laminated sheet taped beside the equipment, there is a fair chance the design is asking the human to compensate for it.

Instructions matter. Some tasks are genuinely complex, regulated or safety-critical. Nobody wants a nuclear reactor controlled by cheerful icons alone. Yet engineers can use documentation as a sort of ceremonial blanket: the limitation is written down, therefore it has been dealt with.

It has not.

A good system makes the safe, sensible action easy to discover and difficult to get wrong. It anticipates predictable slips: a cable plugged into the wrong port, an acknowledgement pressed by habit, a password shared because the account process takes two days, a maintenance task postponed because stopping production feels impossible.

These are not exotic edge cases. They are the main road. The edge case is the immaculate operator, following every step in perfect sequence, in an environment with no interruptions and an unlimited supply of patience. That person exists chiefly in PowerPoint.

We underestimate social systems

Technology is often introduced into workplaces as if it arrives in a vacuum. It does not. It arrives among existing relationships, authority, incentives, routines and fears.

A new reporting tool may be sold as a way to improve accountability. Staff may experience it as surveillance. An automated scheduling system may optimise utilisation while removing the small bits of flexibility that make a difficult job manageable. A dashboard may give managers a clearer picture while encouraging everyone else to optimise whatever happens to be counted.

None of this means measurement is bad or automation is sinister. It means the system has consequences beyond its database schema.

I think disability sharpens this point. A design that works neatly for an imagined average user can create a disproportionately high burden for someone dealing with fatigue, pain, limited dexterity, sensory overload or simply a body that does not cooperate to timetable. The same is true, in different ways, for people with caring responsibilities, poor connectivity, limited confidence with technology, or jobs where they cannot stop and study a screen whenever software requests their attention.

Designing for variation is not charitable decoration around the “real” product. It is how we make products less brittle for everyone.

We confuse compliance with understanding

Users are very good at complying superficially. They click the mandatory field. They accept the terms. They enter a plausible value to satisfy validation. They create workarounds that keep the operation moving while ensuring the official process bears only a passing resemblance to reality.

Engineers can look at a completed form or a green status indicator and conclude that the system is working. Often, it means people have become skilled at feeding the machine what it expects.

The useful response is curiosity rather than blame. Watch how work is actually done. Ask what people do when time is short. Ask which screens they dread, which steps get skipped, and what they have invented to make the process survivable. Then listen without treating every workaround as a confession.

A workaround may reveal poor training. It may also reveal that the formal process is too slow, too rigid, or based on assumptions made by someone who has never had to use it on a wet Tuesday with a queue forming behind them.

Better engineering starts with humility

The remedy is not to become amateur psychologists, armed with a personality quiz and an alarming amount of confidence. It is to treat human behaviour as a serious design constraint, like power budget, latency, calibration drift or cybersecurity.

Test with real people early. Observe rather than merely asking whether they like the prototype. Include people whose circumstances differ from the design team’s. Build forgiving paths for mistakes. Make feedback timely and meaningful. Most importantly, accept that if people use a system in an unexpected way, the system may be teaching them that behaviour.

Engineering at its best is an act of care: taking a messy reality seriously enough to build something that helps rather than merely functions. People are adaptable, inventive and occasionally gloriously contrary. A system that respects that will usually prove more reliable than one that expects humans to behave like well-specified hardware.