We have a scenario where we need to call an API so that the user can draw something on the screen. The following scenarios are possible:

  1. API call goes quickly and is successful: user draws a new object on the screen with no obvious delay.

  2. API call goes quickly and is unsuccessful (rare but can happen, e.g. if 3G data drops out for a moment): user tries to draw a new object on the screen, but gets fast visual feedback that this has not happened. At this point they can try again immediately and don't necessarily need an error explaining what happened or that they can try again.

  3. API call goes slowly but is successful: user is able to draw an object on the screen but there is an appreciable delay (we hope this is rare, but we need to concede that it might happen). The interaction would feel 'laggy'.

  4. API call goes slowly and is unsuccessful: user waits longer for visual feedback before eventually discovering that they need to re-attempt drawing the object.

We could get around the uncertainty of latency and API call success by letting the user 'successfully' draw on the screen in the client (i.e. making the interaction more responsive), and letting the API call and response happen behind the scenes. However this would necessitate an error message when the API call has failed: we would have to let the user know "yeah, sorry, that drawing on the screen you just did? Not so much."

So my questions are:

a) How long is too long for 'drawing on a screen' response latency?


b1) Should we prioritise making the interaction fast (i.e. execute it in the client and make the API call behind the scenes, with a chance of having to show an error message that says "uh, we kinda lied, you didn't draw that thing")


