[HN Gopher] Nielsen's Ten Usability Heuristics [pdf] (2020)
___________________________________________________________________
Nielsen's Ten Usability Heuristics [pdf] (2020)
Author : andsoitis
Score : 87 points
Date : 2024-01-09 15:15 UTC (7 hours ago)
(HTM) web link (media.nngroup.com)
(TXT) w3m dump (media.nngroup.com)
| xnx wrote:
| Web version: https://www.nngroup.com/articles/ten-usability-
| heuristics/
| roteakin wrote:
| 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.
| mrweasel wrote:
| 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."
| dfxm12 wrote:
| 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.
| lcuff wrote:
| Interesting to contrast this with
| https://www.cs.umd.edu/~ben/goldenrules.html which is currently
| on Hacker News front page.
| dredmorbius wrote:
| Seems to be strong agreement between both.
| awei wrote:
| Another interesting parallel is the Calm Technology manifesto:
| https://calmtech.com.
| dfxm12 wrote:
| 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.
| ChrisMarshallNY wrote:
| _> 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.
| zer00eyz wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| diegof79 wrote:
| > 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.
| ChrisMarshallNY wrote:
| 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.
| diegof79 wrote:
| 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.
| ChrisMarshallNY wrote:
| I really appreciate your answers!
|
| I feel like the tech world could use many more
| discussions, like this.
|
| Thanks!
| felixgallo wrote:
| > 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.
| diegof79 wrote:
| 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.
| JohnFen wrote:
| > 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.
| zer00eyz wrote:
| 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.
| _a_a_a_ wrote:
| 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.
| TylerE wrote:
| Where people go wrong is by letting management dictate
| design.
| laserlight wrote:
| > 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.
| mateo411 wrote:
| 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.
| dfxm12 wrote:
| 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.
| anordal wrote:
| 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.
| hedora wrote:
| I'd say it's bad at 4, 6, 8, 9 and 10.
|
| The criteria seem pretty subjective to me.
| ulbu wrote:
| 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.
| Ygg2 wrote:
| 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.
| eyeundersand wrote:
| 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.
| xnx wrote:
| 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.
| Stratoscope wrote:
| 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.
| webnrrd2k wrote:
| 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.
| TylerE wrote:
| The paddle system you describe is the exact one that killed
| Anton Yelchin and forced Jeep to do a massive recall.
| whycome wrote:
| 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
| Stratoscope wrote:
| 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.
| jen20 wrote:
| 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.
| awei wrote:
| The following related article was published on HN 6 days ago:
| https://news.ycombinator.com/item?id=38858185
___________________________________________________________________
(page generated 2024-01-09 23:02 UTC)