[nelsonenzo]

These seem like theories, not laws. And imho, some of it is very wrong, such as:

> 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.

[mattkevan]

We found adding a slight delay in between the user clicking the payment button and showing the success message in the checkout improved trust. It felt like the system was doing something important, whereas if happened instantly people worried that something had gone wrong because it was ‘too quick’.

The user is part of the system too, and sometimes giving them a bit of time to process what’s happening can be beneficial.

[galangalalgol]

It is akin to people adding weights to items to make them seem higher quality. Not in hiking gear certainly, but disassembly of held kitchen appliances or tools often turns up steel chunks used for that purpose.

[ourmandave]

Couldn't they just use lead solder on the IoT circuit board?

[lexicality]

That one is actually genuinely true and why so many price comparison and search websites artificially load slowly with fancy loading screens.

[badsectoracula]

Reminds me when i was a kid back in the DOS days and made my own GUI system in Turbo Pascal on a 386DX machine i had. It had its own GUI library and simple applications and i had made it look kinda like Windows 95 (because i only had Win3.1 and i wanted 95 - though my take was based on screenshots i saw in magazines so it wasn't very faithful, just what i imagined to be).

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.

[germinalphrase]

TurboTax also allegedly adds delays to increase the perception that the work the product does is very technical and difficult (which, of course, is not true).

[JohnFen]

It may be effective (although I'm skeptical), but is the sort of manipulative bullshit that sends me running. Sites and applications that do this are very shady sites and applications.

[b112]

I get fed up waiting, even for a few seconds, and go to another site.

I wonder, are they tracking that? Doubtful.

[rapfaria]

Oh but they are. We three don't like it, but they have the data to back it up.

[TheSpiceIsLife]

It doesn’t matter, Big Co. owns the other sites anyways.

[lexicality]

You had better believe that companies with margins that thin are tracking absolutely everything, often regardless of what your answer to the GDPR popup is

[carlosjobim]

I think that's more of pseudo-science. I've never heard anybody express any distrust for a service just because it's fast.

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"?

[kepler]

A more suitable comparison might be this: envision yourself at a Michelin-starred restaurant, placing an order, only to have your meal instantly served. This leads to a crucial question: would you prefer to represent the immediacy of a fast-food establishment or the meticulousness of a Michelin-starred restaurant? Ultimately, HCI aims to create solutions that mirror the conceptual models of the real world.

[carlosjobim]

Funny example! I used to work in a place like that, and we could make many plates extremely fast, and sometimes getting a head start from overhearing the clients order while they were still talking to the waiter. And yes, sometimes we would wait a little bit to get the food out, just because it would be weird for the client to get his food instantly.

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.

[kepler]

My point is, context shapes the approach in computer interaction. Certain actions like ordering Uber involve wait and load times, while others don't. Theee is no one-size-fits-all solution. The system should harmonize with the user, bridging the gap between existing conceptual models.

[carlosjobim]

If we go back to the original example. Some hotel booking aggregators still show the fake "Looking for best deals..." popup or screen. The largest aggregator Booking.com doesn't show any such thing, but instead loads the results as fast as it can.

As for disorienting, there are ways to avoid that without slowing the user down - I think in almost every situation or use case.

[somat]

On the other hand I can imagine there being some sort of study that claims that having to "check the warehouse" makes the client now invested in the process and more likely to complete the sale.

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.

[lexicality]

Wrong analogy, imagine you ask where the butter is and they answer "aisle 14" and turn away before you even finish speaking. The butter might be there, but it will feel at least a little like they were saying anything to get rid of you.

Humans want things to operate at human speeds and computers are way faster than that.

[JohnFen]

> The butter might be there, but it will feel at least a little like they were saying anything to get rid of you.

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.

[carlosjobim]

If the software is fast, you ask for the butter and he puts it right in front of you. I say fast interactions and response is always better than slowness or fake loading screens.

[AtNightWeCode]

BS. Google have shown that any time loss in any stage of any payment process directly affect conversion rates.

[lexicality]

Payment process is different.

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)

[ourmandave]

Kelly Blue Book (kbb.com) pretends to take forever gathering the car price info so they can just run ads.

Strangely there's a "click here if fails to load in 10 seconds" link that lets you bypass it all immediately.

[simonbarker87]

I added a 2 second delay to a near instant process and made it feel significantly better and like “something happened”. When it was instant it felt … wrong.

[IIsi50MHz]

If I were you're user, I'd appreciate a setting to remove all such delays. That is, assuming I've little chance of convincing you to remove them permanently. (-:

[vogon_laureate]

Maybe a bit of a misnomer as the description states it's more of a "collection of best practices" that designers "can consider".

[jonny_eh]

I recall that at some point Paypal added an artifical delay for logging in with a spinner that said "securely signing you in" and it increased trust in their product, which increased usage.

Just because you find something surprising, it doesn't mean it's "very wrong".

[raincole]

Not only very correct, but far more common than you think.

[thealchemistdev]

I experienced this first hand with the manual sync button on one of my apps. I got feedback stating it didn't work when, in reality, there was no work to be done and the interface didn't have time to display 'syncing' before it finished.

The solution was to add a 50-300ms delay before the network request. Why? Because feelings and perception matter more than facts.

[_thisdot]

Perceived loading time was a matter of debate during the NextJS vs RemixJS thing. RemixJS argued for fast loading time, while NextJS argued for perceived loading time.

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.

[samsolomon]

I see a lot of comments here about added animations because the request is too fast.

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.

[IIsi50MHz]

Moderate preference for the added text, rather than an an ephemeral 'toast' message.

[AtNightWeCode]

Yes, it is incorrect. Some UX designs even try to make you feel like something happens instantly when it is not. Best example I can think of is that Spotify used to have this animation on the play button that was just there to hide the delay between click and play.

[pickingdinner]

Ya, sounds dark, as in dark pattern.

[rolae]

Not necessarily. Something being too fast can be confusing. If you expect a process to take some time and it ends immediately, it can feel like it failed.

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…"

[pickingdinner]

> can be confusing

Confuse who?

An instant "success" notice beats waiting every single time, regardless of user level, if we're even classifying that.

[b112]

The middlings are the problem. Users tech savvy enough to think "wow, that was so fast!", but not tech savvy enough to look and see if there was a 404 or whatever, in the web console.

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".

[markhnthoraway]

Depends on context. There's nothing wrong with slowing down to communicate discrete steps that may happen very quickly under the hood.

- 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.

[JohnFen]

> There's nothing wrong with slowing down to communicate discrete steps that may happen very quickly under the hood.

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.

[pickingdinner]

Elaborating on details, yes. Slowing it down, no.

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".