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

61–70 of 114 posts

Re: Laws of UX

#61

Post by BariumBlue »

pickingdinner wrote: post #36
JohnFen wrote: post #32

Earlier quoted context omitted.

I was taking issue with optimizing things based on the metrics that I quoted. Just because a thing can be done in fewer clicks, or with a smaller movement of the mouse, doesn't mean that's the way that a person most effectively works. What the user wants is important. Understanding how the user works in order to get there is also important. The most efficient path for a person is not necessarily the one with the fewe…

This is just math, so I will continue to elaborate. Mouse clicks and distance are two of the most basic metrics. And straight forward. So why wouldn't you optimize there? But what you're referring to is that which can offset and add to those metrics. "Mouse click" in and of itself means nothing in the context of the program. So it's the "other stuff" that pushes against the goal being accomplished in 1 click. So the…

>Mouse clicks and distance are two of the most basic metrics. And straight forward. So why wouldn't you optimize there?

That's the McNamara fallacy: https://en.wikipedia.org/wiki/McNamara_fallacy Basically: enemy bodycount is easy to measure and thus you should optimize for it. Conversely if you can't measure it, it must not be important. The fallacy is that enemy body count is not wrong per se, but oversimplified.

I don't disagree with focusing on making most use-cases faster, but treating a human like a machine ignores things like error rates, understanding, lasting impressions, and ease of learning, which are important for users who have a choice in software. If you have vendor lock for your software, you don't need to optimize at all so it's kinda moot.

Re: Laws of UX

#62

Post by kepler »

carlosjobim wrote: post #14
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.

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

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.

Re: Laws of UX

#63

Post by pembrook »

pazimzadeh wrote: post #52

I don't really get the point of Tesler’s Law: "any system there is a certain amount of complexity which cannot be reduced" Is it basically saying don't try to hide a bunch of options behind a hamburger menu?

It's become common practice in B2C software to distill the UI down to an insane degree (eg. basically an infinite scroll feed). Since the job to be done of most B2C software is basically: placate my existential angst with various forms of content, this works. Consuming content is not a complex task.

However, it's become en vogue to apply this same design logic to B2B software, where this approach is bound to screw things up.

In B2B software, the tasks are often much more complex (eg. help my large organization collaborate on bespoke long term projects and juggle hundreds of stakeholders, while offering cascading permission management), so any software suitable for this task is going to be a nightmare to use no matter how good the design is (because its a nightmarish task).

The same goes for front-end website builders. Wix has a simple UI because it only lets you do simple things. Webflow's UI is super complex, because it offers all the powers inherent in coding HTML/CSS by hand. So you essentially have to learn HTML/CSS to use it.

The UI of any tool must match the complexity of the job to be done. This doesn't mean UIs can't make things easier/faster. It just means UIs can't remove steps unless you remove requirements.

Often when a tool is lauded for "good design," its because it encourages removing steps that were unnecessary all along, but people were still doing out of tradition. The tool then gives people an excuse to stop doing the stupid tradition, because "X doesn't allow that."

Re: Laws of UX

#64

Post by _Parfait_ »

JohnFen wrote: post #49
graypegg wrote: post #37

Under Aesthetic-Usability Effect > 2: People are more tolerant of minor usability issues when the design of a product or service is aesthetically pleasing. I think this is true for someone’s first interaction with a thing. But if you rely on something, minor usability issues skyrocket in importance, and aesthetic importance drops really fast.

I think this might also be why I've come to associate slick, pretty interfaces with substandard software/websites.

Bad UI is Bad UX

Re: Laws of UX

#65

Post by godshatter »

user3939382 wrote: post #45
graypegg wrote: post #37

Under Aesthetic-Usability Effect > 2: People are more tolerant of minor usability issues when the design of a product or service is aesthetically pleasing. I think this is true for someone’s first interaction with a thing. But if you rely on something, minor usability issues skyrocket in importance, and aesthetic importance drops really fast.