b2) accept that occasionally it will be slow and that users will just have to try drawing the thing again? (doesn't seem very onerous and will probably not happen very often)

  • Please check related question ux.stackexchange.com/questions/58163/… Commented Aug 12, 2015 at 8:39
  • 1
    Can you store the drawing client side? If so, than why bother the user with failed attempts to send it to the server?
    – jazZRo
    Commented Aug 13, 2015 at 11:20
  • As @jazZro commented can you store the drawing client side. Then maybe sync asap across the API. Being so dependent on a connection sounds like asking for trouble to me whether the API is response or not. Commented Aug 13, 2015 at 15:21
  • @jazZRo We did have this conversation in the team; what that does is introduce the need for error messaging if/when the API call is ultimately unsuccessful (e.g. after multiple attempts). I was hoping to avoid visible error states and unnnecessary user perturbation if possible, I guess. Commented Aug 18, 2015 at 11:19

6 Answers 6


Standards for wait times

Microsoft has published standards for what your software can/must do during the first few seconds of wait time.

You can begin reading the guidelines under the heading Is this the right control on this page (about progress bars) in the Microsoft Windows UX Guidelines. Please disregard that this topic is about progress bars, since the "Is this the right control" section actually links to the guidelines for the alternatives.

As you noted in a comment elsewhere on this page, Microsoft isn't too absolute with the boundaries between wait times that are short, acceptable, and too long.

And absolute values might be an unhelpful yardstick, because a lot depends on the context. There's plenty of research that shows that the duration of actual wait time and perceived wait time can differ greatly. If you can make people feel like something happened quickly, then you don't need to take the same measures that you would take if users perceived it to be quite slow.

You want me to wait How Long?

Fluid standards may be more helpful

As a starter for additional reading, try Wikipedia on Time perception, search the Internet, or try the book Designing and engineering time by Steven Seow, or, for a more general interest, try Faster: the acceleration of just about everything by James Gleick.

What do I do?

Notwithstanding that I just recommended a fluid standard, I often tell developers this, as the line we cannot cross:

  • Within 4 seconds the system MUST provide feedback. Ideally, the feedback is simply to Quickly Do The Task That The User Wants To Do.
  • If it's longer, let's think of ways to trick the user, by giving them something meaningful to look at while the processing happens in the background, or in stages.

It seems that you're already leaning towards the second option there, and I agree with you. Causing delays is better than creating complete frustration.

Either way, users react differently to slow responset times, as Jakob nielsen puts it:

Response-Time Limits

The 3 response-time limits are the same today as when I wrote about them in 1993 (based on 40-year-old research by human factors pioneers):

0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation (direct manipulation is one of the key GUI techniques to increase user engagement and control — for more about it, see our User Interface Principles Every Designer Must Know course).

1 second keeps the user's flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.

10 seconds keeps the user's attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it.

After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.


I suppose you could use these time frames to display throbbers or different messages as things load up, letting the user know what's going on and that the wait will pay off.

  • Thanks. I guess the real question is, what happens in the range 1-3 seconds? That's where things start getting really interesting … :) Commented Aug 4, 2015 at 14:39
  • 1
    Come to think of it, in this specific interaction (drawing) I believe the user needs immediate feedback, no matter what's going on backstage. Instead of giving an error message and making the user draw again (b1), can't you simply add a "reload" button that attempts to do an API call once again with the same drawing? Commented Aug 4, 2015 at 16:40
  • 1
    In the 1-3 seconds mark, the user knows the computer is "thinking", so they tend to be more lenient, you just have to give some feedback. As I suggested earlier, a throbber should do the trick. Commented Aug 4, 2015 at 16:42
  • 1
    Microsoft has published standards for what your software can/must do during the first few seconds of wait time. You can begin reading the guidelines under the heading Is this the right control on this page: msdn.microsoft.com/en-us/library/windows/desktop/dn742475.aspx Please disregard that this topic is about progress bars, since the Is this the right control? section links to the guidelines for the alternatives.
    – JeromeR
    Commented Aug 11, 2015 at 1:45
  • 1
    @JeromeR That is a great resource, thank you so much! I note that they are very non-specific about actual amounts of time, but the principles stand regardless. It's too bad I can't accept that answer for this thread because it came in a comment … Commented Aug 18, 2015 at 11:35

First, you might reconsider the framing of the problem. The way you described it, if the user draws an object but the server doesn’t receive it, then the object was never drawn. From a UX standpoint this is precisely backwards, a system-oriented way of thinking. UX is user-centered.

The system is not the authority, the user is. An object is drawn as soon as the user draws it. He performed all the right actions and saw all the right feedback, so the case is closed and the user’s job is done—no waiting involved. If the system isn’t up to date on the facts, that’s the system’s problem.

If the system can’t self-correct in a timely fashion, the user must be notified. But he shouldn’t have to re-draw anything, or perform any further action. Instead, the system should attempt to re-send the drawing. There’s no reason to punish the user for the system’s shortcoming by making him do the same work over again.

If the nature of the product is highly timing-sensitive and users need quick feedback, you could use a combination of well-timed animations for a “sleight-of-hand” effect (animations that take up time while latency-intensive operations are happening) and the “skeleton screens” concept (LukeW: Mobile Design Details: Avoid The Spinner) to cover over latency-related issues for a few seconds. This helps prop up the illusion of a flawless system in the mind of the user, and prevents him from worrying about technical details that have nothing to do with him.

  • 3
    "But he shouldn’t have to re-draw anything, the system attempt to re-send." That statement is key. Drawing for the user isn't about making a connection between point A to point B. It's about putting ink/color on a canvas to depict something. A system that stops the user between strokes is interfering with the drawing process. It's a much better experience to implement a "syncing" vs "up-to-date" indicator like how Google Docs/Sheets does. Only if a catastrophic error happens should the system regretfully inform the user that their data is lost.
    – nightning
    Commented Aug 10, 2015 at 20:00
  • Absolutely agree with all of this — wherever possible we should strive to make it not the user's problem. Really what I am trying to understand is how to cope with error states where it is likely that the error state will continue (API unavailable, etc). I'm nervous about loading too much of this onto the client; users may lose a lot of work if the client cannot sync for a long while, but is giving no feedback about this to the user, so they carry on working. It's a cross-platform service so they expect changes to stay up to date and follow them around (e.g. onto mobile). Commented Aug 18, 2015 at 11:41

I think it's vitally important there be minimal latency in operations like drawing (or any mouse driven operation), so I propose a third option: perform the draw operation immediately (on the client) but indicate that the drawn object is in a pending state. The pending state can be indicated by having the object grayed out or a special color or a special background or....? When the confirmation comes back from the server the object's visuals simply change to indicate "normal object/not pending".

The important things accomplished by this are:

  1. immediate response to UI interactions
  2. the status is very obvious (what's pending and what's not).

The user should be able to inspect pending objects (find out how long they have been pending) and possibly resubmit them.


Perceived lag = latency + framerate

Response timings described by Nielsen is something different than perceived lag. While waiting for a page to load, user is expecting to see some delay and is not providing any constant input.

While drawing a picture, user is providing constant input and is expecting immediate response.

  • User is going to notice lag when one of these happens:

    • framerate drops below 12fps
    • latency is higher than about 200ms

If your requests are going to cause one of these to happen, you should choose an option to do it behind the scenes.


Humans are very sensitive to noticing latency and framerate. Users would start to notice that drawing is laggy even after relatively short delays.

There are multiple scholarly articles about a treshhold when latency becomes noticeable. Interestingly, this is different different for audio and visual latency. While for some people 100ms latency for visual output can be acceptable, 10ms makes it already difficult to play an instrument.

https://en.wikipedia.org/wiki/Input_lag Testing has found that overall "input lag" (from controller input to display response) times of approximately 200 ms are distracting to the user.

https://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay The 100 ms threshold was established over 30 yrs ago.


https://en.wikipedia.org/wiki/Limited_animation For movements in normal speed, most animation in general is done "on twos," meaning each drawing is displayed twice, for a total of 12 drawings per 24 frames per second. Faster movements may demand animation "on ones" with a new drawing in each frame.


Besides handling the delay as it happens I think it would be good to let the user know of the connection quality early on. A good example for this is when calling someone on Skype. With this the user is prepared to expect a delay based on their connection strength rather than get caught off guard while they are working on something.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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