Hacker News new | past | comments | ask | show | jobs | submit login
Laws of UX (lawsofux.com)
134 points by mgdo 10 months ago | hide | past | favorite | 110 comments



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 trying to parse the fleeting intermediate states. Also, the fade animations are too slow -- literally making me wait through the jank to get back to the content I'm looking for...


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


No, it's important that every single element vertically slide and fade in as I scroll the page.

How am I supposed to know this is "design".


That's the "chrstphrknwtn principal", use whichever principal best applies.


This is the "jonny_eh meta-principle" at work! Finally see it with my own eyes!


I, personally, see it everywhere!


The orthography principle.


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 configurable, it might have been possible for me to mitigate the worst parts.

Further, UX/UI decisions have been getting worse over time, making configurability even more important as time goes on.


Exactly.

It's unfortunate that accessibility is usually treated as an add-on in a lot of 'UX' project. Focus is heavily on visual design.

Accessibility needs to be considered from the start when designing new apps.

Making things accessible means making it easier for all users.

Which apps / sites have you stopped using because of poor UX choices.

And what are those things that made you stop using those sites?


> Which apps have you stopped using because the UX choices.

The biggest example for me is Firefox. FF's UX has always been horrible, but until the revamp, it was always possible to configure it to be OK without a great deal of effort. After the revamp, the UX is still horrible (although in different ways), but the ability to configure the bad parts away has been seriously reduced.

> And what are those things that made you stop using those sites?

Overreliance on Javascript, hidden functionality, and (related) the lack of discoverability top my list of peeves. Also, with websites, being too aggressive with enforcing a particular layout, color scheme, fonts, etc.


> FF's UX has always been horrible

I've used it for years. It can browse sites, manage tabs and so on. Even synchronization between devices works fine. There are some issues but I wouldn't call it horrible. Could you elaborate more?


> After the revamp, the UX is still horrible (although in different ways), but the ability to configure the bad parts away has been seriously reduced.

It has become HTML-rendered, if anything, shouldn’t it be more configurable?


It depends on how you mean. If you're a web dev, and/or willing to mess with CSS, then perhaps it's more configurable? But there is significant friction in doing so, even if you do know how to work at that level. In terms of what normal users can realistically do, the browser is much less configurable.

Also, that pretty much only affects the look, it doesn't affect how the browser behaves.


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


One I really appreciate is having sane tab indexes and the ability to trigger things like buttons and drop-downs using the keyboard. A slick select box loses a lot of points for me if I can’t navigate and use it with just my keyboard.


When you build for the common denominator, people with brains often get left out.


Agreed us vim users are serverly undercatered to.


Sites with surprise hjkl always make me smile


got a solid laugh. thank you


We have made Dark mode an expected feature on UI's, hopefully with time we will get an Expert mode that allows customizable interfaces (anyone remember Foobar2000 or GMusicBrowser?). Home Assistant is a good example of such UI.


You used to be able to bring your own themes. Now if you're lucky, you might get dark mode, as a treat.


> hopefully with time we will get an Expert mode that allows customizable interfaces

I hope we won't. Why do you need this? What issue will you solve with it?


There’s plenty of UIs that I would like to be able to either reorganize or remove parts of.

Arc Browser has Boosts which do allow for a decent amount of customization which is much appreciated.


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.


Interestingly, I do share this association, I have seen more people react this way, and I have seen more people consciously describe that association.

But I've never seen anybody having this as a first reaction to some software. It needs some time to kick in.


> But I've never seen anybody having this as a first reaction to some software. It needs some time to kick in.

It used to take time, but the association has become common enough that it's a red flag right at the start for me. It won't make me not try it out, of course, but it does set a certain expectation in me.

The effect is strongest with websites. I think the correlation between being pretty/shiny and the site being generally worthless is high enough to be roughly predictive.


I have a knee-jerk reaction to sites that reveal things or animate as I scroll down. It was cool the first time or two…years ago. Now it feels gimmicky at best, and more often it obscures the page in a way that makes me feel like I need to scroll the entire page before reading it so there’s no hidden surprises.

Of course this also boils down to intent - is the page an art thing where presentation plays a part in the interaction? Cool. But I was on a product page for a home media server that did this and it was painful - I wanted specs, testimonials, information, and I had to scroll through animations and slide-in text and all kinds of stuff to get a grip on the -product-


