Part Two: The product · Everyday use
Each small delay has a good technical reason. Together they make the product feel like hard work, and people cannot say why.
Nobody decides to make a product slow. A page loads a little more data. A check runs before each save. Someone adds a script to count clicks. Each has a reason and costs a fraction of a second, and on a developer's new laptop on the office network nobody notices.
The customer notices, on a three-year-old laptop on hotel wifi, without having words for it. They say the product feels "heavy" or "clunky." They do not file a complaint about speed. They just reach for it a little less.
The limits are old and well known. Jakob Nielsen set them out in 1993. A response within about a tenth of a second feels instant. Up to about a second, people notice the delay but keep their train of thought. At around ten seconds, their attention goes elsewhere. Most of a product's life is spent between the first two, and that is where the feeling of ease is won or lost.
Speed loses arguments because it is not on any list of features. Nobody owns it, and the next feature always seems more urgent. It holds only when it is written down as a limit: this action, on an ordinary customer's device, in this long. Over the limit is a defect, like any other. Anyone on a team can start this. Time the five most common actions and put the numbers where everyone sees them.
Some work cannot be fast. Then the answer can be. Show the change at once and finish in the background, as long as the screen stays truthful about what is done and what is not.
Therefore:
Set a limit for how long each common action may take on an ordinary customer's device, and treat going over it as a defect. Where the work is slow, answer at once and finish in the background.
In practice. Use the product for a day on the oldest laptop in the office, connected through a phone. Note every moment you waited.
Goes with. Slowness is the kind of trouble FIX WHAT'S THERE FIRST (25) exists for. An ordinary customer's device is found through WORKS WHERE THEY ARE (47), and answering before the work is finished is safe only with HONEST STATUS (82).
Source: Jakob Nielsen, Usability Engineering (1993).