Why Good Engineers Design for the Person Having a Bad Day

The user is not a neat little use case

There is a popular fiction in product development: the user arrives alert, calm, well-trained, holding a reliable internet connection and a fully charged phone. They read every label, remember every password, understand every warning, and respond to a notification within seconds.

This person does not exist. Or, if they do, they are probably too busy organising their spice drawer by molecular weight to use our software.

Real people use systems while tired, interrupted, worried, in pain, carrying shopping, dealing with children, travelling, working a night shift, or trying to solve a problem that should not have existed in the first place. Sometimes all of those arrive before breakfast.

A good engineer designs for that person: the person having a bad day. Not because users are careless or incapable, but because human attention, memory, dexterity and patience are limited resources. Systems that demand too much of them will eventually fail at precisely the moment they matter most.

Bad days are a design condition, not user error

Engineering is full of conditions we accept without moral judgement. A sensor has a tolerance. A battery has a discharge curve. A network connection has latency, packet loss and occasional moments of theatrical collapse. We do not call a battery lazy because it is flat.

Yet when people struggle with a product, organisations often leap to “user error”. Sometimes the user has indeed pressed the wrong thing. The more useful question is why the system made the wrong thing easy to press, hard to undo, or unclear in the first place.

This is particularly important in systems with consequences. If a temperature-monitoring platform sends an alarm at 3am, the person receiving it may be half awake and under pressure. They need to see what happened, where it happened, how severe it is, and what to do next. They do not need a dashboard that treats every alarm like an escape room.

A sensible alarm design separates urgency from information density. It should make the primary action obvious, retain the history needed to investigate, and avoid burying critical detail under decorative charts. Colour alone is not enough, either. It is an accessory, not a communications strategy. Labels, icons, contrast, text and sensible ordering all matter.

The system should also be honest about uncertainty. A sensor reading can be stale because a gateway has lost connectivity. A timestamp can be wrong because a device clock has drifted. A missing reading is not necessarily a safe reading, however much a green dashboard would prefer otherwise.

Make the safe action the easy action

The strongest practical test is simple: when somebody is rushed, what action will the interface encourage?

If the safe action needs six steps, a manual, two-factor authentication and a small emotional pilgrimage, people will find a shortcut. They are not being difficult. They are adapting to friction, which is one of humanity’s more reliable talents.

Good design reduces the chance of a damaging action and makes recovery straightforward when one happens. That means considering mechanisms such as:

• Clear defaults that suit the common safe case, rather than leaving every decision blank in the name of flexibility.
• Confirmation for irreversible actions, especially deletion, acknowledgement and configuration changes that affect alerts.
• Undo where it is technically possible, because a mistaken click should not always become a permanent lifestyle choice.
• Plain-language status messages that say what failed, what the system has already tried, and what the user can do next.
• Graceful offline behaviour, so a temporary network failure does not turn an app into an expensive picture of its former self.

There is a trade-off here. Too many confirmations create warning fatigue. If every harmless action produces a modal dialogue, people learn to click “Yes” with the speed and attention usually reserved for accepting biscuit banners. Confirmation should be reserved for actions with real consequence, and the wording should describe that consequence plainly.

In embedded and IoT systems, designing for recovery is often more valuable than trying to prevent every possible fault. Power will fail. Wi-Fi credentials will change. A gateway will be unplugged by somebody who needs that socket for a vacuum cleaner. The device should reconnect predictably, preserve useful state safely, report its health, and avoid silently pretending that everything is fine.

Accessibility is ordinary engineering discipline

Designing for a bad day overlaps heavily with accessibility because disability, illness, fatigue, stress and temporary impairment all expose the same brittle assumptions.

As a disabled person, I am familiar with the difference between a system that technically permits access and one that makes access practical. Those are very different standards. A form that times out while someone needs longer to read or type is not made accessible by a polite statement in the footer. A button that is difficult to reach, identify or operate is still difficult, even if the design review called it “clean”.

Accessible design benefits far more people than the narrow image some teams carry in their heads. Captions help someone in a noisy station. Large tap targets help someone using one hand. Good contrast helps in bright light. Keyboard operation helps people who cannot or do not want to use a mouse. Clear instructions help everyone, especially when the system has just chosen a spectacularly inconvenient moment to complain.

This is not a request to make every product visually dull or smother it in options. It is a request to understand variation in human capability as a normal operating condition. We already do this for voltage ranges and environmental temperatures. People deserve at least as much consideration as a lithium battery.

Test the messy version of reality

A polished prototype in a quiet meeting room tells us very little about a system under strain. Testing needs to include the awkward conditions: poor connectivity, slow devices, interrupted tasks, low battery, screen glare, background noise, confusing data and users who have not attended the three-hour training course that nobody has time to attend.

For software, this can mean testing with keyboard-only navigation, screen readers, reduced motion, large text, and deliberately degraded networks. For connected hardware, it can mean power-cycling at inconvenient points, checking what happens when time synchronisation fails, simulating sensor disconnection, and making sure alarms do not vanish merely because the cloud service has taken an unscheduled lie-down.

It also means talking to the people who will actually operate the system. Not just the buyer, the project sponsor or the most technically confident member of staff. The person who receives alerts overnight, enters data between other tasks, or has to use the interface while wearing gloves may reveal the flaw that a room full of product people missed.

None of this requires clairvoyance. It requires humility. Engineers cannot predict every circumstance, but we can identify where assumptions are doing suspiciously large amounts of work.

A kinder system is usually a better system

Designing for the person having a bad day is not sentimentality bolted onto engineering after the serious work is finished. It is serious work.

It produces systems that are safer, easier to support, less prone to avoidable mistakes and more trustworthy when conditions are difficult. It also tends to expose weak architecture. If an outage leaves users unable to understand what is happening, the problem is not merely in the interface. If a single mistyped setting can disable an important function, the problem is not merely training.

The useful ambition is modest: build things that do not punish people for being human. Give them a clear next step. Preserve their work. Explain failure without blame. Let them recover. On a good day, they may barely notice these choices. On a bad one, they may be the difference between a manageable problem and a thoroughly miserable afternoon.

That is where good engineering earns its keep.