Open the Hood to Check a Flat Tire: The Def/Use Granularity Mismatch
Your dashboard lights up. One amber icon, vaguely engine-shaped. You don’t know if it’s the oil, the transmission, an emissions sensor, or something that will leave you stranded in ten miles. To find out anything more specific, you open the hood and look for a dipstick — for many drivers, an act with its own quiet dread, performed rarely enough that every time feels like the first time.
Meanwhile, on the same dashboard, a tire pressure light comes on. Somewhere under the car, four independent sensors already know exactly which tire is low and by how much. The dashboard shows you one icon. Not which corner. Just: a tire, somewhere, is wrong.
Two failures, and they are not the same failure. One is a calibration problem — how much detail should the panel show. The other is not a calibration problem at all — it’s data that already exists, generated by hardware already installed, that simply never got wired the last six inches to the display.
The Granularity Knob
Every interface sits somewhere on a dial between two failure modes, and both ends are real engineering decisions, not accidents.
Too coarse: a dishwasher’s error display says E07. That’s it. Somewhere behind that code is a specific fault — failed water inlet, blocked drain, dead heating element, stuck door latch — but the panel collapses all of them into one undifferentiated number you now have to look up in a manual or search for online. The machine knows more than it’s telling you. It just decided you don’t need to know.
Too fine: a commercial aircraft cockpit has a dedicated gauge, light, or readout for nearly every independently monitorable system — hydraulic pressure per circuit, individual engine parameters, cabin pressure differential, each one its own instrument. This isn’t excess. A type-rated pilot has hundreds of hours of training specifically on this layout, and in aviation the alternative — quietly aggregating faults behind one summary light — is itself a known failure mode, because the one thing worse than too much information is a single point of abstraction that fails silently.
Both panels can be correct for their Use side. The cockpit is calibrated for a trained operator who needs raw signal, continuously, with no resolver standing between sensor and eye. The dishwasher is calibrated, in principle, for someone who wants clean dishes and no manual. The failure isn’t that one shows more than the other — it’s that most consumer products get this calibration backwards, hiding detail that a two-second glance could use, while burying eleven settings nobody asked for one menu deeper.
“Which Tire” Is a Different Kind of Failure
The tire pressure example doesn’t belong on the granularity dial at all, and that’s what makes it worth separating from the dishwasher and the cockpit. It isn’t a judgment call about how much detail the driver can handle. The Tire Pressure Monitoring System has four sensors. It already knows, to the corner, which tire is low. The information exists, at full resolution, inside the car, right now.
What’s missing isn’t a decision about complexity. It’s six inches of wire — or rather, six inches of software — between “the system already knows this” and “the icon shows you this.” Someone built four sensors. Someone built one icon. Nobody connected the second one to the full output of the first.
This is the cleanest version of the whole problem because it has no good excuse standing behind it. The dishwasher’s E07 might be a real cost tradeoff — a richer display costs money, and maybe the manufacturer judged correctly that most owners would rather call a technician than read a fault code. The cockpit’s density is justified by who’s sitting in the seat. “Which tire” has neither justification. The resolver was simply never built, even though every piece required to build it was already sitting in the car.
Open the Hood to Check a Flat Tire
Here is where the car’s design fails hardest, and it isn’t really about tires or oil individually — it’s about which problem gets routed to which body part.
A flat tire is visible from outside the car, often audible, and diagnosable by anyone who has ever looked at a wheel. It needs no hood, no manual, no specialist knowledge. But the dashboard light for low tire pressure looks structurally identical to the dashboard light for low oil — same shape of icon, same amber colour, same vague “check engine” register — and the only path the car gives you to investigate either one is the same path: open the hood.
So the driver who sees a tire warning and a driver who sees an oil warning are handed the identical next action, even though one problem is solved by looking at a wheel and the other requires opening a compartment many people have never opened, locating a dipstick by feel, wiping it, reinserting it, and reading a level against two marks they were never taught to interpret. The car’s interface didn’t just get the granularity wrong in one direction or the other — it merged two problems with completely different correct responses into one shared escalation path, because building two different escalation paths is more work than building an amber light.
For a driver who already knows engines, opening the hood is nothing. For a large number of drivers, it is something closer to performing minor surgery on a machine they don’t understand, for the first time, on the side of a road, possibly in the rain. The dashboard’s silence about which problem this is doesn’t just withhold information — it forces the more frightened response onto a problem that may not have warranted it at all.
Same Root, Three Different Shapes
The dishwasher, the cockpit, and the car aren’t three unrelated examples — they’re three shapes the same underlying gap can take, depending on what got built and what got skipped.
The dishwasher under-resolves what it knows: a specific fault collapsed to a meaningless code, because building the lookup table from fault to plain description felt like someone else’s job.
The cockpit is calibrated for a different Use side entirely — dense, correctly, because the person reading it was trained for exactly this density.
The car does something neither of the others does: it has the resolved, specific, correct information sitting right there in the tire sensors, and routes the driver around it anyway, merging it with an unrelated problem and sending both down the same path — the one path most likely to be unfamiliar and unwelcome.
None of these are about whether engineers or designers are to blame, and none of them are solved by “more options” or “fewer options” as a blanket rule. Steve Krug’s old rule — don’t make me think — is usually read as a plea for simplicity. It’s better read as a plea for the right resolver: a driver glancing at a dashboard at 120 km/h should not have to think about which subsystem an icon refers to, the way a pilot, trained for exactly this density, is expected to think continuously about every gauge in front of them. The thinking isn’t eliminated. It’s relocated to whoever is actually equipped to do it — sometimes the engineer who builds the resolver in advance, sometimes the trained operator for whom raw signal is the correct interface, never the unprepared person standing at the open hood in the rain.
And again, the user does not sux. The owner who can’t decode E07, the driver who’s never opened a hood and never wanted to, the person standing over a coffee machine wondering why their cup just overflowed — none of them failed to learn something they should have known. In every case the system already had the information, or could have had it for the cost of wiring four sensors to one display instead of one. The discomfort lands on the person at the panel only because nobody upstream built the six inches of resolver that would have let it land on the system instead.
They’re solved the same way every muddy waterline in this series gets solved: find out what the system already knows, find out what the person in front of it actually needs in the next ten seconds, and build the six inches of resolver in between — instead of either hiding the data behind one light, or handing over the full parts list and calling it a feature.
This post is part of the Gutenberg/Semantic series. Related: Nothing Is Confusing to Me: The Inmates Are Running the Asylum on engineer Def-Push exposing the internal model directly, and Every “Where Is the Close Button?” Is a Bug on the gulf between what a system can do and what a person in front of it can find.