What Wheelchairs Teach You About Designing Robust Systems

A robust system is often described as one that keeps working when conditions are less than ideal. That definition sounds sensible until you ask the obvious follow-up: less than ideal for whom?

For many people, a wheelchair makes that question impossible to ignore. A route that looks perfectly adequate on a planning drawing can become unusable because of a steep camber, loose gravel, a poorly placed bollard, a broken lift, or a threshold with the confidence of a small mountain range. The wheelchair has not failed. The environment has failed to accommodate the conditions in which the system is supposed to operate.

That is a useful lens for engineers, product designers and anyone building connected systems. Robustness is not a laboratory property. It is a relationship between a thing, its users, its surroundings and the unpleasant surprises that turn up on a Tuesday afternoon.

The operating environment is part of the system

A wheelchair is not used on a clean, level, climate-controlled test bench. It meets potholes, rain, dropped kerbs, narrow doorways, low batteries, worn surfaces and infrastructure designed by people who apparently regard a 90-degree turn into a cupboard as an accessibility feature.

Engineering projects make a similar mistake when they define the system boundary too narrowly. A sensor may meet its accuracy specification on the bench, for example, but its reading can still be useless if condensation reaches the connector, a cable is routed beside a noisy motor, the enclosure is fitted in direct sun, or the wireless signal disappears behind a newly installed metal rack.

The device is only one component. Installation, maintenance access, power, network behaviour, operators and physical surroundings are all part of the working system.

This matters especially in IoT. It is easy to say that a monitoring device transmits data every fifteen minutes. The more important questions are less glamorous:

• What happens when it cannot transmit for three days?
• Does it buffer readings locally, and can it preserve time order after reconnecting?
• What does it do when its clock drifts or resets?
• Can a technician replace its battery without dismantling half a plant room?
• Does a user know it has failed, or does it merely become quietly optimistic?

A robust design treats these as core requirements, not awkward appendices for the person writing the support manual.

Graceful degradation beats theatrical failure

Wheelchairs teach another important lesson: partial capability still matters.

If a power wheelchair has a problem, the consequences depend heavily on how it fails. A system that reports a declining battery early, limits non-essential power use, preserves enough charge for a safe return journey, and gives clear status information behaves very differently from one that appears healthy until it abruptly becomes an expensive chair-shaped administrative problem.

The principle carries straight across to embedded systems. When an IoT gateway loses its internet connection, it should not necessarily stop gathering data. Local storage, retry queues with sensible backoff, visible fault indicators and an explicit recovery path can turn an outage into an inconvenience rather than a data integrity disaster.

There is a design trade-off here. More local buffering requires non-volatile memory, careful wear management and rules for what happens when storage fills. Retry logic needs limits, otherwise a device can drain its battery repeatedly shouting into the void. A fallback mode may provide less functionality, but it must be predictable.

Predictable limitation is usually kinder than an impressive collapse. Systems rarely receive applause for this, because nobody notices a failure that was handled properly. That is rather the point.

Maintenance is not an edge case

A wheelchair that cannot be repaired quickly is not robust merely because its original design was elegant. Availability depends on practical things: whether faults can be diagnosed, whether a part can be obtained, whether a repair is possible without specialist equipment, and whether the owner is given useful information rather than a blinking light with the emotional range of a smoke alarm.

The same is true of industrial and connected products. Designers sometimes optimise fiercely for assembly cost, then create a maintenance puzzle involving security screws, glued battery compartments and connectors placed where only a very determined ferret could reach them.

For a field device, consider the full maintenance chain:

• Can someone identify the unit without guessing which anonymous grey box it is?
• Are diagnostic logs available without physically recovering the device?
• Is the battery or sensor replaceable, and is the replacement process resistant to mistakes?
• Can firmware updates be rolled back if an update is interrupted or proves faulty?
• Does the system distinguish a genuinely failed sensor from a disconnected cable or a flat battery?

That final distinction is particularly important. A temperature monitor reporting an implausibly stable value may look reassuring while its probe is disconnected. A sensible design uses plausibility checks: rate-of-change limits, expected operating ranges, detection of open or shorted sensor circuits where the interface permits it, and a clear quality flag alongside the measurement. Data without provenance is just a number wearing a lanyard.

Reliability includes the human interface

Robustness is often reduced to hardware durability or uptime statistics. Both matter, but a system can remain electrically functional while becoming unusable to the person who relies on it.

Wheelchair users encounter this whenever a control, payment terminal, door button or lift panel is installed where it is technically present but physically unreachable. The designer can claim the feature exists. The user is left negotiating with geometry.

Digital systems have their own versions of this failure. Status colours without text labels, tiny touch targets, timeout-heavy forms, alarm messages written in vague technical fog, and dashboards that require perfect vision, dexterity or concentration all shift work onto the user at exactly the wrong moment.

Accessible design is therefore not a charitable add-on. It is a form of fault tolerance. A clear alarm that communicates what happened, what the risk is, and what action to take helps everyone: a tired operator at 3am, a technician wearing gloves, a user with low vision, or someone trying to make sense of an incident while being interrupted every thirty seconds. Which, to be fair, describes most operations rooms.

Redundancy must address real failure modes

“Add redundancy” is often offered as a universal remedy, rather like suggesting tea for any British problem. It can help, but only if it addresses the thing that is actually likely to fail.

Two sensors mounted beside each other may protect against one sensor fault, but not against a power loss, an installation error, a blocked airflow path or a shared calibration mistake. Two network connections do not help much if both depend on the same poorly placed antenna. A backup manual process is weak if nobody has practised it, documented it or been given the authority to use it.

In wheelchair access, a lift is not meaningful redundancy for stairs if it is routinely out of service, inaccessible from one side, or requires a staff member with a key who has gone to lunch. A backup is only a backup when it is available under the conditions that caused the primary route to fail.

For technical systems, this means performing failure-mode analysis with uncomfortable honesty. Identify shared dependencies. Ask what happens during power failure, network loss, corrupted configuration, a bad firmware release, a failed certificate renewal, or a human being understandably making a mistake under pressure.

Then test the recovery process, not just the failure. Plenty of systems can detect an incident. Fewer can get back to a known good state without an archaeological expedition through log files.

Design for dignity as well as survival

The best robust systems do more than limp onwards. They preserve the user’s agency.

That means giving people clear information, choices that are meaningful, and an escape route when automation makes the wrong call. It means not forcing users to prove that a problem exists before they are allowed to report it. It means recognising that time, energy and attention are limited resources, particularly for disabled people, but frankly for everyone.

A system designed around ideal behaviour, perfect infrastructure and unlimited user patience is not robust. It is merely lucky when it works.

Wheelchairs make the gaps visible because the consequences are immediate and physical. Good engineering takes that lesson seriously. Build for uneven ground, imperfect information, interrupted connections and ordinary human lives. The result is not only more accessible. It is calmer, safer and far more likely to keep doing its job when the world declines to behave like the test plan.