Hacker News new | past | comments | ask | show | jobs | submit login
Nielsen's Ten Usability Heuristics [pdf] (2020) (nngroup.com)
96 points by andsoitis 9 months ago | hide | past | favorite | 40 comments



I had to read The Design of Everyday Things in college and was nodding along the whole time: yes, of course, this is so simple! It feels like common sense, but it is good to see it written out so plainly. It should be required reading for anyone creative, i.e., anyone who might create something, anything.

I get why some commercial websites fall into dark patterns (it's because they want your money). I get that years of iterations can make old software feel clunky. I just can't believe how poorly designed some new internal business applications are, even with how easy modern low code application platforms make designing interfaces/processes.


Design, real design, is HARD.

Basic things like line length, contrast (black and white people) get screwed up by most app/web designers and devs. Then we gave all sorts of font tweaks to web monkeys and its been down hill for readability...

But a lot of it sucks because everyone feels like they can bike shed the interface, somehow design is "opinion" and not an art/skill.

Here is a blast from the past: https://getlevelten.com/blog/randall-knutson/why-web-develop...

Somethings haven't changed.


Actually design is not hard, it's mainly common sense and iteration + book learning. Where people go wrong is being unable to leave their ego at the door so they insist their design is right and don't look at the facts.


Where people go wrong is by letting management dictate design.


> It should be required reading for anyone creative, i.e., anyone who might create something, anything.

I agree. I have found that designers refuse to read it. They don't like usability at all.

My experience is that designers want users to admire the UI, as opposed to use it.


> My experience is that designers want users to admire the UI, as opposed to use it.

This is a biased generalization, like "engineers are nerds that don't like to interact with other people." Which is wrong.

I work as head of UX, and my career path started in computer science, and I became more interested in user interfaces.

Today's UI results from the legacy of designers from diverse backgrounds (like Alan Cooper, Brendan Laurel, Larry Tesler, Donald Norman, Maeda, and many anonymous ones who worked on successful products).

No matter what the background is, most designers care about usability.

But where does the prejudice of "designers only care about visuals" come from?

Many founders, CEOs, CTOs, etc; the people defining a product don't have a background in product design. That influences the hiring and company structure.

When you hire a designer only by its visual portfolio or outsource a crucial part of your product experience to an agency with the mandate of "make it look pretty." That's what you get: a pretty-looking but shallow UI. You can see that on Behance and Dribble: most of the designs are nice-looking dashboards that are useless. The intention is to show the visuals because understanding user needs and defining the information architecture is unattractive (and takes more time).

The core of the problem is what we understand by design.

If you want to create a good product, design is the result of the work of many people. It includes testing ideas, re-working things that don't work well, and interacting with many roles in the company to understand the business and the technical constraints. It requires a lot of collaboration. People like Steve Jobs are often praised because doing those things requires leaders who see that as a priority. But that's rare. Most leaders would love top-notch product experiences but underestimate the work needed.

If you see design only as the result that a designer handed you in Figma to enter into a mini-waterfall process, then yes, the result is probably a UI designed to be admired and not used. Because that's the output, your organization asks for the designer role.


> But where does the prejudice of "designers only care about visuals" come from?

This isn't prejudice, it's just observed factual reality in the world. The entire flat UI thing came about as a fashion, and had as its consequences the removal of affordances (scroll bars, buttons that were clearly buttons, etc.) You might not like that people question it, but it's nevertheless a thing that happened and is still happening.


It's also an observed factual reality that there were many terrible software development trends: XML everywhere, SOAP, microservices architectures (even if they do not apply), YAML in every config file, etc.

Every specialization has those trends, which are often copied without analysis.

I don't have any problem with questioning those trends. However, criticizing that YAML may not be the best way to build a DSL is not the same as saying that all engineers don't care about systems architecture and only use the latest framework.


> But where does the prejudice of "designers only care about visuals" come from?

Probably from modern computer UI design, where this seems like a reasonable conclusion based on how common it is for UIs to be really hard to use.


Fair point.

I apologize for the apparent generalization, and appreciate the reply.

However, it has been quite common.

Back in the day, my company worked with Pentagram for visual design, and DDO, for interaction.

We found that we could not get a single entity to deliver a comprehensive solution.

But, as a bit of a riposte, I did say "It has been my experience." It wasn't a generalization. It was a report of 30 years' worth of experience.


You are forgiven, no worries. :)

My extended response is because this is something that I see very often. The blame is put on "the designers" (in the abstract), but it is deeper than that.

> We found that we could not get a single entity to deliver a comprehensive solution.

I can relate to that. But the problem is more than just the designers. It's a mixture of things. A comprehensive solution should include a comprehensive approach. That's the hard part.

