Laws of UX(lawsofux.com) |
Laws of UX(lawsofux.com) |
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...
How am I supposed to know this is "design".
> 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.
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?
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.
I hope we won't. Why do you need this? What issue will you solve with it?
> 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.
But I've never seen anybody having this as a first reaction to some software. It needs some time to kick in.
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.
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...
> 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.
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.
The reason these need to be written down in the first place is that they can be counter-intuitive.
Of note: "Laws" can be broken when you have a very good reason to do so. These are definitely good rule of thumbs.
The perfect UI is the interface that has the quickest, most optimal workflow to accomplish a user's tasks
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.
I disagree with this, actually. The perfect UI is one that the user doesn't have to consciously think about when using.
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.
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)
Is it basically saying don't try to hide a bunch of options behind a hamburger menu?
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."
> 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.
Anyone care to chime in with their caveats to some of these?
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.
The user is part of the system too, and sometimes giving them a bit of time to process what’s happening can be beneficial.
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.
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"?
Strangely there's a "click here if fails to load in 10 seconds" link that lets you bypass it all immediately.
Just because you find something surprising, it doesn't mean it's "very wrong".
The solution was to add a 50-300ms delay before the network request. Why? Because feelings and perception matter more than facts.
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.
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.
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…"
- 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.
Arc Browser has Boosts which do allow for a decent amount of customization which is much appreciated.
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.
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.
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".
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)
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.
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-
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.
Confuse who?
An instant "success" notice beats waiting every single time, regardless of user level, if we're even classifying that.
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".
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.
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?
It has become HTML-rendered, if anything, shouldn’t it be more configurable?
Also, that pretty much only affects the look, it doesn't affect how the browser behaves.
I wonder, are they tracking that? Doubtful.
[...]
> 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.
> 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.
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.
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.
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.
Humans want things to operate at human speeds and computers are way faster than that.
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.
As for disorienting, there are ways to avoid that without slowing the user down - I think in almost every situation or use case.
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).
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.
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.
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.
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.