> if you rely on something ... aesthetic importance drops really fast IMHO it bothers me more because I'm forced to experience it more. It's like the annoyance accumulates. I may care more about UI than the average user though, or maybe I'm just more able to articulate my thoughts about it because of my profession? Not sure.

In some ways I prefer the older interfaces to more modern ones because, even though they were ugly, it was often more obvious what was clickable, what workflow was expected, and if you needed something it would probably be in the horrendous menu tree somewhere. Nowadays it's often impossible to determine what is clickable and what is not, but things look much prettier. I don't really need pretty, it's just a nice-to-have. Of course there are newer interfaces that are easy to understand and older interfaces that are borderline unusable. It's just been my experience that an older interface will be easier to use, though probably more annoying to go through. YMMV.

Re: Laws of UX

#66

Post by jonny_eh »

montroser wrote: post #60

For a site espousing UX platitudes, I don't feel it's too nit picky to call out their completely terrible back-button behavior. You click on one of these items, read down the item detail page, then click back to go to back to the index page, and this happens: - it scrolls you back to the top of the item detail page - it fades out the detail page - it fades in the index page It's janky, and wastes my brain cycles tryi…

The "montroser principal": "Enough with the animations already".

Re: Laws of UX

#67

Post by galangalalgol »

JohnFen wrote: post #55
user3939382 wrote: post #47

My ideal for UX or UI is that a new user, understanding the domain and what the application is supposed to do at the most abstract level, should be able to immediately use it without any training or explanation.

I agree, but the problem is that the UI that is great for new users tends to be horrible for experienced users.

One way to handle that is through multiple user modes. A simple case is how MS office shifted UI many times, but the keyboard shortcuts remained the same and accumulated to some extent. The key sequences are still there to navigate menus that disappeared before ribbons, or even before MS bought out the originating product. Key combos are a common thing experienced users learn almost unintentionally to speed up a workflow, but it doesn't harm the discoverability for new users or of new features.

Re: Laws of UX

#68

Post by graypegg »

JohnFen wrote: post #35
JohnMakin wrote: post #34

I would like to see more support in UI/UX for people who are not neurotypical. Or, customizable interfaces to support people with disabilities. When you build for the common denominator, these people get left out.

When you build for the common denominator, a huge number of people are left out, including those with disabilities. > customizable interfaces to support people with disabilities. Customizable interfaces are the only real solution -- not just for people with disabilities, but for everybody. There are a number of websites and applications that I stopped using because of UX choices I am allergic to. If they were configu…

One little thing I think makes a huge difference is just using the user agent a bit more.

You can write styles at only apply in high-contrast or reduced-motion mode.

Use relative text sizes so you the user agent can use a value for the root font size that isn’t 16px.

Use buttons for buttons, links for links, and for dialogs etc.

I’ve thought about just making more web apps that have nearly no styling, maybe just some layout, but otherwise relying on the user agent styles. That’s a ton of user customizability for FREE! And honestly, it usually doesn’t look that bad.

Re: Laws of UX

#69

Post by galangalalgol »

mattkevan wrote: post #39
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.

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

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.

Re: Laws of UX

#70

Post by JohnFen »

galangalalgol wrote: post #67
JohnFen wrote: post #55

Earlier quoted context omitted.

I agree, but the problem is that the UI that is great for new users tends to be horrible for experienced users.

One way to handle that is through multiple user modes. A simple case is how MS office shifted UI many times, but the keyboard shortcuts remained the same and accumulated to some extent. The key sequences are still there to navigate menus that disappeared before ribbons, or even before MS bought out the originating product. Key combos are a common thing experienced users learn almost unintentionally to speed up a work…

Yes, although key combos is no magic bullet. Personally, I prefer having an "advanced" UI option that you can select when the introductory UI becomes irritating or restrictive.
Post reply on HN