Bad UI is Bad UX


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


I think the clearest delimitation between old and new is a lot of old interfaces really tried to make every GUI element appear distinct. I think as we presume that users are familiar with basic GUI elements we’ve started replying on them having intuition from context clues instead. “The button doesn’t look pushable, but we know that you expect a button here anyway.”

I signed up for a Lemmy instance a while ago, and just stopped using it because the default lemmy web UI adopted 2010s worst trend of making buttons, text areas, and combo boxes all the exact same featureless rounded pill. It’s legitimately difficult to use on a phone. One big pile of pills that do random things.


Humans are pattern-matching machines though. I think anyone, UX-designer or not, can notice annoyances that are clearly just not following the obvious pattern.

I know people that have quit jobs, because they were forced to use software that “I could never learn”. (Salesforce) It got in the way of them doing their job.

However, I’ve seen way more people tolerate an outdated or badly styled UI because “it just works for me, ok?”. No one is quitting a job because their CRM is aesthetically unpleasing.


As a dev, I've never quit a job because I didn't like the software I had to use. But if I'm evaluating whether or not to take a position somewhere, the use of certain software is certainly a mark in the minus column.


There’s an example of that in the linked write up - a user reported really enjoying colorful, full-page images…on the first use. After subsequent use, the failures of the UX made such aesthetics more annoying than useful


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.


Discoverability is an underrated feature in software. I like how in Microsoft Word (off the top of my head), all shortcuts are displayed when you go to the file menu.

Redundancy is also an underrated design feature. In Word, if you want to copy/paste, there are at least 3 ways (I'm sure I'm missing some obscure way).

- menu->edit->copy

- right click->context menu->copy

- ctrl-c

And it's a great way of transitioning users from new mode to expert mode. A hotkey is just about useless if you don't know it exists, whereas the menu is slow. So, beginner users start using the menu, then transition as they memorize the particular hotkeys for this software as they become expert users. Somebody put thought into this design.

Also taking this opportunity to shamelessly plug the nested tooltips in Crusader Kings III. As far as learning context in-situ without breaking flow, it is amazing, though sadly not generalizable to all applications. Seriously, whoever designed that needs another raise; I have yet to see a minor UI component receive any mention at all, let alone praise, save this one.

https://www.reddit.com/r/CrusaderKings/comments/102gtm8/nest...


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.


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.


That's one of the messages of The Design of Everyday Things. It's too bad Apple hired the author and ignored him.


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


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.


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


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


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.


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


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.


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


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


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.


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.


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.


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.


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.


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.


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


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.


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


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)


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.


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.


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


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


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


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


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.


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.


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.


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


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.


Ya, sounds dark, as in dark pattern.


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


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


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.


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


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


Noticing that most websites are designed for mobile now and barely work on desktop especially if zoomed in or using accessibility features.

Sticky headers take up half the page.

Margins are too wide for the browser

Images are way too big compared to text size

Images don't fit on the page no matter what zoom level you use.


I love HN and UX articles. Every time this comes up, the thread is full of smart people disagreeing with these principles.

The reason these need to be written down in the first place is that they can be counter-intuitive.


The first time I saw this site, I thought some of it was heavy handed, but reading it again today—yeah, it's good. I'm buying the deck form of this to have sitting on my desk.

Of note: "Laws" can be broken when you have a very good reason to do so. These are definitely good rule of thumbs.


Every time I see this site it still amuses me that despite all the valuable UX information, it is very annoying to use on a desktop because it feels like it was designed entirely for tablets or phones.


The perfect UX is one obvious button that obviously does exactly what you need, that presents itself exactly when you need it. And all you need is to be able to read it.


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, obviousness, and fault tolerance of every flow.

This is more fundamental to the user experience than colors or animations or the availability of any single feature.


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


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 fewest clicks/shortest mouse travel.


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 answer is, considering that "other stuff", what is the most efficient, as in, fewest clicks and shortest distance possible?

The gripe that should be had is not even optimizing on this level, and even worse, prioritizing "fancy" animations as if that's a good thing and as if that's your main job.

