Why is the elevator button panel a UX disaster?

Any office lobby at 8:52 a.m. Twelve people, two panels, one small illuminated triangle pointing up. Somebody presses it. Somebody arriving ten seconds later presses it again, harder, because pressing an already-lit button is a universal human reflex nobody has ever been talked out of. Then everyone stares at the seam between the doors, doing arithmetic they have no data for.

The reflexive answer to "why is it like that?" is because elevators are old. Dead end. The control system behind that wall is networked, load-sensing, and running a dispatch algorithm that would have been a research paper in 1990. The interface is the part that didn't move. So: which decisions produced this panel, and which of them are still true?

1. Three people in front of the same doors

Refuse the generic user. "Someone who wants to go up" is not a person. Three who are:

• A courier with a loaded hand truck at the dock. Both hands committed. He needs to know whether to wait here or take the freight car around the corner, and the only thing he wants from the interface is a number: how long? He'll happily walk ninety seconds to avoid waiting a hundred.
• A hotel guest on floor 24, checkout morning, suitcase in hand, flight in three hours. Every car that arrives full and leaves without her is a small crisis. She doesn't want a faster elevator; she wants to stop feeling the risk.
• A resident carrying groceries and a toddler's hand. She needs to pick a floor with no free finger, and she needs the doors not to close on a small slow person behind her. Her failure mode isn't delay, it's panic.

Three products wearing one word. The courier wants an estimate. The guest wants a guarantee. The parent wants a way to operate the thing with no hands. Only one cares about speed, and none are served by a lit circle.

The amateur designs the panel. The professional notices there are two panels, serving two different decisions, and that only one of them is in a queue.

2. The obvious job is not the job

The obvious job is "move me vertically." True, useless, discriminates between nothing. The jobs that create trade-offs:

• Help me decide whether to wait — a decision made in the hallway, with zero information, before the product has done anything.
• Get me there without stopping six times — not about speed at all. In a mid-rise, most of the trip is doors opening and closing for other people.
• Let me operate you with what I've got — an elbow, a knuckle, a cane, a seated reach, no hand at all.
• Make a small shared box with strangers survivable — which is why the mirror is load-bearing.

These conflict, and the conflict is the story. A car that never stops for anyone else is a car that never comes for you either. Every passenger is simultaneously a customer and a source of latency for every other customer. Hold that thought.

3. The pain point we all normalized

Here it is: you press the button and receive an acknowledgement instead of an answer. The light means your call was registered. Not that a car is coming, or when, or which one, or whether it will have room.

Compare that to every other queue in your life. Your rideshare crawls toward you on a map. Your food has a progress bar and a courier's name. The bank tells you you're seventh. Your package has a four-hour window. We rebuilt the consumer internet around one insight — uncertainty hurts more than duration — then walked into the lobby and accepted a light bulb.

And the elevator, unlike your food delivery, isn't guessing. It's a closed system in a fixed shaft with a known top speed, known dwell times, a known list of pending calls, and a load cell reporting how full each car is. It is the only queue you stand in that has near-perfect information and discloses none of it. That gap — not the wait, not the crowding — is the actual product failure, and almost nobody notices, because we decided long ago that elevator waits are weather.

The famous fix is instructive precisely because it isn't one. The story every UX class tells — a building drowning in slow-elevator complaints installs full-length lobby mirrors, and the complaints stop — is part folklore, but the mechanism is real: occupied time feels shorter than unoccupied time. The wait didn't shrink by a second. It was given somewhere to go. A legitimate move, and also a confession: we chose to manage the feeling because we never considered disclosing the fact.

4. Trace every feature to its constraint

Nothing on this panel gets to be "just how it is." Take it apart:

Notice how little of that was a free choice. Button size: code. Dwell time: code. Floor numbering: a landlord and a superstition. Panel height: the reach envelope of a seated user. Most of what looks like design is a set of interfaces to systems you don't control — and here, one of those systems is the other passengers.

That last one is the transferable prize. Almost every interface you've designed is single-player: your user's input affects your user's outcome. The hall button is multiplayer — a shared queue where each person's perfectly reasonable input taxes everyone else, and where optimal system behavior and optimal individual behavior diverge. If you've run a shared CI queue, a multi-tenant database, or a Slack channel ten teams treat as their help desk, you have shipped an elevator panel. You just didn't know to look for a tragedy of the commons in the input design.