It's hard to prioritize as a designer when user experience is not a priority. Take, for example, "undo". Every usability guideline will recommend you have an undo (a "trash" area in an email UI is an undo, too).

But having that functionality is an architectural decision (like most UX decisions). You can design that without issues if the whole team is on board. But when "design" is merely the "V" in MVC terms, there is a strong push for showing a visual confirmation: easier to develop and design.

When an agency does the design, you also have a monetary incentive: it's better for the agency to hand off the nice-looking design rather than enter into a negotiation with the engineering team about why it's essential to expend a month having the architecture to support that "undo" button.

Also, the "undo" button should be paired with principles applied across the product. You spent a month adding undo to a single part of the product, but another part doesn't have it, and instead of doing things better, it makes it worse. This piecemeal growth is also common in engineering; the difference is that most users don't see that mess. I wish to have a simple solution, but there isn't one. It requires a lot of work, from business strategy to process organization.


I really appreciate your answers!

I feel like the tech world could use many more discussions, like this.

Thanks!


This is easy to fix:

Find 8 people to use your app, get their feedback, record them using it (what they do and say)...

Do this once or twice, when the mortals complain and stumble over the same things every one in the company did designers get the memo pretty quick.


That is exactly what I did (50 people).

The designer thinks I'm a big ol' meanie with control issues (they're right), but they do listen to feedback.

That's why I have been running such a long beta test. The others wanted to ship, six months ago.


Internal business applications are going to be a lot clunkier than a publicly available web interface.

The reasons are typically:

1. They are designed for a few number of users, so they can automate an internal task. The application seems complicated and uses a lot of language specific to the domain.

2. Generally under invested in. These are great learning projects for people to do, but it also means the implementation will probably be substandard. Work arounds will be discovered for the known bugs, since the users all in the same company anyway. These projects reduce OPEX/COGS, they don't directly contribute to Sales/Revenue, so they aren't as important for the company.


I know I didn't give any examples, but this has nothing to do with funding or domain knowledge. I'm talking about people going out of their way for bad design. Like a form with a submit button that was tiny compared to a very prominent reset button, or background colors that changed jarringly on hover. These are deliberate choices in this era of LCAPs.


> I had to read The Design of Everyday Things in college and was nodding along the whole time

Same here. I started reading it twice, but quit each time, because it was telling the obvious.


My Kia EV6 has a great example of bad design, specifically #2, "Match between System and the Real World".

The gear selector (which just selects forward or reverse) is a rotary knob.

You twist it to the right to go forward, or twist it to the left to back up.

There are a couple of photos in this review:

https://www.jdpower.com/cars/expert-reviews/2023-kia-ev6-rev...

Even though I've had this car for a few months now, I still get this mixed up once in a while.

There is at least one report on the EV6 forum about a a crash while parking that was almost certainly due to this UI blunder:

https://www.kiaevforums.com/threads/unexpected-acceleration-...

What pains me is that there is a simple solution Kia could have used: a little paddle that you push forward to go forward, pull back to back up.

Then there would never be any confusion over which way to turn the knob. You would have a direct mapping between your action and the car's motion.

I love this car otherwise; it's by far the best one I've ever had. But I don't understand why Kia decided to use a rotary knob to select forward and reverse.


I'm driving a Subaru Solterra right now, and it has the same kind of knob. I find it awkward as well. But I suspect that safety is the reason for using a rotary knob. I think a simple forward/reverse lever is too easy to accidentally hit. It's far harder to accidentally twist the knob while driving.

Of course, a forward/reverse lever could be done with a button to push to unlock it, just like automatic transmissions had for decades. That would be ideal for me.


The 'simple' solution you propose is the opposite of what almost all cars with electronic shifters actually do, and no better really than the rotary control.


The gear selector in some BMW is a switch - moving it forward puts the car in reverse and moving it backward puts the car in forward gear.


The paddle system you describe is the exact one that killed Anton Yelchin and forced Jeep to do a massive recall.


No, that Jeep issue was from the paddle returning to a neutral position and not giving good feedback. I think what's described here would have the paddle maintain the physical position.

https://youtu.be/AC6Uldx1mi8


In fact, Kia's rotary knob works more like the first one in that video (before the recall). It is spring-loaded in both directions and returns to the center position after you twist it.

The knob itself gives no indication of which direction you've set it to; only the R/N/D lights in front of the knob show that.


I disagree a little with their point on avoiding error codes, just messages; codes can be used for an easy reference with a customer support department, and easy reference for tech support as well.

But yes, show the friendly, descriptive error message in large, bold letters, and let the user know which code to rephrase if they need to call support.


Sadly we frequently only see the error codes and a pointless message. I have a local streaming app on my AppleTV. When, not if, it crashes you get "Error, code: 12345X, use this code if you contact customer support."

Customer support may have a spreadsheet where they can lookup the code, but as a user, that's pretty pointless. It would be better for the customer to get the error "Something in the application crashed, please restart" or "Something bad happened at our end, there's nothing you can do, we have been automatically notified."


The context is about giving a user advice on how to overcome an issue. To an end user:

Merely displaying "Error code 429" is terrible, of course.

"Contact the help desk like this and let them know the error code is 429" is better. Norman doesn't seem to be against this if there is nothing the user can do to handle the error on their own.

If error code 429 is something the user can fix (maybe they need to wait 3 minutes before trying again), then just letting them know that is best.



Another interesting parallel is the Calm Technology manifesto: https://calmtech.com.


Interesting. I can't help but think of Git as a benchmark for these criteria:

In my mind, Git is very guilty of 1-5, and any CLI would struggle with 6 (save for discoverability), but excels in 7-10.

As such, good criteria: I think they criticise Git the right way.


I think Git is a fine anti-benchmark.

#1 it does fine on

#2 fails because it uses jargon that's internal Git state, staging, index, etc.

#3 mostly does ok but doesn't provide useful undos for stuff like shallow copying

#4 `git checkout` exists. It fails this.

#5 doesn't do good error prevention

#6 https://imgs.xkcd.com/comics/git_2x.png exists for a reason.

#7 Git is great at this.

#8 No. It's CLI is huge and byzantine.

#9 Git has gotten better at this, but it's not good at it.

#10 There is a lot of help, docs and tutorial on the web, and with Git.

So in my book Git is like 3-5, that's a failure.

If you want a great CLI tool, Cargo is a stellar example. Git is a failure.


> #1 it does fine on

By default, I'd say no. But with a few config settings and one or to aliases it is excellent.

> #2 fails because it uses jargon that's internal Git state, staging, index, etc.

Yes, it uses it's on jargon. But before Git there were no generally known terms for those concepts. And Git's concept do exist in the real world, previous vc systems simply tried to abstract them away and failed miserably at that.

> #3 mostly does ok but doesn't provide useful undos for stuff like shallow copying

The reflog is a very comprehensive undo mechanism, but it is hard to discover and certainly not as easy to use an undo button. Considering the target demographics of Git, I'd say it is acceptable.

> #4

This has and still is Git's weakest point.

> #8 No. It's CLI is huge and byzantine.

The default porcelain (Git's CLI) is inconsistent and very large, yes. But the underlying model is very elegant. To an expert user, this should matter more than consistent wording in the CLI and documentation. Although, I would still like to have that consistent wording. And because of the qualities of the underlying model it is possible to improve on the porcelain. Which has been happening for quite some time.


> By default, I'd say no.

What I mean is that `git status` is showing you generally what's staged, what mode it's in and so on.

> Yes, it uses it's on [sic] jargon. But before Git there were no generally known terms for those concepts.

Mercurial exists, and it's much lighter on the jargon and concepts needed to know. I'm fine if they are optional learnable stuff, like merge vs rebase. But without knowing index and staging, you're essentially confused why some commands work and some don't.

> The reflog is a very comprehensive undo mechanism

True, and I didn't say anything about it, but setting up some stuff as undoable (commits, rebase, merge) and some stuff as non-undoable (making repo shallow) is honestly indefensible.

> The default porcelain (Git's CLI) is inconsistent and very large, yes. But the underlying model is very elegant.

The Usability as I understand it is about the Interface (where Human and System meet). Whether it's CLI, GUI or physical.


I’d say it’s bad at 4, 6, 8, 9 and 10.

The criteria seem pretty subjective to me.


You use your body to interact and measure the success by how comfortable and pleasurable it is. No criteria / generalizations in such domains could be non-subjective.


Interesting to contrast this with https://www.cs.umd.edu/~ben/goldenrules.html which is currently on Hacker News front page.


Seems to be strong agreement between both.


Interesting list- a lot of great points.

Two minor pedantic observations: (0) I think adding lots of divergent colors should only be done to serve a purpose. In this case, imo the color palette used does not complement the numbering and appears to be used solely to distinguish different heuristics- for which there is no real need.

(1) Also (and this is even more minor), going down from #1 to #2 trains the reader to keep going down but #3 is to the right of #2 making it needlessly disorienting.


Web version is better for reading: https://www.nngroup.com/articles/ten-usability-heuristics/. PDF version is good for put up on your cube wall.


The following related article was published on HN 6 days ago: https://news.ycombinator.com/item?id=38858185




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

Search: