Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Laws of UX

lawsofux.com

Post reply on HN
Print view View original

21–30 of 114 posts

Re: Laws of UX

#21

Post by JohnFen »

pickingdinner wrote: post #18
BariumBlue wrote: post #12

Earlier quoted context omitted.

The perfect UX is the interface is that displays and works exactly how the user wants and expects. The perfect UI is the interface that has the quickest, most optimal workflow to accomplish a user's tasks

> quickest, And this can be scientifically measured by mouse distance and clicks. > most optimal workflow to accomplish a user's tasks And this can be scientifically assessed by taking all use cases and refactoring over them. List all the available goals at any given "location" in the program. List all the steps users take to get accomplish their goals. Consolidate and refactor, then optimize on the shortness, obviou…

> And this can be scientifically measured by mouse distance and clicks.

[...]

> And this can be scientifically assessed by taking all use cases and refactoring over them.

And I can't count the number of times I've seen applications do this, resulting in a terrible UI that is hard (and therefore slow) to use.

Re: Laws of UX

#22

Post by pickingdinner »

markhnthoraway wrote: post #11
pickingdinner wrote: post #5

Earlier quoted context omitted.

Ya, sounds dark, as in dark pattern.

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

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

Re: Laws of UX

#23

Post by pickingdinner »

JohnFen wrote: post #21
pickingdinner wrote: post #18

Earlier quoted context omitted.

> quickest, And this can be scientifically measured by mouse distance and clicks. > most optimal workflow to accomplish a user's tasks And this can be scientifically assessed by taking all use cases and refactoring over them. List all the available goals at any given "location" in the program. List all the steps users take to get accomplish their goals. Consolidate and refactor, then optimize on the shortness, obviou…

> And this can be scientifically measured by mouse distance and clicks. [...] > And this can be scientifically assessed by taking all use cases and refactoring over them. And I can't count the number of times I've seen applications do this, resulting in a terrible UI that is hard (and therefore slow) to use.

This contradicts the premise.

> hard (and therefore slow) to use.

You assess the use case, as in each case the user goes from want to finish. If it's slow and hard, you fix that.

1 click is the fastest.

An obvious button that does exactly what you want is the easiest.

There is nothing slow or hard about an interface optimized based on a complete understanding of what the user wants to the point that they can distill it in one button.

Re: Laws of UX

#24

Post by b112 »

JohnFen wrote: post #17
lexicality wrote: post #4

Earlier quoted context omitted.

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

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.

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

I wonder, are they tracking that? Doubtful.

Re: Laws of UX

#25

Post by lexicality »

b112 wrote: post #24
JohnFen wrote: post #17

Earlier quoted context omitted.

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.

I get fed up waiting, even for a few seconds, and go to another site. I wonder, are they tracking that? Doubtful.

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

Re: Laws of UX

#26

Post by rapfaria »

b112 wrote: post #24
JohnFen wrote: post #17

Earlier quoted context omitted.

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.

I get fed up waiting, even for a few seconds, and go to another site. I wonder, are they tracking that? Doubtful.

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

Re: Laws of UX

#27

Post by JohnFen »

markhnthoraway wrote: post #11
pickingdinner wrote: post #5

Earlier quoted context omitted.

Ya, sounds dark, as in dark pattern.

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

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

Re: Laws of UX

#28

Post by b112 »

pickingdinner wrote: post #19
rolae wrote: post #8

Earlier quoted context omitted.

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…

> can be confusing Confuse who? An instant "success" notice beats waiting every single time, regardless of user level, if we're even classifying that.

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

Re: Laws of UX

#29

Post by TheSpiceIsLife »

rapfaria wrote: post #26
b112 wrote: post #24

Earlier quoted context omitted.

I get fed up waiting, even for a few seconds, and go to another site. I wonder, are they tracking that? Doubtful.

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

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

Re: Laws of UX

#30

Post by thealchemistdev »

nelsonenzo wrote: post #2

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.

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.

Post reply on HN