If your users can degrade each other's experience through the interface, you are not designing a screen. You are designing a policy, and the screen is where you enforce it.

5. Break a constraint on purpose

The most consequential constraint on that list is the sequencing one: the elevator is the only vehicle you board before saying where you're going. A taxi asks at the door. A bus makes you pick the route before you step on. The elevator inverted it, and every downstream inefficiency — the guessing algorithm, the stop on floor 4 that isn't yours, the car that arrives full — descends from collecting intent after the user has already committed.

Break it and you get destination dispatch: enter your floor at a lobby kiosk, and it tells you to take car C. The system can now group passengers by destination and slash stops per trip. Vendors report handling-capacity gains on the order of twenty to thirty percent in busy buildings.

Here's the part worth sitting with. That twenty-to-thirty percent is not an engineering achievement. No car got faster. No shaft was added. The whole gain came from moving one input earlier in the flow — a form-field decision. A building that would otherwise need another elevator, at the cost of a structural core and years of construction, instead needed a better question asked at a better time. Capacity problems are very often information problems in disguise, and the tell is a system working hard to guess something a user would have told you for free thirty seconds earlier.

Then the honest footnote, and the second surprise: people frequently hate destination dispatch. It optimizes the building while making the individual experience feel worse — you sometimes wait longer in the lobby, you're assigned a car rather than choosing one, and in the purest installations there are no floor buttons in the car at all. The system removed the ability to change your mind. An aggregate win that reads to each user as a loss of agency is exactly how a metric-improving launch gets rolled back.

Five elevator interfaces that don't exist yet

Each of these comes from relaxing one named constraint — which is exactly how you close a strong interview answer:

1. The ETA button. Constraint broken: the hall button is input-only. Seconds-to-arrival count down in the ring around the button. Trivially possible today; nobody ships it, and the reason isn't technical. A displayed number is a promise, and promises generate complaints when they're wrong. The industry chose no ETA over an occasionally wrong one — the same trade you make every time you leave a progress bar indeterminate.
2. The declared arrival. Constraint broken: intent is collected at the panel. A badge, phone, or QR code at the entrance registers your floor while you're still crossing the lobby. Destination dispatch without the kiosk queue — and with a visitor path that needs no app, the way a gate number works for someone who's never flown that airline.
3. The no-hands car. Constraint broken: selection requires a free fingertip. Floor pads underfoot, a spoken floor number, proximity selection as you step toward a numbered zone. The pandemic briefly produced foot-pedal panels and then removed them — which tells you they were framed as hygiene rather than access. They were always access. The courier and the parent were there the whole time.
4. The renegotiable ride. Constraint broken: a dispatched destination is final. One "actually — " control in the car that amends your floor once, at a modeled cost. Undo is often the difference between a system that's efficient and a system people will tolerate being efficient.
5. The transparent shaft. Constraint broken: the shaft is opaque. A vertical light strip beside each set of doors showing all cars moving in real time, like a subway platform's train diagram. It promises nothing, so it can't be wrong, and it turns an anxious unknown into a glanceable fact. The mirror trick done honestly: instead of distracting you from the wait, it lets you see it.

None of these is the answer. The transparent shaft suits a mid-rise full of short anxious waits; declared arrival suits a tower with a brutal morning peak. A strong answer shows the map, picks a point, and says which user it favored and who it left behind.

The transferable skill

Two thousand words on a light-up circle, but the object was a vehicle. The loop is the point:

1. Name the user and the moment. The courier, the guest, the parent — never "a passenger."
2. Separate the obvious job ("go up") from the jobs that create trade-offs ("help me decide whether to wait").
3. Find the friction everyone stopped noticing — here, an acknowledgement standing in for an answer the system already has.
4. Trace each feature to its constraint, and flag which constraints are interfaces to systems you don't control: code, the landlord, the hand, the other passengers.
5. Break one on purpose. Ask for the destination earlier, and watch a capacity problem turn out to have been an information problem.

Run it on your own product this week — on your inputs specifically. Find where your system spends real money inferring something a user would have told you for free, one screen earlier. That's your destination dispatch. Then check whether asking earlier takes away anyone's ability to change their mind. That's the part the elevator industry got wrong, and the part that gets launches reverted.