10

Have there been any studies, or results, focusing on the impact of variability in latency of response times on the overall user experience?

I'm aware of the research on the "generally accepted" recommendations (100ms for instant, progress indicators for 1s+, etc.). However, what I'm curious to know is specifically the perceived performance difference (if any) between cases like:

  1. consistent 500ms response time for all interactions
  2. average 300ms response time with +/- 200ms variability

Is (1) preferable to (2), vice versa? If either, in all cases? Etc. Of course, 500ms and 300+/-200ms are arbitrary stand-in values.

| improve this question | |
  • possible duplicate of Should aspects such as page render time or time taken to retrieve results be considered part of UX? – Benny Skogberg Dec 19 '12 at 7:16
  • 2
    I'm not sure this is a duplicate. This question is specifically asking about research, whereas the linked question is about whether or not response time counts as UX. Similar issue, but a different approach to each question. – JonW♦ Dec 19 '12 at 8:55
  • @JonW That's true, but in the answers of the possible duplicate there are some answers from research reference. Or should one post them here as well? – Benny Skogberg Dec 19 '12 at 14:37
  • They are still useful answers. They could be referenced in answers here, because they are valid sources. However they shouldn't be copied and pasted - feel free to use the citations and link to those answers though. We can't migrate them across to this question because they'd lose the score achieved on that post. – JonW♦ Dec 19 '12 at 16:00
2

Do you want to feel that the application you're using is generally slow or slow for the actions that one could expect to take a long time to execute..?

I would like to compare it to two different real world examples.

  • If the bus is always late, you can adjust your schedule/timing so that you're right on time even though it's always late. You as a user of the bus is unaffected, because you can adjust.

However, the bus runs its own schedule, unaffected by any input from the commuters. So even though it could work in a bus scenario, it doesn't apply to a user interaction scenario.

Instead think of it as what it is, a request and a response.

  • If you order food from a restaurant, do you want the quick dishes to be prepared and served in the time they take to make? Or do you want the time to be consistent for all dishes, ie the quickest dishes are served in the same time as the advanced dishes? If you ordered a plate of fries, do you want it to take the same time as if you ordered a sea basket?

Sure, if you're a party you would prefer if everyone gets served at the same time, but that has more to do with a code of conduct and is not very applicable here. If you order something fast by yourself you want that damn food to be served when it's done, not to be delayed as if someone you were with ordered the most advanced dish on the menu.

I would argue a user of an application is the same, at least I am. I realize a customized search for items takes time to perform, and that's OK. However, when I view an item in the search and then go back to the search results I don't want to wait the same time again as it took for the initial search. As a user I would feel, -Hell, there's no need for this to take this long?! Why is it doing this to me?!

So keep execution times to the actual time an individual action takes to execute, no need for unnecessary waiting.

| improve this answer | |
  • You make some good points, but I can't upvote because the OP is specifically asking for research and sources. This answer would be better suited to the linked question, really, where it's not so focused on research. – JonW♦ Dec 19 '12 at 16:01
  • @JonW hmm... it's in the ball park, but it looks like another game... that question is more regarding whether execution times should be taken into account when designing in the name of good UX (which I'm positive it should). My post is regarding why it's a good thing trying to keep the wait minimal, and why pondering whether to keep execution times consistent disregarding the actual time an action takes to execute is not. I see why you can't vote this up, it's really just my own reasoning with no facts behind it. I just liked what came out when I thought about it so that's why I posted it! =) – AndroidHustle Dec 19 '12 at 18:53
  • Neither analogy answers the actual question. One way to rephrase my original question with your bus analogy is: is there any data indicating that users would prefer to be slow-ish, but arrive at fairly predictable times, or would they prefer potentially faster arrival, but a much higher probability of arriving late? I can make up good arguments for both, but what I want to see is quantitative data.. And more importantly, my guess is it's not a binary answer. Hence, where is that elbow point on the curve? How much variability is "acceptable"? And so on. – igrigorik Dec 20 '12 at 5:57
  • @igrigorik I'm sorry but I think you're totally off. It's not a matter of completing something in a predictable time or being late. You can't compare a request and response to a bus ride/transit, they are operations of two totally different types. A bus ride somewhere usually involves planning of what you're going to do when you arrive, and then of course it's good to have an accurate idea of when that is, we're talking several minutes/hour(s) here. In applications you do something and you idle until you can make another operation, request and response. All you do is wait until you can proceed – AndroidHustle Dec 20 '12 at 8:17
  • @igrigorik Just out of curiosity, what good argument do you have for letting actions take a longer time to perform than they actually need? – AndroidHustle Dec 20 '12 at 8:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.