Can higher speeds harm the user experience?

Question

Inspired by "Is coffee a good excuse for a slow application start-up time?" I tried to look for examples where having higher speeds could be bad for the user experience but I couldn't find any.

Are there any scenarios where faster {startup times, interactions, animations, etc} can harm the user experience? Do we always have to optimize looking for the highest speed?

Answer 1

I know some people advocate introducing a deliberate delay after certain actions in order to make it feel like some sort of processing has happened. Consider a 'save' function for example. Even if the system is able to save changes almost instantly without delay, introducing an artificial delay may well instil confidence in the user that their changes really have been saved. This is based on the idea that people are accustomed to computers "taking a while to think" when performing certain actions.

Here's a real-world example of how Coinstar used this idea: Adding delays to increase perceived value: does it work?

Other than this, I'm sure we all introduce subtle delays in one way or another. One example is a dropdown menu that opens and closes based on mouse hover. It is often necessary to introduce a delay so that the menu doesn't open immediately when the mouse pointer passes over it on the way to something else, and equally so that it doesn't close immediately if the mouse pointer accidentally moves away momentarily.

Answer 2

How about Pacman? Surely with computing power these days, you could speed the ghosts and yellow chomper to Superman-like speeds, but then the game would only be fun for those who can click faster than a speeding bullet.

The general rule is that any time you are simulating a graphical interaction or sequence, you must know your audience and render that interaction in a speed optimal for them.

Answer 3

Actually, the "perceived time" is the important subjective UX factor.

But since UX and usability also embraces objective factors (such as effectiveness), slow performance can per definition decrease the UX/usability.

One example of such illogical "perceived time" tasks is the installation process of 5 floppy discs vs the installation with a CD-ROM.

The 10 minutes "active" installation process with 5 floppy discs and all that disk switching were actually perceived as faster (and thus preferred!) over the 5 minutes passive CD-ROM installation with nothing to do other that wait for the progress bar to finish...

The conclusion is, of course, not to slow down our application!
But we cannot judge the UX from the system performance alone. We need to evaluate how the system interacts with the person using it.

Answer 4

I'm intrigued by the question. However, there is one thing I haven't seen mentioned. Very often, the most stunning looking graphical decisions are an annoyance to the audience that does not expect it to be that stunning.

For instance, when I first started with jQuery, I felt tempted to animate EVERYTHING I could find, menubars, dropdowns, loading gifs etc.

However, more recently I found that elderly, or impaired people, actually find menu's that "suddenly dissapear" quite annoying. They just don't expect them to fade out when they take the cursor of it, while trying to read whatever the cursor was blocking.

Now, this might seem off-topic. But I believe indeed that animation and loading speeds work the same way. If something moves quicker than I feel comfortable with, I'll refrain from using it too much ( And yes there are exceptions to those rules ).

I therefore think that Briguy37 is right. It's all about the intended audience.

Also, the windows 7 start menu pops up and hides instantly after a mouse click. That feels natural because you want something from it. However, a program minimized to the taskbar takes a while to popup. Why? Because it might be touched accidentally while reaching for something at the bottom of the screen. Immediately showing the program works confusing in this case.

Bottomline: Interesting question, fun topic, no answer. These decisions must be based on the target audience and the intended purpose the element or software.

Not the answer, just mine.

Answer 5

I think that things should happen in the speed that the user expects them to execute.

In the 386-era, if something happened exactly after you typed or clicked, something would seem to have gone wrong, because almost everything that was done at those computers took a certain time, and users were used to it.

With a new computer, one user would expect things to happen faster, but only to those things that were taking more time than the user would require to perceive it. Example: the program could save the document faster, but if the user couldn't see a change (like a icon changing color, etc) he wouldn't trust that something really happened.

Answer 6

I think the key is the UI feedback. Generally, doing the action faster cannot harm. But giving UI feedback too fast can harm.

I have a few examples.

When I type some letters in Firefox' address bar, Firefox does show me suggestions, but only after a delay of 1 second. This is a good compromise. If I want the suggestions, they come quickly. But showing the suggestions at once would be too disturbing.

In the same vein, things related to mouse position, such as tooltips appearing and disappearing, usually have delays.

On the Mac, activating a menu item — even with its keyboard equivalent — makes the menu blink in blue. If the blink were too fast, it would be unnoticeable, or blinding. Animations are something special. There must be not too many animations, and they must not be too slow. They can be irritating. But some animations help the user understand what happened (where is my window ??).

When I leave my finger on N, key repetitionnnnnnnnn is not just a while loop adding a character at each iteration. Otherwise, after two seconds I would already have a gazillion letters N. The repetition rate is even settable on the Mac.

Throwing a surprise dialog in front of the user is generally a bad practice. However, computers do that over and over. And, in some few cases, it is justified. I am using an application, and I am going to click on something, and the Windows Update dialog jumps in, with two buttons : Restart now and Restart later. If luck is bad, the first button comes where I intented to click, I click, and… bye bye ! The same happens with the keyboard. If I am writing the letter R of “keyboard” just when the dialog jumps in, bye bye ! So a good practice when showing such dialog is to have its buttons ignore action during the first two seconds. Firefox has a similar delay on some controls, to prevent click hijacking.

When you try to authenticate in a system, the system often delays its response on purpose. This intentionally harms your user experience. This is for a — good — security reason.

Slowing pure processing speed on purpose is rarer than slowing UI on purpose. But it can have good reasons too.

For example, Mac laptop computers have an energy saver option, on by default, which makes them run their processor more slowly when on battery.

I think of the telephone. When you hang up, the link is not cut at once. If you quickly take back the phone, you can continue your conversation. I don't know whether there is an intentional delay at play or just a slow process.

When you are in a hurry, the lift doors open and close too slowly. Their engine can certainly make them move much more quickly. Having the lift doors move more quickly would improve the experience of most users. But they would knock out a few fragile things called children, so their little user experience would be harmed by the improved speed. :-) The same goes for metro and tramway doors.