Perceived Response Time from a Developer’s Perspective

One of the most cited usability problems is when the actual implementation response time is very different from the perceived and expected response time. In most cases, the implementation response time is slower than expected.

Yesterday I had an interesting observation to the contrary. As a developer, I understand what the “actual” implementation response time should be, because I understand the runtime complexity of an operation and can bring into consideration other factors such as network latency and server load. On the other hand, the “average user’s” perceived response time might be significantly lower or higher than the implementation response time.

In this case, I would feel uncomfortable with a certain application even if works faster than it should, because my understanding of the implementation response time is different from the actual implementation.

One such example is the introduction of local caching to web GMail on mobile devices a couple of days ago. Composing a message with slow network connectivity or archiving a message with slow network connectivity is something I perceive to have a slow implementation, because I imagine that this operation requires a network round trip. However, thanks to local caching, the operation completes instantaneously. My immediate mental response was, “I probably did something wrong and that’s why it completed so quickly”. On the other hand, an “average webmail user” might have a different reaction, along the lines of, “at last!—GMail responds immediately to my commands, as it should have from day 1”.

I assume most of my readers are software developers. Did you encounter this kind of disparity using your own applications or someone else’s applications?