> The most efficient path for a person is not necessarily the one with the fewest clicks/shortest mouse travel.

The most efficient path for that person is necessarily the one with the fewest clicks/shortest mouse travel (for that person).

And that is the optimization process of 1 use case (user usage case path).

The goal of UI is to optimize efficiency across most use cases (and hence users) as measurably possible.

(all the fancy animations can be added after that, so you can bill for those hours, and add an obvious "animations off" button, and you'll literally make everyone happy).


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


> making a decision based solely on quantitative observations (or metrics) and ignoring all others

I literally just stated how you should observe "all others". With everything important considered, you should then "count your bodies" and optimize. McNamara would agree with that.

Most UIs don't. Just take any app or program you use daily, and imagine better paths to the goals you repeat on a daily basis. If you're a UI person, you should be focused on optimizing these paths.


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

You might, but to do so based solely on those metrics is a mistake. That's because those metrics don't fully capture what makes a UI efficient for human use. Other things, like cognitive load, are more important.

Does it matter if it only takes two clicks to do a thing if that usage path isn't one that meshes with the way I think? I think not, because it means that I'll spend additional time thinking about how to accomplish the task rather than just accomplishing it.

> and even worse, prioritizing "fancy" animations as if that's a good thing and as if that's your main job.

I 100% agree with you there! Animations are commonly misused and dramatically overused, and I think that more UIs would be improved by omitting them.

> The goal of UI is to optimize efficiency across most use cases (and hence users) as measurably possible.

If we're talking about "efficiency" in terms of "minimizing the use of the mouse", then I disagree. If we're talking about "efficiency" in terms of what helps a person to accomplish a task in the best way possible, then I agree -- but focusing mostly on those metrics excludes so much other important stuff as to give a distorted picture of the situation.


> solely

Not solely.

> "efficiency" in terms of what helps a person to accomplish a task in the best way possible

Correct. THEN optimize the metrics.

I didn't realize there was a myth that some users prefer slower. They don't. If they could be done they'd rather be done. Especially if this involves work. Most users that use software at their job didn't choose that software. The least we can do as engineers is let them go home to their family sooner.


> The perfect UI is the interface that has the quickest, most optimal workflow to accomplish a user's tasks

I disagree with this, actually. The perfect UI is one that the user doesn't have to consciously think about when using.


You're not contradicting what you're disagreeing with.


The perfect UI doesn't have a button, it does what's expected without the user asking for it.


I disagree. That isn't even an interface. And this is the source of so much trouble. The "developer knows best" mindset. The developer will never know exactly when I want coffee, yet so many programs assume my coffee needs are just an algorithm that I secretly obey and just don't know it yet.

The best interface does nothing. It's idle and listens. Everything automatic must be fully transparent and be opt-in. Fully explained if not self-explanatory.

User instruction beats developer assumption every single time. If the user is "wrong" as arbitrarily defined by the developer, the least they can do is kindly instruct and point the user in the "right" direction, not assume, let alone assume they know better than the user about what they want.


What you describe just means our tech is not ready yet.

Not that it's not the best UI.

Nobody miss having to manually change their clock for DST or after a plane trip.

One day, the machine will read your mind, know you need some info, and download it into your brain. You will just know what you need to know without asking, as if it were obvious.

That's the best UI.

It's also the UI that will be the most abused with the most terrible consequences.

Dark patterns on neuralink are going to get, well, dark.


There will always be an interface for any tool, mind reading tech or otherwise. And anything that does something against the user's will is a bad tool with a bad interface.


Related:

Laws of UX - https://news.ycombinator.com/item?id=24030969 - Aug 2020 (293 comments)

Laws of UX - https://news.ycombinator.com/item?id=16185118 - Jan 2018 (207 comments)


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


From the site itself:

> 1. All processes have a core of complexity that cannot be designed away and therefore must be assumed by either the system or the user.

> 2. Ensure as much as possible of the burden is lifted from users by dealing with inherent complexity during design and development.

> 3. Take care not to simplify interfaces to the point of abstraction.


This site does what it preaches but these seem a little off. Some of these I'd argue against but I'd also argue I'm not qualified to.

Anyone care to chime in with their caveats to some of these?


Wait, why not the site use tailwindcss ?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: