> Purposefully adding a delay to a process can actually increase its perceived value and instill a sense of trust, even when the process itself actually takes much less time.
> Purposefully adding a delay to a process can actually increase its perceived value and instill a sense of trust, even when the process itself actually takes much less time.
The user is part of the system too, and sometimes giving them a bit of time to process what’s happening can be beneficial.
Let's say you go to a store and ask if they have a certain product. The clerk says "Sure, here it is". Is that worse than saying "Hmmm, I have to check in the warehouse first"?
Humans want things to operate at human speeds and computers are way faster than that.
But that's because you're interacting with a human and that sort of behavior from another human typically indicates a kind of hostility.
Interacting with software is nothing like interacting with a human, and doesn't trigger those human social cues.
But apart from that, clients usually appreciated getting their food about twice as fast as they would normally expect. As long as the quality is there, nothing is wrong with speed. And a restaurant is kind of a poor comparison, since cooking is always time dependent, while other goods can be ready for purchase at once.
As for disorienting, there are ways to avoid that without slowing the user down - I think in almost every situation or use case.
I get it, sales and marketing are an essential part of doing business, you will not have a business if you can't sell anything. But it is an inherently evil practice, the whole goal is to coerce somebody into doing something they would not have other wise done. When kept to a moderate amount this is not a problem, the business sells things the customer gets things, everybody is happy. But sometime the marketing department can push thing to a very unhealthy level, psychological manipulation, dark patterns, obsessive tracking, etc.
I wonder, are they tracking that? Doubtful.
The problem was, it was too fast. The shell was up and running pretty much once i pressed the enter key after typing the command in DOS. Real Windows didn't do that, so mine felt bad and fake (to me).
So i added some code in initialization to create and delete 1000 random files with some random delays between them (to cause the HDD to make "doing stuff" noises and its LED light to blink) and show a progress bar for it. After that it felt properly professional :-D.
Strangely there's a "click here if fails to load in 10 seconds" link that lets you bypass it all immediately.
This is all about implying serious work and complexity is taking place for some interaction there the user thinks there should be some.
PayPal used to have an entirely artificial five second wait between the user hitting "log in" and the browser sending the request because it raised perceived security in user testing.
Many banking apps will display "establishing secure connection" for a while for the same reason.
(Possibly paypal still have an artificial delay, but it's hard to tell given how badly the site works these days)
Just because you find something surprising, it doesn't mean it's "very wrong".
The solution was to add a 50-300ms delay before the network request. Why? Because feelings and perception matter more than facts.
Remix would show a white screen and two seconds later have everything ready. Next would show the header and a loader first then gradually over the course of 3-5 seconds have everything ready.
In this case I would guess the issue is not with speed but feedback. The user did something, nothing changed, so they thought it was broken.
Instead of the delay you could add a toast or some text with near the button indicating that the action actually happened.
I remember the people from Blogger (google) talking about this problems. People were not very familiar with blog / website builders and users were confused when their blogs got created instantly, like "This is a big deal, me getting an entire website, what happened, what went wrong? It must have aborted the process…"
Confuse who?
An instant "success" notice beats waiting every single time, regardless of user level, if we're even classifying that.
Which, sadly, is the tech level of most UX people.
Unskilled users are just happy it was fast. Why would it take time, it's a computer!
It's a little like psychiatrists. A surprising number have loads of issues, and go into the business to help themselves.
But this skews perception.
UX people make all sorts of unfounded rules up, many created decades ago, when almost everyone was a "new user".
- Input was received - Input was processed/stored correctly - Outcome is X
Doing everything in real time can reduce confidence and understanding. If everything takes like 5ms it feels weird, sometimes feels even like nothing happened, so people might submit again or feel the need to call and check or whatever.
It's deceptive in the sense that you are waiting maybe 500ms instead of 5ms. But it can be better UX in terms of communicating what's actually going on and having people feel comfortable with their understanding.
On the other hand, artificially slowing down something like closing an advertising modal - antipattern for sure.
If the user is confused as to what happened, you haven't communicated what happened. If you need them to stop and read it, let that notice appear instantly with a next button.
And nothing can happen too fast on a computer. If it's done it's done. Just show "done".
I disagree. If the discrete steps happen that quickly, why is it important not only to inform the user of each discrete step, but to slow things down to ensure they can see the notice of each discrete step?
Surely, in a case like that, it would be better just to tell the user the whole process has completed at the end, rather than detail every step that happened on the way there.