Perceived Performance
Featuring David Maister
An office building got complaints about slow elevators. The owners priced out expensive mechanical upgrades. Then someone installed mirrors in the lobbies instead, and the complaints dropped immediately. The story may be apocryphal in its details, but the principle is well documented: how long something feels and how long it actually takes are two different numbers, and the gap between them is a design opportunity. That insight produced skeleton screens, optimistic UI, and progress bars that quietly accelerate at the end, and research stretching back to operations work in the 1980s on why waits feel long.
For anyone building a product, this is a case about the slowest moment in your user's experience, and whether it is genuinely slow or just feels slow because nothing is communicating that progress is happening. It sharpens what to do when actual speed is expensive and hard to win. What makes a wait feel shorter without lying to anyone, and the hard limit on how far perception can carry you before real engineering has to take over, is the part the app saves for you.
Frequently asked questions
What is perceived performance in design?
Perceived performance is the difference between how long something feels and how long it actually takes, and that gap is a design opportunity. It is why techniques like skeleton screens, optimistic UI, and progress bars that quietly accelerate at the end can make an experience feel faster without changing the underlying speed.
Why did installing mirrors fix the slow elevator complaints?
In the well-known elevator story, an office building cut slow-elevator complaints not by buying expensive mechanical upgrades but by installing lobby mirrors that gave people something to do while they waited. The wait did not get shorter, but it stopped feeling long, which is the core of perceived performance.
How do skeleton screens and optimistic UI improve perceived speed?
Skeleton screens show a placeholder layout so the interface looks like it is loading rather than frozen, and optimistic UI shows the result immediately while the work finishes in the background. Both communicate that progress is happening, drawing on research stretching back to 1980s operations work, often associated with David Maister, on why waits feel long.
What can product and design teams learn from perceived performance?
Find the slowest moment in your experience and ask whether it is genuinely slow or just feels slow because nothing communicates progress, since you can make a wait feel shorter without lying to anyone. But perception has a hard limit, and past it real engineering has to take over. CaseBook turns this into a move you apply to your own product, with an AI coach that reads your answer.