Will forcing response time to the average time as a minimum improve UX?

Question

I have a situation where my Ajax call response time could vary from 14ms to 600ms, because of the complexity of a Query they could make.

From my experience Users take for granted those 20-80 ms round trips and expect to have the same speed all the time and everywhere, in reality in my particular project it is impossible.

So I came up with an idea that I could force users always wait for at least some x amount of time before getting results.

Question is: Should I use an average of my own data of response round trip lengths already gathered or should I just use a publicly agreed highest allowed response time to a Users action?

From what I can remember that was somewhere between 100 - 200 ms I can't remember now.

Answer 1

You should not artificially delay how long a user must wait. Do not punish a rapid response by slowing them down to an "average". Let all queries complete naturally, for longer query times you may want to consider the following...

Jakob Nielson did some research on wait times back in 1993. From "Response Times: The 3 Important Limits" -

(1) 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

(2) 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

(3) 10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done.

These numbers would show that your expected average (100-200ms) wait time would generally not require any additional feedback to the user in order for them to perceive it as "instantaneous". Even with wait times up to 1.0 second no special feedback was normally required, even though the user may "lose some feeling of operating directly on the data."

It is important to note that the study, and the above times, are not associated with interactions on the web! These numbers represent raw wait times for user engagement. Don't fall into the "this data is so old, the web was so young" trap! The above isn't "on the web", it is basic "how long will a user wait until they become disengaged" on a task.

What does that mean? At worst it means take the numbers as they are (web users expect faster and faster response these days). At best it means you have a little extra room because users will give you a little extra wiggle room on the web.

In fact, Nielson kept getting questions about "what about on the web" and updated the answer slightly in 2014:

0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column — if so, users would feel that they are sorting the table. (As opposed to feeling that they are ordering the computer to do the sorting for them.)

1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.

10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks.

Still, with your expected averages, a user will feel that they are "directly manipulating" the data or will notice the delay but do not necessarily need to be informed as they "feel the computer is 'working' on the command." Only if your queries are taking over (or regularly close to) 1.0 second would a notification be necessary.

But that might not be the whole story. A NYTimes article, "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait" discussed work being done by Google and Microsoft on how long users are willing to wait for a page when "like services" are available.

From the article:

People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds (a millisecond is a thousandth of a second).

This doesn't tell you to include a notification or not, but does point out how important response times are to users! If you artificially inflate wait times you'll potentially be pushing users to a competitor!

Answer 2

Over 30 years ago I was what at the time we called a systems programmer, looking after a minicomputer network with a few dozen users. In those days, the displays were essentially 80x25 "text only".

When we upgraded the comms links between the minicomputer and the displays, several users started complaining that the system was slower, even though we knew nothing had changed at the server end, and the links themselves were actually many times faster. We also knew that at times of low system load, the original comms links were often the main bottleneck.

It turned out the faster link was causing each "packet" of display data (512 bytes, being less than a 2K screenful) to arrive and be displayed well before the next packet arrived. Even though total throughput was actually faster, these visible pauses gave users the impression it was slower. In the short term we reconfigured the original slower comms link speed for any users who complained, until we could add memory at the server end (cripplingly expensive at the time) allowing us to increase the link packet size.

I know this doesn't exactly mirror OP's circumstances, but I think it's part of a general principle that users' perceptions of "responsiveness" are always "relative". Our users didn't mind a screen taking 6 seconds to display when it filled up at a constant speed, but they didn't like seeing 4 "chunks" displayed instantly at 1 second intervals.

By the same token, I think if some queries produce "instant" responses, users are more likely to classify all other queries as "slow", because they'll compare against the fastest thing they see, not the average. It's probably relevant to note that I'm assuming most users won't have much idea of which queries they might expect to be faster or slower (if they did, that might change things).

Answer 3

I like the accepted answer and I agree that you should not artificially delay anything.

However, given your expected wait times, I'd do what you can to improve perceived performance. For instance, showing a spinner while the results are loading helps. But according to this study, it's optimal to wait 0.4 seconds before showing the spinner.

There's another technique I like to use at times. If clicking a link or button ultimately results in showing a new page or interface, then go ahead and take the user to that page immediately while the data is loading in the background. That way the user sees something happen right away, and then maybe the data fills the new interface half a second later.

In general, any time you can create instant visual feedback will help improve the perception of speed and responsiveness.

Answer 4

There does exist some research suggesting that, at least for certain types of applications (real-time strategy games, to be exact), users may find a slow but consistent response time preferable to a unpredictably varying one.

Specifically, let me quote from the article "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond" by Mark Terrano and Paul Bettner (emphasis mine):

"For RTS games, 250 milliseconds of command latency was not even noticed -- between 250 and 500 msec was very playable, and beyond 500 it started to be noticeable. It was also interesting to note that players developed a "game pace" and a mental expectation of the lag between when they clicked and when their unit responded. A consistent slower response was better than alternating between fast and slow command latency (say between 80 and 500 msec) -- in that case a consistent 500 msec command latency was playable, but one that varied was considered "jerky" and hard to use.

In real terms this directed a lot of the programming efforts at smoothness -- it was better to pick a longer turn length and be certain that everything stayed smooth and consistent than to run as quickly as possible with occasional slow-downs. Any changes to speed had to be gradual and in as small increments as possible."

While this effect might be particularly noticeable in games, I see no reason to assume that it could not occur in other applications as well. Indeed, it seems to match well with FumbleFingers' minicomputer anecdote, suggesting that there may well be a more general effect at play here.

Answer 5

One case where it can be beneficial to add a delay is when the user may not otherwise realise something has changed. I've implemented it before on a site - we already have the query results ready, but if we change it without a delay, the user probably won't realise that a change has occurred. So we add a fake delay with a brief "loading" animation.

Though the delay in this case should be very small - just enough for the user's brain to think "oh something's changing!", and by the end of that realisation the content has changed.

Answer 6

While I agree completely with the accepted answer, and it's already late, I'd like to offer another perspective, focusing rather on the "perceived waiting time" (i.e. behavior problem), instead of the "real waiting time" (i.e. engineering problem).

This Signal vs Noise article cited the classical example of managing the perception of waiting time. Just adding a mirror in the elevator completely removed the enormous number of complaints from people about how slow the elevator is. Having mirrors helped those waiting could look at each other or themselves and hence reduced the boredom associated with the waiting.

Steven Seow's book Designing and Engineering Time: The Psychology of Time Perception in Software provided a lot of very interesting insights about the psychology of waiting and how to manage user perception's of waiting.

This newly published article cited several of those insights. In particular, of the most relevant to your question are:

• Rule 1: Never let your users watch the soup come to a boil: Look for places where your users wait and attempt to fill that time with something meaningful.

• Rule 3: Provide transparency throughout the process: Ensure they know how long the wait will be by using numbering systems or systems to let them know where they are in the process.

• Rule 4: Set goals you can meet or beat: Underpromise and overdeliver to lower expectations and then exceed them. Restaurants are famous for slightly overestimating the wait time. They do this so they are sure they will meet their estimate or possibly even beat it.

• Rule 5: Carefully design the beginning and the end of the process: Evaluate what your user sees or experiences when they encounter your product, service or interface for the first time and how the experience ends for them. Memories of events are heavily shaped by the beginning and ending of the event.

So, in directly answering your question: Will forcing response time to the average time as a minimum improve UX?, I'd say no. Forcing it won't improve UX.

However, applying rule 4, you could possibly give users an over-estimated number, and then deliver the results before that. Combining it with other rules, and your users will even possibly feel good about waiting. :)