VI. Technology should work even when it fails: Difference between revisions
Caseorganic (talk | contribs) Created the page! |
Caseorganic (talk | contribs) m Created the page! |
||
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
Every system fails. The design question is what remains when it does. A system that retains its core function during a failure costs a person an inconvenience. A system that loses everything costs a person the task, and often the trust that made the system usable in the first place. | |||
Failure states are part of the product, and they are the part most often left undesigned. A device that assumes power, connectivity, a working sensor and a reachable server has four ways to become useless, and each one is a decision somebody made. | |||
* A | * A mechanical key opens a door when the battery in the lock is dead. | ||
* A | * A window opens when a ventilation system is off. | ||
* A | * A printed schedule remains readable when a display is dark. | ||
=== | ===The Escalator=== | ||
An | An escalator that loses power becomes a staircase. The treads are stair-shaped and stair-sized because they were engineered to carry standing weight, and the handrail remains at the height a hand expects. A person walking onto a stopped escalator changes their gait and continues. | ||
Nothing about this is accidental. Tread depth, riser height and handrail placement are specified so the stopped condition is safe to walk. The comparison case is a powered door that seals shut, or a hotel lock whose dead battery leaves no mechanical path to the room. | |||
An escalator that fails well does not need to: | |||
* | *Announce that it has stopped | ||
* | *Be repaired before people can pass | ||
* | *Trap anyone on it | ||
* | *Be operated differently while stopped | ||
The | The same logic applies to software. A connected thermostat that holds its last schedule during an outage keeps a house warm. One that reverts to a default or waits for a server does not. | ||
Just as a | Just as a stopped escalator is still a staircase, well-designed technology retains its core function when the parts that make it convenient are gone. | ||
==Categories== | ==Categories== | ||
Latest revision as of 18:30, 23 August 2026
Introduction
Every system fails. The design question is what remains when it does. A system that retains its core function during a failure costs a person an inconvenience. A system that loses everything costs a person the task, and often the trust that made the system usable in the first place.
Failure states are part of the product, and they are the part most often left undesigned. A device that assumes power, connectivity, a working sensor and a reachable server has four ways to become useless, and each one is a decision somebody made.
- A mechanical key opens a door when the battery in the lock is dead.
- A window opens when a ventilation system is off.
- A printed schedule remains readable when a display is dark.
The Escalator
An escalator that loses power becomes a staircase. The treads are stair-shaped and stair-sized because they were engineered to carry standing weight, and the handrail remains at the height a hand expects. A person walking onto a stopped escalator changes their gait and continues.
Nothing about this is accidental. Tread depth, riser height and handrail placement are specified so the stopped condition is safe to walk. The comparison case is a powered door that seals shut, or a hotel lock whose dead battery leaves no mechanical path to the room.
An escalator that fails well does not need to:
- Announce that it has stopped
- Be repaired before people can pass
- Trap anyone on it
- Be operated differently while stopped
The same logic applies to software. A connected thermostat that holds its last schedule during an outage keeps a house warm. One that reverts to a default or waits for a server does not.
Just as a stopped escalator is still a staircase, well-designed technology retains its core function when the parts that make it convenient are gone.
Categories
- Pass-Through Technologies
- Principles of Calm Technology
- I. Technology should require the smallest possible amount of attention
- II. Technology should inform and create calm
- III. Technology should make use of the periphery
- IV. Technology should amplify the best of technology and the best of humanity
- V. Technology can communicate, but doesn't need to speak
- VI. Technology should work even when it fails
- VII. The right amount of technology is the minimum needed to solve the problem
- VIII. Technology should respect social norms
- Papers on Calm Technology
- Podcasts on Calm Technology
- Calm Tech Example Book Development