7 ms·
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 perceive
by nelsonenzo 3y ago
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.
- AtNightWeCode 3y agoYes, 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.
- vogon_laureate 3y agoMaybe a bit of a misnomer as the description states it's more of a "collection of best practices" that designers "can consider".
- pickingdinner 3y agoYa, sounds dark, as in dark pattern.
- rolae 3y agoNot 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 3y ago> 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 3y agoThe 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 3y agoDepends 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.
- pickingdinner 3y agoElaborating 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".
- JohnFen 3y ago> 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.
- lexicality 3y agoThat one is actually genuinely true and why so many price comparison and search websites artificially load slowly with fancy loading screens.
- germinalphrase 3y agoTurboTax 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).
- carlosjobim 3y agoI 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"?
- lexicality 3y agoWrong 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 3y ago> 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 3y agoIf 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.
- raincole 3y agoNot only very correct, but far more common than you think.
- simonbarker87 3y agoI 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 3y agoIf 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. (-:
- thealchemistdev 3y agoI 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 3y agoPerceived 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 3y agoI 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 3y agoModerate preference for the added text, rather than an an ephemeral 'toast' message.
- mattkevan 3y agoWe 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 3y agoIt 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 3y agoCouldn't they just use lead solder on the IoT circuit board?
- jonny_eh 3y agoI 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".