The first screen is a long scroll of 20 elegant looking blocks and titles none of which mean anything on their own. I have to click on each and sit through some superfluous animation before I can even get access to the explanation.
Because of the animation, t he natural flow of swiping back on my phone results in a really janky transition.
I have to say, I love the style of these graphics. Minimalism I guess? Reminds me of the University of Waterloo during my childhood.
Quite frankly, it has a terrible UX. It took me three visits to understand what you meant by access to the explanation. I could only find a bunch of uninformative slides and a blurb promoting a book on the first visit two visits. On visit number three, I found the explanations.
I originally interpreted the scrolling indicator as an advance to next slide button. When I clicked on the button it presented the new slide and the advance button disappeared, so I further explored the site by clicking on the learn more button. That presented another uninformative slide so I ignored the advance button. After all, why would I want to repeat an action that failed to produce the desired result the last time I did it? Noticing the next link, I clicked on that in hopes that it would produce a more desirable result. Unfortunately, it produced the same sort of result as the advance button. At that point, I just gave up and clicked on the Info button and saw the blurb promoting the book. I tried clicking on the links to the left, saw the uninformative slides, and concluded that it was a gawd awful promotion for a book that included nothing but chapter headings.
Those were my first two visits. On visit three, convinced that there must be something more, I actually tried the advance button on the right slide and discovered that it was a scroll indicator. By that point, I was already so frustrated with the experience that I just gave up on the site without seeing what the creator had to say.
As for the graphics style, sure it's great. On the other hand, taking the minimalist presentation too far produced a site that was more difficult to interpret.
Edit: trying to keep terminology consistent as my understanding of the site evolved.
> frankly, it has a terrible UX
I don't follow these critiques. The content and navigation of the site is quite clear to me. The trackpad/wheel scrolling stutters very slightly in FireFox on Windows.
EDIT: And hey, it's in Dark Mode!
#21: More people will visit your site with tiny/mobile screens than large/desktop ones.
In a way, I should know better. I landed on a news article earlier in the day that started with one of those dynamic infographics that you interact with through scrolling. I was at the point of backing out of the page, concluding that the article was the infographic, when a hint of an actual article popped up on the screen. While it is a visually, I also find it a very annoying waste of time when I am trying to find information.
(Incidentally, I didn't run into the performance issues that others have been mentioning even though I was using an 8 year old computer.)
Bad user! You're not following the first law of UX:
> Users often perceive aesthetically pleasing design as design that’s more usable.
> Aesthetically pleasing design can make users more tolerant of minor usability issues.
> Aesthetically pleasing design creates a positive response in people’s brains and leads them to believe the design actually works better.
> Aesthetically pleasing design can mask usability problems and prevent issues from being discovered during usability testing.
You're supposed to go "oh, pretty!" and forget how crappy it really is! /s
Seriously now: the first law of UX should be that aesthetics are secondary to usability. If your focus is on making something "eye catching" or "beautiful" then you're doing bad UX. If designers followed that, we wouldn't have so many UX trainwreaks.
The first law of UX is that human resources are precious. Therefore design must seek to maximize the economy of user time, cognition, and effort.
This is the biggest problem with tech today, making "eye catchy" software which is horrible to use and getting anything done (and I mean simple things as making a payment if it's just little bit different than the "designer" imagined, for example you want to add a note) is so frustrating because it takes so much time. Yet it was not like that few years ago.
Thanks apple I guess ?
EDIT: And then to make the software "easier to use" security goes down the drain. There is a small fintech bank where all you need to know is email and 6 digit pin number to pair the account with a phone. That is, the 6 digit pin number is all you need to know to access the customer's funds. Now keep in mind attacker wouldn't care about a specific account, just get loads of customer emails and try the most common pin numbers and fish what you can - there is no notification when a new device is paired either, indeed.
Not really the best user experience and use of my time if I lose my money and need to fight with the fintech bank to get it back or when my account gets locked needlessly.
The same goes for the constant redesigns. How is that mindful to the user if you change everything (again) so they need to spend their time to learn again how to use your app just to get the same stuff done as before.
And they may or may not even interact with the software directly, or for very long.
Teams will build software aligned with the immediate incentives they have, never assume those incentives are even remotely close to those that might make the business succeed in the actual market.
The rule seems to imply UI > UX lol
To be honest, this site looks like some designer's playground, not something an UX expert put together.
I would argue that instead it should be aesthetics and functionality need to be balanced.
Your usability will suffer if lack of aesthetics obscure the usability of a tool. Conversely, your aesthetics need to be reigned in, so that they do not obscure the usability of your tool.
Ever performed your craft and you just nail it and as a side effect the thing looks positively beautiful?
Once again someone on HN phrases something better then I could hope to.
> Ever performed your craft and you just nail it and as a side effect the thing looks positively beautiful?
Best feeling in the world, on the rare occasions I manage it.
I didn't notice any scrolling differences myself ¯\_(ツ)_/¯
"Don't fuck with scrolling" applies to both scenarios equally though.
So it's not designed for me — a person on lunch break, hoping to read at least 5 articles via Hacker News before my burrito is gone.
While I was annoyed there, I still appreciate it. It's a free resource. It's pretty. I gleaned a few useful takeaways (especially the idea of putting more important things on the edges).
i agree none of the graphics use actually seem to mean anything intuitively to me. Looks like just pretty placeholder pictures.
Also if one find oneself writing down 20 general rules for anything, it's an excellent indication one may not have actually grokked the topic because it's very very unlikely you'll apply 20 rules at the same time. It's likely in some situations, 3-4 are important and in other situations, some others are more important and this ability to classify and recognise what applies where is an indication of knowledge and pedagogical strength.
(The laws titles are not selectable on desktop/linux/firefox.)
Furthermore the short description of the laws does sometimes subtle differ from the actual long descriptions in ways which make major differences about how "correct" that law is.
Oh, wanna search for a cool band outside our platform, but there name is in Chinese or something else you don't have an IME for? TOO BAD, GOTTA INSPECT ELEMENT.
They are not easily selectable.
I mean who expects the whole card to act as a link and as such need special handling wrt. selecting text? Especially if there is an explicit "link button" to navigate to the "more details view" just besides the card.
The funny thing is that while for some users the whole card acting as a single hyperlink is intuitive (even through there is no indication that it does) for others it isn't intuitive at all and at most they would expect it to behave like a normal tile (it looks like a title) .
The logo on the card being clickable and being a hyperlink on the other hand is probably expected by much more people.
> The first screen is a long scroll of 20 elegant looking blocks and titles none of which mean anything on their own.
The page behaves differently on mobile vs desktop, and that quote is a description of the mobile experience. On desktop, it also includes a one-sentence explanation of each law without needing to click through.
> Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
Side note, this text was hard to copy because the site changes the text highlight color to black, the same as the background.
I agree that the mobile experience is broken. They should rethink the layout to add the summaries back onto the main page.
If I was offering advice to the designers, I would suggest they abandon the obsession with 100vh layouts and always have a little bit of scrollable content peeking in from the bottom. 100vh layouts evokes the slideshow metaphor, which changes how people expect interaction to function.
I would also restyle the "LEARN MORE" buttons to make them clearer. My brain somehow completely ignored them on first viewing. I saw them on subsequent viewings but the low contrast makes them not seem very clickable, I think they could be easily misinterpreted as shortcuts to the next content "slide".
So now you say "I love the style of these graphics". So if the 1st law is correct it means you perceive this design as usable.
Then here's the irony: Just because you PERCEIVE it as more usable does not necessarily mean it is more usable. Which seems to be the case as per your experience.
But so what is the point about trying to make users PERCEIVE a design as usable? Shouldn't the goal be to make it actually usable whether users perceive it as such or not?
It's a "Memphis style" variant. Pretty trendy these days. Now the industry is starting to move to "Neumorphism".
Really? I thought Memphis style was this: https://en.wikipedia.org/wiki/Memphis_Group and this: https://www.megapixl.com/illustration-for-hipsters-memphis-s... (e.g. "80s style").
This website is not giving me that impression. If anything, it reminds me of a style I associate with the 60s or 70s (namely a sans serif font coupled with geometric graphics that use multiple shades of the same bright color).
Edit: I think it's closer to the "Swiss/International Style": https://www.google.com/search?q=Swiss/International+Style+Gr..., but I'm by no means an expert.
It seems you are conflating "Memphis" from modern web design. What we see on the Laws of UX cards is geometric abstraction.
It's like saying Apple is not Bauhaus.
Regarding neumorphism, I’d bet that will be much like the “long shadow” trend of yore; an interesting style that is hyped until, a short time after, the appeal of the newness and uniqueness wears off completely.
Really? Neumorphism is cool to look at occasionally, but I would hate it if everything started looking like that.
The index page is even worse. It sits under the burger/help menu. Non of the titles make sense, you'll have to click each and read to have a clue.
Paulie law: make a website you would like to use
The other 25 are irrelevant
I'd say if you practice Minimalism, then also make sure it applies to the total amount of space you're using for it ;)
Whatever you call this style.
1. UI > UX.
2. Respond in less than 400 ms.
3. Make buttons clickable.
4. Make it simpler.
5. Copy functionality and UX off other sites.
6. Draw borders around similar functionality.
7. Simpler imagery is better.
8. Users think objects next to each other do similar things.
9. Similar items close together look like one big thing.
10. Things that look the same (color, font, etc) will look like they do the same thing.
11. The average person can remember 5-9 things at once.
12. Remove all unnecessary elements.
13. Focus on the 20% that does 80% of things.
14. Any task will inflate until all of the available time is spent.
15. People judge the experience by its beginning and end.
16. Be tolerant to whatever actions the user may take.
17. People remember the first and last items in a series.
18. You can't reduce all the complexity.
19. When one thing stands out from others in a group, it will be remembered.
20. People remember incomplete tasks, i.e. use progress bars.
4 and 12 are identical. 14 has nothing to do with UX or UI. 15, 11, and 17 are the same. 18 is an excuse masquerading as a Law. From 11-18, it feels a lot of these are pulled in from some Tim Ferriss book or some generic self-help Seven Secrets of Highly Influential People. Perhaps it believes its 15th and 17th law so much that it thinks it can hide fluff in the middle of the list.
It establishes credibility with a lawsofux.com domain them then proceeds to wreck it by violating its 7th law. It does solidly prove its first law, that if you have a pretty enough site, everyone will believe it.
Take for example 15. It doesn’t say people judge by the beginning and the end, but by the peak and the end. Or 4 - representing Hick’s law as “make it simpler” misses so much nuance that the key point is completely missed.
It rather seems like you barely skimmed the page before deciding to shit on it for arbitrary reasons.
"People will perceive and interpret ambiguous or complex images as the simplest form possible, because it is the interpretation that requires the least cognitive effort of us."
If a website violates its own laws, that brings into question the credibility of the laws, or the credibility of the author of the website. Without credibility, it feels like a waste of time to do anything more than skim... perhaps this is a failure of UX?
Fair point about 15, but neither you nor the website managed to express Hick's Law any better than KISS.
You can see how this doesn't just boil down to "make it simpler". And many of your summaries similarly miss the point.
I do admit that the website doesn't elaborate on the concepts very much. For example, if I hadn't known about Hick's law beforehand, I might have arrived at the same conclusion as you. But they do link further reading which seems to do the job of explaining the laws in detail. So I think the website is a nice reference if you go the extra mile and look at the links.
I hate when people do this. It messes with selection by keystroke. It's frustrating and breaks the default means of using a drop-down box.
Which equally gets broken by different ways to write countries:
United States of America (U), America (A)
United Kingdom (U), Great Britian (G), England (E)
Hacker News in a nutshell.
The best (or worst) part and the last part, that is.
It is a comprehensive look at ux and goes over the history, the context and how to incorporate in a project.
- 400ms css transition
- network load of new page
- scrolling down to view content
- another 400ms transition to go back to main content
as its primary mechanism of interaction... is the irony totally lost on them? Or did they drink the #1 kool aid to the extent that they believe their "design" will outweigh their myriad UX failures?
It can mean "display the linked page within 400ms" or "start the animation within 400ms". You can't expect 1 TB of data to be transferred within 400ms but you can display a progress bar within 400ms.
Apple used that to great effect. iPhones, at least in the early days always felt more responsive than Android phones. That because they hid latency using smooth animation. And it worked. It was also apparent when I compared Chrome and Firefox a few years ago. Chrome felt faster but mostly because Chrome was faster at showing something on screen. They took about the same time to fully load the page.
Side note, it would be very interesting if comments were a DAG rather than a Tree... that way one could respond to several comments with the same thread.
The length of an animation is not the same as making your users wait for an initial response to your input. The rule is talking about how fast the computer appears to acknowledge and begin responding to a user input, it is not talking about how fast any given task is completed. The wait is the length of time between clicking the button and when the screen starts to animate.
Animation you have to wait for can sometimes be a bad design choice on a page, and I'm not a big fan of overuse of css transitions. But a navigation transition helps the user keep mental track of where they are, and it specifically signals that the computer is responding to your input. The animation itself here doesn't break the Doherty threshold, it does the opposite, it meets the Doherty threshold.
Network loading of a new page is unavoidable (out of the control of the page author), is absolutely standard practice for internet apps (see Jakob's law), and your browser (not the page) is what handles the interaction. The browsers adhere to the rules listed here to every extent possible, and they respond to page loads instantly by showing you a loading spinner, a blank page, and allowing interactions like cancelling the load while loading. Again, the interaction criteria here is that the computer acknowledges your input, not that it is required to finish something that can take time.
Scrolling is another interaction that meets rule #2, it doesn't break the rule. The rule is not about design or layout. When scrolling, if the page is moving in response to your input, then it's meeting the rule. And scrolling is one of the things browsers bend over backward to make as smooth and fast as possible.
> Network loading of a new page is unavoidable (out of the control of the page author)
Nope, the author had complete control over how much information they wanted to show on the main page vs the details page. In desktop view they show the single-sentence descriptions on the main page, in mobile they don't. So they've forced mobile users to wait for the network load (potentially much more than 400ms) completely unnecessarily.
> Scrolling is another interaction that meets rule #2, it doesn't break the rule.
Sure, it doesn't break rule #2 specifically, but it does break #3. And, more importantly, it's shitty UX and has no place on a "Rules of UX" website, except maybe as a counterexample.
The alternative here is no visual response to a click at all. I'm not okay with that, and I seriously doubt you'd be okay with it in general. Most people aren't (this has been shown). A 400ms delay after button clicks and scrolling and other interactions is an indication that your input was not received, and it feels intolerable to people today. The 400ms standard here was set 40 years ago. Today software feels completely broken if it doesn't respond with something in under 100ms, and desktop browsers typically do something within 33ms.
> the author had complete control over how much information they wanted to show
That's irrelevant. The browser does respond to your page load request instantly, with a blank page and a spinner. It doesn't break the rule.
Again, you can criticize the choices with your own opinion at a subjective level, this doesn't mean the authors aren't following their own advice. It feels like you're looking for reasons to justify not liking the page. You're free to not like the page, I won't disagree with that. What I disagree with is the reason given.
> Sure, it doesn't break rule #2 specifically, but it does break #3.
It seems like you're moving on to misunderstanding rule #3. Scrolling and clicking does not apply to Fitts' Law.
EDIT: I said scrolling doesn't apply to Fitts' law, and I meant that specifically as a reponse to, and in the context of the suggestion being made here by the parent: scrolling to find a new unknown target plus acquiring a new target, plus moving to click on the new target.
Fitts' Law has been studied on scrolling alone, for example: https://www.microsoft.com/en-us/research/wp-content/uploads/...
Extending the law to include the number of interactions is going to be tautological in the sense that if number of manual interactions is your "distance" then of course more will take longer. Including targets that are unknown is just beyond the scope of what has been studied and shown, I'm saying it is not really in the spirit of Fitts' law. https://en.wikipedia.org/wiki/Fitts%27s_law
Fitts' law is referring to a single interaction ("movement") with visible targets, not a general abstract concept of "futher away" that you can extend in any way and to any topic you want across multiple interactions. It is precisely because you have to use two different movements, as you pointed out, to both scroll to see the target and then move your mouse or hand to reach the target, that Fitts' law does not apply here.
Speaking more generally, there is a big problem with your assumption here that you can take interaction studies (or any scientific results) out of context just because you can think of it as analogous. When researchers have studied human perception and motions under specific conditions, you cannot assume the findings apply to conditions that weren't tested.
You've been confidently wrong about the only two rules you've commented on.
We can discuss form and composition forever, but we all know that a simple scrollable page with screen-high tiles and/or a floating "next" button would do the job a million times better than this. If that was a job-related tool and not a site that you can read once and close forever, I would consider an alternative immediately. Fun fact, I didn't even bother to go further than few "articles" and read 6-8 times more text here itt than on their site in the same amount of time.
Your points are probably correct for a ux that has such problems, but if you do not create a problem, you do not have to solve a problem, and you cannot fail at it (which is easy to do).
FWIW, I'm not discussing form or composition at all, nor am I defending the site's high level design choices at all. I'm just trying to help clarify what the rules on this page actually mean, because rule #2 was misunderstood above. This page has been posted before, and other people have also misunderstood rule #2 to assume it means that interactions have to be complete in a certain amount of time. The rule is simpler than that, and lower level than page layout issues. I would guess that part of the reason this rule is misunderstood is because it's rarely broken these days in commercial apps and web pages. Unlike the 80's, it's not that common anymore for computers to not respond at all in any way to a user input in more than 400ms, and browsers take care of a lot of the cases where it might happen.
"System Response Time. This is the time span between the moment the user enters a command and the moment a complete response is displayed on the terminal."
Note the phrase "complete response" and that the paper itself is titled "The Economic Value of Rapid Response Time".
Yes the phrase "complete response" does sound like a full task finished, but what, exactly, is a "complete response"? Isn't a popup or dialog box or a loading spinner a complete response from a UI perspective? If not, why not?
The definition of "complete response" in the paper is not specific. What were the tasks being studied? Can you have sub-tasks for which there are multiple complete responses? Note the interactions this paper is discussing are terminal commands on a terminal connected to a local mainframe. They didn't have web pages.
There are notes in the paper that give clues as to what kind of tasks & responses they are talking about: "In 1979 their installed system was designed to offer 300 simultaneous users word processing, programming, computing, and remote job entry capabilities, with the response to 80 percent of the transactions being processed in .5 seconds or less."
There are lots of other clues that the kinds of interactions they are talking about are so basic and tiny that we don't even think about them as individual tasks anymore. When you read the entire thing and study the charts, what the paper is really showing is that computers in 1982 were excruciatingly slow, so slow that they interfered with basic word processing and data entry, so slow that they could actually calculate the financial savings of being able to execute shell commands slightly faster.
Even though it says the subjective words "complete response", there are and always have been large tasks that take much longer than 400ms. Does that mean any task that takes longer than 400ms is automatically bad UX? I don't think so, I consider starting a 3GB video download, for example, to be a complete response when the browser acknowledges sending the request, and starts showing progress. I think the paper's definition would agree with that because I can submit other tasks to the computer immediately, I can read other pages, type other commands, save files, etc., etc.
Here is another quote that the paper quotes: "...each second of system response degradation leads to a similar degradation added to the user's time for the following [command]. This phenomenon seems to be related to an individual's attention span. The traditional model of a person thinking after each system response appears to be inaccurate. Instead, people seem to have a sequence of actions in mind, contained in a short-term mental memory buffer. Increases in SRT [system response time] seem to disrupt the thought processes, and this may result in having to rethink the sequence of actions to be continued."
A spinner still disrupts the thought process in the same way. I would personally say that yes, anything that takes longer (I'd say more like 100ms even, possibly less) is automatically bad. It might still be the best possible in a particular situation and pretending that something will necessarily be fast when it often isn't is also bad. It is easier to plan around tasks that take longer when a small and reliable set of tasks take longer and somewhat fits with the theme in that way, but I'd still say the core idea here is "everthing that happens should happen quickly" and have other guidelines to deal with the cases where that isn't possible. Don't try to trick yourself that the system is actually responding quickly when it really isn't.
You could say that the most extreme reading of this principle would imply that a computer should never play video or audio. Personally, I would say it shouldn't except when I ask it to. My top guideline for websites would be something like "your website is not an experience". You can put an experience on your website and some people will appreciate it, but let me accomplish what I wanted to do when I visited your site quickly. Breaking my thought process to insert marketing is not a good experience.
I disagree this is not relevent today; I didn't use a mainframe in 1982 but I wouldn't be surprised if the experience was more responsive than what is common today. Part of this is due to everything making network requests today but in general system response does not seem to be valued particularly highly. I regularly wait over two seconds for a particular text entry box in Windows 10 to work on a fast modern system with an SSD and no network connection that is interacting with a small local database. Windows 7 seemed more responsive to me, as did a lot of older software compared to modern versions.
The paper talks about launching batch jobs. How does that fit into your interpretation of a "complete response"? What would the complete response to starting a batch job have been in 1982?
> I didn't use a mainframe in 1982 but I wouldn't be surprised if the experience was more responsive than what is common today.
I did use mainframe terminals in high school and college, and they were nowhere near the responsiveness that is common today. Not in the same ballpark, not even on the same planet. Our expectations for responsiveness have grown as fast as response times have shrunk, computing today is orders of magnitude more responsive across the board.
> Don't try to trick yourself that the system is actually responding quickly when it really isn't.
That sounds pretty catchy, but is completely subjective, it depends on what you mean by response, which is what we are trying to flesh out here. I'm trying to make the case that in the context of UI/UX best practices this is a red herring. The questions are about interaction and expectations, about acknowledging your input, not about whether computers can magically perform impossible feats of physics. Speed of light prevents some servers on earth from getting a response to you in under 100ms. I do tasks all the time that takes seconds or minutes, and I bet you do too. I disagree that long tasks are automatically bad UX. Bad UX is failing to notify you that you started a task, or failing to notify you that a task finished. Bad UX is giving no indication of how long a very long task will take. Bad UX does not automatically exist merely because a task takes time.
The paper is not talking about turning non-batch jobs into batch jobs (or batch jobs at all really), it is just an aside where they insert magic marketing numbers to sound good. Presumably for practical reasons they would consider the response "batch job started" to be the complete response. I think we can at least agree that it is unhelpful to call an unavoidably long task bad design just for being unavoidably long.
Nothing in the paper suggests that making tasks avoidably long is ok if the system gives an indication it is doing something.
> Nothing in the paper suggests that making tasks avoidably long is ok if the system gives an indication it is doing something.
I can agree with that statement as written, but there are a couple of minor issues with your framing here. One, I didn’t suggest that making tasks avoidably long is okay. I can see why I might appear to have hinted in that direction, but your summary, especially inserting the word “avoidably”, is not a generous interpretation of my words, and I was explicit from the start about stating that I’m not a fan of CSS transitions and not defending the design choices of the Laws of UX site. Two, you already know the context of this paper is 1980, when the alternative to what they actually mean by “complete response” is a blinking terminal cursor that doesn’t move. They’re not talking about partial response of some kind, and they are considering “batch job started” to be a complete response. In that sense, and in the context of the time the paper was written, it is very much suggesting that more quickly giving an indication that it’s doing something is the goal.
Beyond this paper, the broad idea of fast response in the UI/UX and web world has adopted the idea that showing acknowledgement of input very quickly is important. There are multiple examples of this in the nearby threads, and many hundreds of papers beyond Doherty’s that discuss these topics and demonstrate the humans perceptually prefer to see fast reactions even when the final result takes a while.
It might also be worth pointing out that for the arrow buttons on the Laws of UX site, the animation itself literally is the “complete response”. The function of the button is to trigger the animation. Animations are really out of the scope of Doherty’s paper, their idea of a “complete response” in 1980 was a line of text that could display at once.
This is where we disagree. The animation is exactly what I mean by "avoidably long". It interrupts the user the same way the long response times mentioned in the paper do. If you quote this paper, expect people to say that it means what it clearly states since this is a source of real frustration for many of us. As I mentioned earlier, some people do appreciate a more paced "experience", but many of us never want such an experience from a website and just want rapid response.
Yes, the length of animation is a design choice, and is in that sense avoidable — precisely because the length of time the animation plays was a conscious intent. What you’re talking about is not related to what Doherty’s paper was talking about.
CSS transitions can be fine, but they shouldn't block user input or force the user to wait until they finish before moving on.
For this particular instance it might not matter a ton that they broke rule 2. But imagine if this was a table of paginated data, having to wait up to an extra second each time you go to the next or previous page just so the data could animate in would be rage inducing after a long period of time.
I do agree that transitions shouldn't make you wait, and I mentioned above that I'm not the biggest fan of transitions. BUT the transitions here do not break rule #2, regardless of whether they are good design or not. Forcing you to wait as part of the interaction is not the same thing as not responding in the first place. The animation is the response to the input, and it acknowledges that the system is up and running.
A good way to understand rule #2. Here are two scenarios. A breaks rule #2 and B does not break rule #2.
A - You hit a button that makes an AJAX call. The response takes 10 seconds to arrive. The CSS has disabled button hover highlights, and button press state changes. There is no indication on screen that the request has been made.
B - You hit a button that makes an AJAX call. The response takes 10 seconds to arrive. Default CSS rules show the button press, and the page pops up a loading spinner.
(I found this because I already read the first 2-3 laws and closed the page, reopened to see the "Details" and wanted to quickly navigate to the middle/end of the list. Instantly the site felt super sluggish and unresponsive)
I totally agree with you BTW, clicking a button and having a quick (<200ms in my eyes) visual response is completely fine, even if that response is just a CSS transition. I do this all the time.
The specific problem I had is the NEXT button stops responding during that CSS transition which might not technically break rule #2 but definitely makes the UI feel sluggish and non responsive.
I'd also note that rule #2 serves a more specific purpose than avoiding any wait times. It's there to avoid confusion about what's happening in response to a click, not to eliminate all waiting, nor to eliminate all annoyances in UX delays. With a transition, it's annoying that you can't interact while the animation plays, but it's not (in this case) confusing about what's happening. I know why the button isn't working, and very quickly I know how long I have to wait before it works again, even though I'd rather that it did work instantly.
On a technicality, I'll mention that a 400ms transition technically isn't more than 400ms, it's equal to 400ms. That's just me being cheeky though, it's irrelevant, because rule #2 is met on my laptop within 17ms when the animation begins.
Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
Further, from the original study itself:
"When a human being’s command was executed and returned an answer In under 400 milliseconds, it was deemed to exceed the Doherty threshold, and use of such applications were deemed to be “addicting” to users."
My answer has not been returned within 400ms, and I had to wait for the computer, and the site was so un addicting that I exited out after suffering through those animations only 2 times. Thus not a single interpretation of Doherty threshold in its original form has been met. It’s really quite simple.
If acknowledging input rather than returning an answer was all that was needed, the rule would state as such and the old hat engineers making the original computers would have had wired “Enter” up to “bell” and called it a day. Luckily they weren’t nearly as lazy as many in this thread seem to be.
For cases such as the “downloading a 3gb file” that get brought up, I’d consider the “answer” to pressing the download link to be the dialog box saying that a download has started. I would not consider the “answer” to clicking a link to be an animation saying... I’m not sure what; rather, the “answer” to clicking a link is clearly my browser starting to navigate to that link
Side note: just for funzies, I patched vscode to show a loading animation for 400ms before opening new files. After playing around with it for a couple minutes, I can assure you that if I pushed that to master, insiders users would come screaming tomorrow morning and all the “well actually this is in compliance with XXX law because technically...” would not appease them. If you wouldn’t accept it in your editor, why accept it in your websites?
Edit: Exact test of rule 2:
Nowhere does it say that waiting is only bad if you don't see something happening. I am waiting on the computer to finish it's little jig. That is bad, and a violation of rule #2.
My answer has not been returned within 400ms, this the Doherty threshold has not been met.
If Amazon had a 400 ms animation for every purchase/page load I would be very upset.
If an art project had a 400 ms animation, that would be part of the art.
Shouldn't this be normal?
Instead, I think links taking you to pages where the content is immediately visible should be normal.
Craigslist is a great example, original reddit is another example: my UI/UX designer friend considers original reddit to be quote “ugly and horrible”, and while there definitely could be some improvements, the reddit redesign (which I know my friend would come up with something similar to) is quite literally orders of magnitude worse, but is aesthetically “nicer”.
Original reddit looks ugly, but everything you want from an interface is there once you get through a 3 minute learning curve: information dense, enough white space (but not too much), consistent behaviour, fast, respects scrolling, etc etc.
Where did we go “wrong” with web design that what we have now is seemingly worse? And what does a good balance of “actually functionally useful” and “aesthetically pleasing” look like?
Now I just need HN to do something similar and maybe I’ll get back to being a productive member of society ;)
Granted, I have a cheap not very fast laptop, but it's less than a year old and almost everything else works just fine – certainly not as horrendously slow as Reddit. These problems seem to disappear if you gave a faster machine from what I've been told.
But, yeah; it's broken for millions of people who have low-end to medium hardware. I genuinely don't understand how they could ship something so dysfunctional for so many people.
Infinite scroll kills it after a while for me. You must spend less than 4 hours per session.
* Make users use the app
* Make Reddit more like Instagram (browser visual content)
As a non-designer who's had to fight many designers on this, I'd like to draw your attention to the fact that this is about perception. It's about a user's first impression regarding usability prior to actually using the system. It's not an actual impression based on their experience after interacting with it. That impression can quickly evaporate the moment they try to do anything with the interface. If time and money have to be allocated to develop a product, use them wisely. The properties of this principle seem to be more relevant to marketing and advertising than actual UX.
I believe that the wrong take-away from reading this law would be that improved esthetics implies improved usability. Attempting to place esthetics and function on the same pedestal would be a mistake. When it comes to usability, function is superior to esthetics and should almost always be given priority, no matter how ugly.
I agree that esthetics can and should be used in a way that it supports function, but as you add to it, there will always be a point of negative return (functionally speaking). If you misunderstand what that law is saying you might be misled into thinking that esthetic climax and usability climax are on the same locus. I think we can agree that something can often still be made even more beautiful way past the point where it's almost completely unusable. Adversely, you might be called into making something uglier in order for it to become useful again. Better get comfortable with the idea.
Even 'compact' views which seem to be a throwaway effort to alleviate these are becoming more and more spacious and forcing scrolling even on huge screens.
Putting additional effort on aesthetics can encourage these users to consider your product with fresh eyes, or give it a chance when they otherwise wouldn't. Of course, past that initial help you need "real" usability to keep them.
For example, I would pay a lot of attention to this principle if I was working on a product in the payment space (e.g. Stripe), taxes (e.g. TurboTax), etc.
Also, I commonly see Miller's and Zeigarnik Effect being disregarded: although our working memories are not so great, we possess some and we can retain some basic information about our workflow. Then, IMHO there's more harm than good in putting a lot of visual clues, drawers, panes over panes etc. so that navigation is "improved".
Speaking particularly about form-based enterprise applications, I keep thinking that some important empirically learned lessons from the last 40 years are simply being thrown away. Simple, correct and, most important, FAST interfaces trumps everything else, even if it's a TUI.
Oh, and regular users also can and ENJOY using the keyboard -- a tool which is being deprecated in this mistake of trying to create a uniform experience between desktop and mobile.
Also: At work I make internal software for managing basically everything. We do not use any animations, besides one for dropdowns. And those are only .1 second long.
So, I kinda tend to think that animations/trying to be clever in interactions are actively harmful.
Speaking of being clever, the new reddit layout seems to try to be a single page application. I hate those quite a bit, due to making it much harder to browse.
They all have pretty much the same functionality, but some hide functionality for UI's sake. Then anytime I need to do something new, instead of looking around a busy screen, I'm sifting through a bunch of websites I found on google.
If, by removing widgets, those interfaces are making you to perform more steps and to think more to find and execute the functionality you need, then I'd say those interfaces are getting more complex actually.
Besides, this is another common mistake in current UX trends, IMO. They seem to assume that interfaces can always be simpler, as if there weren't fundamental bottom limits to complexity; and, to make things even worse, they remove widgets, replace text with icons etc., seeming to believe in a positive correlation between complexity and amount of stuff in the screen
1. Universal Principles of Design https://g.co/kgs/X19MeR
2. The Humane Interface by Jef Raskin https://g.co/kgs/JfdBkB
Edit: bear in mind vanilla search URLs include personal info, which you need to know how to identify & strip.
Edit: Specifically, I think I can make the website easy to use, but I have no idea how to make it look good.
Rough Design Process 
- Have you identified your users and the need that you are hoping to solve with this "part/feature"?
- Usually users are broken into different segments, a persona is just like a rough representative sample of the different segments.
- It sounds like you work for a for-profit organization, therefore you must also understand who your stake holders are and what they think the business needs are (they can be wrong and you might have to help correct this).
- Are there already people doing something like what you're trying to do? Not only should you benchmark competitors, you can look for analogous situations in totally different domains and still use this to help inform you.
- Redefine the problem your own way.
- review research claims, scientific literature, external info
- explore insights
- design objectives
- develop user POV and need statement
- low fidelity prototypes based on the perspective of your user needs and POV from (2), explore solutions to the problems
- you should be going for volume at this stage because this is a discovery oriented process for finding unknown unknowns
- escalate the fidelity of prototypes enough that you can gain feedback from potential or actual target users
- end points for higher resolution prototypes should definite measurable analytics and success metrics so some prototypes can be selected for further refinement, ideation and testing
- you can conduct formal usability testing, but the point of a prototype is to create an object to fuel conversation and discovery
 "1 hour of research saves 10 hours of development time" http://bokardo.com/archives/1-hour-of-research-saves-10-hour...
This is my derivative of Stanford's Design Thinking process taught at dschool.stanford.edu, for a worksheet example see: https://static1.squarespace.com/static/57c6b79629687fde090a0... on dschool.stanford.edu)
I'm specifically building an internal tool for service-requesting, thus the users will be from our own company and there is no competition to speak of. Most of the points you listed still apply, of course, but I'd still like to ask if you have any tips that could help me in this concrete situation.
And also, where would you recommend me to look for inspiration? (apart from "just look around on the web") Nowadays I often look at tailwindui.com to get an idea how some particular component could look like, but there must be something better. Awwwards and dribbble (at least at first sight) are too landing-page oriented — not something I could use in an internal service.
That aside, what most UI/UX rules fail to capture is that our experience of X exists over time and in larger context. Aside from things with near-zero intended lifespan (which this one may well be—I won’t pretend I know author’s intention), it is not only (and not so much) important how a product or resource is experienced right at this moment, but also how it will feel after a while, how it would evolve, how it interoperates with other software or resources (including search engines), what resources are required to maintain it, etc. True beauty arises from functionality and sustainability.
Please put more than one thing on the screen at a time, especially when those things are links that lead to the actual content.
Also, when I click through to one of the laws, there's no indication that I have to scroll down, so I'm clicking around for a few seconds like an idiot trying to figure out what to do.
I feel like I'm crazy... Is this really considered good UX?
The average HN user probably:
- knows their way around a terminal
- understands default browser behavior in depth
- has the programmer's mentality of 'everything should be governed by universal logical rules that apply equally everywhere'
The truth is, this is not how most users think. Good UX for a cli application is not the same as good UX for a website. If you think of websites in terms of what programmers think good UX is, you get... HN and Craigslist and all the other things that HN users typically think are fantastic user experiences, because they meet their expectations. These applications are also almost uniformly ugly. This actually makes perfect sense, and for these users, this is fantastic UX.
But what makes UX good is that the target audience can easily use the software. That's it. There's no such thing as an 'intuitive user interface'. Clicking on stuff in computers is not natively intuitive to humans. There are only familiar and unfamiliar interfaces. Every interface we haven't seen before is unfamiliar and 'terrible' at first glance. People will train themselves to use and love extremely bad interfaces, or refuse to use very good interfaces that are difficult to learn. The HN user is someone who has typically put a lot of effort into learning how computers work and how web browsers work by default, so they develop intuitions like, "If a website breaks the default browser behavior, it's bad UX." And for them, that's true, but what makes the default browser UX better than an alternative, other than that you already know it? Now maybe it actually is better, and I can think of many examples of websites that change default behavior in ways that are absolutely worse. But I've also seen websites do cool things with scrolljacking that aren't inherently wrong because they defied expectations for 3 seconds.
Every application has to be learned by the user. How easy it is to learn it depends on the background knowledge and experiences of the user, so it's very very hard, if not completely impossible, to develop a UX that will be good for every possible user. But if some UX isn't good FOR YOU, that doesn't mean that it's bad, it might just mean you aren't the target audience.
So would you argue that the Craigslist experience is only good for those with the "programmer's mentality"? "Ugly" is perhaps a smaller factor in UX than designers account for.
> And for them, that's true, but what makes the default browser UX better than an alternative, other than that you already know it?
Nothing, that's just it: you already know it. What you call "programmer's mentality" is actually fundamental to human cognition. In making sense of things we use what we've already made sense of. The more we can rely on our existing knowledge to figure something out, the less cognitive friction there will be.
The cost of surprise can certainly be outweighed by other factors, or surprise in itself can be exploited to usefully convey something, but in my experience it is not generally used to these effects. For every zooming interface or slideshow where scrolljacking might make perfect sense there are hundreds where those three seconds of defied expectations are wasted to implement something that is either useless or entirely detrimental to usability.
> But if some UX isn't good FOR YOU, that doesn't mean that it's bad, it might just mean you aren't the target audience.
Or I am the target audience and the designers have failed to design for the target audience. Or I am not the target audience only because the designer has failed to identify and characterize their target audience correctly. Or the designers primarily work with making business-required anti-features bearable. Or they're optimizing for first impressions and not long term usability. Or they're optimizing for generating more work opportunities ahead of themselves.
To decidedly say that you, our user, is not our intended target audience seems like a conclusion that must be backed with a lot of data, something which IME not a lot of organizations can muster. From that perspective these alternatives seem more likely.
> So would you argue that the Craigslist experience is only good for those with the "programmer's mentality"?
No, I think I was clear - I think the Craiglist experience is good for people who are familiar with simple sites like Craigslist, but not for all people. Craigslist has a very simple UX, so it would be hard to find someone who had trouble using it. It would be easy to find someone who finds the UX unpleasant, because I personally find it unpleasant because it's very ugly.
> Nothing, that's just it: you already know it. What you call "programmer's mentality" is actually fundamental to human cognition. In making sense of things we use what we've already made sense of. The more we can rely on our existing knowledge to figure something out, the less cognitive friction there will be.
Here, you're just agreeing with me, except that I didn't call the "programmer's mentality" the general rule of familiarity, it was the general rule that all things must behave according to the same rules.
> The cost of surprise can certainly be outweighed by other factors, or surprise in itself can be exploited to usefully convey something, but in my experience it is not generally used to these effects. For every zooming interface or slideshow where scrolljacking might make perfect sense there are hundreds where those three seconds of defied expectations are wasted to implement something that is either useless or entirely detrimental to usability.
I'm not claiming anywhere that it's impossible to make a bad UX, either by breaking previously known rules OR by following them, I'm claiming that good UX is context based and the rule of "scrolljacking is always bad" isn't true. You seem to agree with me here.
> Or I am the target audience and the designers have failed to design for the target audience. Or I am not the target audience only because the designer has failed to identify and characterize their target audience correctly. Or the designers primarily work with making business-required anti-features bearable. Or they're optimizing for first impressions and not long term usability. Or they're optimizing for generating more work opportunities ahead of themselves.
Sure, bad UX exists, and these are plausible reasons why it might happen. I never claimed that no UX ever was bad for any reason.
> To decidedly say that you, our user, is not our intended target audience seems like a conclusion that must be backed with a lot of data, something which IME not a lot of organizations can muster. From that perspective these alternatives seem more likely.
Here you're either misunderstanding me or knocking down a straw man. I didn't use the word 'decidedly', I said it 'might mean'. I also wasn't focused on the perspective of the organization or person creating a user experience, I was focusing on the person consuming it and criticizing it, without any regard for everyone else who also consumes it and whether they might agree that the UX is 'obviously' terrible.
To give a concrete example: Slack recently released a redesign, and I personally hate it and many of the interactions it created. Most people I know love it and had no issues adapting to the changes they made. Did Slack release a bad UX? I would argue no, even though I personally do not like the UX they created, because I think I am a rare case and for the majority of their userbase, they made the correct call and improved the experience. It seems to me that most arguments on HN about UX boil down to "I immediately closed the tab because it hijacked my scrolling, terrible UX." I'm saying that's a bad argument, and your personal enjoyment is not a complete picture of what makes an experience good or bad for the complete audience of users.
I'm not sure that motivation deserves praise.
Provide system feedback within 400ms in order to keep users’ attention and increase productivity.
That's horrible lag. Try 30ms. I get frustrated whenever the responsiveness is slower than I can hit keyboard shortcuts or click. I even turn off Android animations as they slow me down.
Touch targets should be large enough for users to both discern what it is and to accurately select them... Touch targets should have ample spacing between each other
Sure thing hoss. But don't take it too far. The wasted screen real estate on your site is abominable.
...I had to stop after the first few...
Some of these may be more pertinent while analyzing User Experience compared to composing User Experience.
Occam's Razor: What is this control meant to do?
Pareto: does this UX cover at least 80% of the user's needs? Are there critical cases in the remaining 20%?
Parkinson's Law is more of a bank shot, but think of it along with the Pareto Principle: Organize the UX so that the user can accomplish the most important tasks in the least time.
No. I’m saying if you squint hard enough, then maybe you can think of how these apply to UX, but they don’t directly indicate some insight of UX, in any way like the others do.
> Occam's Razor: What is this control meant to do?
If that’s how they mean to apply it, they should phrase it as “users make the inference about the control that requires the fewest assumptions about how to model the UI”. There’s a big difference between saying how users actually act, vs how you as an engineer should infer, or what you should optimize for.
And yes, if the latter is meant, then it’s applicable on some level, it’s just not specific to UX (just making inferences about data in general), and even then didn't make clear how it would apply in a UX scenario.
>Pareto: does this UX cover at least 80% of the user's needs? Are there critical cases in the remaining 20%?
That wouldn’t be the Pareto principle, that would be “check the 20% for if you’re missing something critical.”
Again, a tangential application, if you stretch, just not direct like the others.
>Parkinson's Law is more of a bank shot, but think of it along with the Pareto Principle: Organize the UX so that the user can accomplish the most important tasks in the least time.
That's orthogonal to Parkinson’s law, which says that time spent will bloat to its bounds. What you’ve described is a different principle, something like “minimize the time average spent to do tasks, thus giving more weight to the more frequent ones”.
LATE EDIT: With that said, those three should definitely be part of any UX engineer's mental toolkit ... but only in the sense that they should be part of any engineer's toolkit. The specific applicability to UX isn't obvious the way the others are, at least.
I think that's fair. I will say that I appreciate this site, but I do think the author had to stretch a bit to get to 20 rules. For instance, I would have had a section just on the Gestalt Principles because they don't make much sense by themselves.
Aesthetic Usability Effect
01 Users often perceive aesthetically pleasing design as design that’s more usable.
02 Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
03 The time to acquire a target is a function of the distance to and size of the target.
04 The time it takes to make a decision increases with the number and complexity of choices.
05 Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
Law of Common Region
06 Elements tend to be perceived into groups if they are sharing an area with a clearly defined boundary.
Law of Prägnanz
07 People will perceive and interpret ambiguous or complex images as the simplest form possible, because it is the interpretation that requires the least cognitive effort of us.
Law of Proximity
08 Objects that are near, or proximate to each other, tend to be grouped together.
Law of Similarity
09 The human eye tends to perceive similar elements in a design as a complete picture, shape, or group, even if those elements are separated.
Law of Uniform Connectedness
10 Elements that are visually connected are perceived as more related than elements with no connection.
11 The average person can only keep 7 (plus or minus 2) items in their working memory.
12 Among competing hypotheses that predict equally well, the one with the fewest assumptions should be selected.
13 The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes.
14 Any task will inflate until all of the available time is spent.
15 People judge an experience largely based on how they felt at its peak and at its end, rather than the total sum or average of every moment of the experience.
16 Be liberal in what you accept, and conservative in what you send.
Serial Position Effect
17 Users have a propensity to best remember the first and last items in a series.
18 Tesler's Law, also known as The Law of Conservation of Complexity, states that for any system there is a certain amount of complexity which cannot be reduced.
Von Restorff Effect
19 The Von Restorff effect, also known as The Isolation Effect, predicts that when multiple similar objects are present, the one that differs from the rest is most likely to be remembered.
20 People remember uncompleted or interrupted tasks better than completed tasks.
Rule 21 should be: don’t make the user click 20 times.
<h1>Laws for good User Experience (UX)</h1>
<dt><a href="https://en.wikipedia.org/wiki/Aesthetic%E2%80%93usability_effect">Aesthetic Usability Effect</a></dt>
<dd>Users often perceive aesthetically pleasing design as more usable.</dd>
Allow humans a fudge factor for ease of use, but not at the cost of integrity.
For instance, allow phone numbers with separators, or spacing, or shortened versions etc. It's aggravating when a form asks for a cc number and allows a user to type spaces but the field has a max length so you have to backtrack and delete all the spaces.
Make apis conservative in what they accept. This reduces complexity and the likelihood of bugs.
If you’re allowing basically anything in, eventually the wrong person with the wrong code will get in. And that might very well be the last day you have a business.
Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know."
A lot of designers should write this down 100 times before they start working. An extension should be
"users prefer your site to work the same way as it did yesterday since that's what they already know."
Can we also have some rule about the maximum frequency of changes? Alternatively can I go one further and suggest that for UI/UX changes, agile style sprints are absolutely not the way they should be done? Rushing out change after change in the UX won’t let you actually see what works and, and let you iterate, it just disrupts users. These changes should be thoroughly thought through, distilled, tested properly - not wildly deployed onto a subset of users, and if necessary, grouped up and deployed altogether so that there is only one UI change to adapt to, not 30.
that's what I am disliking more and more about rapid releases. If there is a big change once a year, I can take time to read the release notes and learn what changed. But if there is a change once a month I can't keep up.
“Users don’t want to use your software, they want to _have used_ your software.”
Users come in with a task they want to perform, not so they can bask in the glory of your wonderful UI.
Is that right? Personally I feel like the opposite is true; I'll take an ugly looking but very usable UI over one that has all the bells and whistles but is actually a nightmare to use. Surely when the UI is bad and the UX is also bad the effect is compounded, and first time users might very well perceive the combination of bad UI/good UX as much worse than good UI/bad UX, but I really don't think this should be given out as good advice.
If you have two websites with very similar UX, both very usable with the same quirks, one beautiful and one ugly, users will be more forgiving towards the beautiful one.
I have a problem with that law.
EDIT: TL;DR/Clarification: What matters is what users believe as "intuitive and easily usable" which is not implied by something being familiar nor by what most other sites or apps do.
People don't want your site to work like other sites at all.
They want your site to work "intuitive and easily usable" for them.
As such they only want your site to behave like other sites if what they perceive as "intuitive and easily usable" was coined bye such "other" sites.
But in reality what user perceive as "intuitive and easily usable" is often largely coined bey the UX patterns around which they "learned" to use tech initially.
Which means what is "intuitive and easily usable" is often displaced in time and depending on your audience might MAJORLY differ from what most other sites you can find today in the internet do!!
A good example is sourcehut (e.g. look at `https://git.sr.ht/~sircmpwn/scdoc`).
It's visually completely different from what most other github like sites do and probably for some people it might look bad.
But for their target audience it's supper appealing as it appeals to what that audience originally learned to be "intuitive and easily usable".
So I would strongly argue that Jakob’s Law is a harmful over simplification of the actual effect which might be ok for some target audiences but literally might brake your business if applied blindly.
HN doesn't have backticks syntax, so the trailing one is getting inculded as part of the link and 404ing. Fixed link: https://git.sr.ht/~sircmpwn/scdoc
A stronger criticism, at least in my opinion, is that presenting observations about user behavior as "laws" is misleading, since humans aren't particles. You can have laws in physical science, but not in design. If you thought of these as laws rather than wise words to bear in mind, you'd be an ineffective designer.
I wonder if site creator can be persuaded to replace that js dependency with the "checkbox hack" at least for the basic navigation.
- At first, the site looked like a slideshow with prominent prev/next at the top and a title content that takes the entirely of my desktop monitor. So, naturally, I hit the keyboard right arrow (like most slideshow web pages) to get to the next slide for content, and nothing happened.
- Then at the bottom left, there's a down button. So I scrolled down to find the content there. I read it, and still subconsciously hit keyboard right for the next slide...oops, I mean, page...because of the prev/next at the top (sure, pebkac and all that; but it's also expectations-setting).
- Then I clicked on "next" to get another page that again takes the full monitor for the title, requiring scrolling down to get to the content, all of which can easily fit on a single screen. It seems unnecessarily "distracting", in a sense, since the expectation is that the user would actually go through the content and not just the titles which themselves are not very informative.
- One way I tried to improve ergonomics was to hitting page-down to read the content and then tab a couple times to get to the next button (almost automatic). However...the focus indicator for the "next button" has been removed in CSS, which is another usability nono.
Of at least tangential relevance here are Doherty Threshold (slide 2) and Jakob's law (slide 5). Just my 2c.
Figures that would be rule number one. Everywhere you go there are pretty UI's that are garbage, functionally.
Animation, transparent fading, no distracting scroll-bars or borders, wrapped around a 1-2-3 menu selection.
> Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.
That is just nonsense. Productivity soars the faster the computer is. Ideally, the user should never waits for the computer; everything should be instant.
Whether the user waits for the computer is neither here nor there.
The ultimate computer-does-not-wait-for-the-user is to have the users prepare job specifications entirely outside of the computer and then submit them to a clerk at a job window. The computer never waits for a user because the job queue is busy from numerous users. It is not very good UI.
In an actual interactive UI, a needless delay could be caused by, for instance, collecting the necessary parameters for an operation through a cascade of multiple dialogs instead of batching them together. Though the computer waits more, too, that's irrelevant; the user's time is what was wasted.
I'm amazed anyone pretending to be a UI person would even feign being interested in how much time the machine spends waiting for the user.
Also, the nature of the tasks that users performed in 1982 may have meant that there was no benefit to <400ms response times. (If it takes twenty seconds to read and understand the output, and another ten to key in your next command, then a 400 ms delay is not a meaningful productivity drag.)
Today, I would guess that the threshold is closer to 50 ms.
(Also, "time spent by the computer waiting for the user" makes sense in the context of a 1982 research paper. That has changed in the last 28 years, to say the least.)
All of this is a long way off saying that if you are making UX decisions based on 28 year old research, you are on shaky ground!
The microcomputers I used in 1982 had instantaneous response time.
Most of the software was developed by assembly language die-hards.
400 ms is more acceptable if there is no jitter in it, in comparison to unpredictable response time.
I’d be over the moon if most websites did things within 50ms, even 100ms would be a significant and welcome improvement.
Anecdotally, when I’m working on the database at work, the olap database (Clickhouse) feels amazingly snappy because it’ll respond in around 30-60ms, but SQL server feels like molasses, even when doing queries each dB is designed for.
2. avoid low contrast between text and background (it's hard to read your light gray text on white background)
3. make it clear what a button is and what a label is (a blue label being a button on iOS)
4. avoid wasting screen space, stop making fonts huge unnecessarily (if you wasted half the screen size by couple of words or there are big empty spaces where is your content really, what are bigger screens good for then)
5. stop designing desktop UIs like it was a smarphone (scrollbar should really be big enough to move by mouse and handle should have contrast to the slider; I am not touching my desktop screen or scrolling by swiping and hopefully never be)
6. for text content (descriptions, articles, comments, etc) stop preventing right click, copying text or messing up with clipboard (like appending some garbage at the end of copied text)
7. stop inventing original design widgets no one asked for and it is not immediately obvious how they work and easy to use / just an additional option (I have seen many toggles where it was unclear whether they are in On or Off state; or widgets lost ability to be controlled by the keyboard; or date fields which I could fill in in 2 seconds by keyboard but they forced me to spend minutes by selecting year first, listing months, finding the day in some unnecessary calendar popups)
Certainly some fine UI laws in action.
In some contexts (selling), certain things are more important, like having a beautiful appearance and no data overload. Your first time user may be your most common user, because they may only make one purchase per [lifetime, year, etc]
In other contexts, for instance industrial controls, data density is more important, and the user may be expected to take more time to learn the interface. There is still some need to accommodate new users, because everyone is a new user at some point.
In any case, there is a decision to be made, aided by some data presentation.
This cobbler's children have no shoes. Not because he doesn't care about his children, or can't be bothered after a long day. No; this cobbler simply doesn't know how to make shoes.
edit: is the site satire? Poe's law is strong with this one.
The claim that better aesthetics are perceived as better usability is based on a 1995 study by Kurosu and Kashimura. The study was done on 156 students of a Japanese design school and 96 students of a Japanese university psychology course.
That's already an over 160% sample bias towards very likely extremely aesthetically-minded people, not to mention that the Japanese have an ancient culture of aesthetics (https://en.wikipedia.org/wiki/Japanese_aesthetics) which in itself renders the study and its conclusions culturally irrelevant to global audiences.
Thus, for the breach of the Laws ot UX, by the authority granted to me by myself, I sentence the author of the website to 2 months of studying GNOME HIG. 
(Non-affiliate link. I'm just recommending a book I found helpful...)
What IS interesting is how many times this site(https://lawsofux.com/) has been submitted and not received ANY comments and now about the 10th time it got submitted, it has 226 comments :) ? lol HackerNews can be so weird at times.
I wrote more about this here: https://simpleprogrammer.com/information-architecture-develo....
I wanted to read your thoughts but your pop-up modal prevented me from reading your article and also decreased the probability that I'll ever visit your website again.
i hope they don't sell a single book as this serves as an example of how to not do UX.
It seems that it got updated with double the rules since then.
If you want to learn about UX, Nielsen Norman Group's website is a good place to start:
While likely accurate, this thinking is likely not conducive to UX innovation.
Also, this site is impossible to read?