Nielsen's Ten Usability Heuristics [pdf] (2020)
media.nngroup.com
media.nngroup.com
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.
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.
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.
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.
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.
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.
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 feel like the tech world could use many more discussions, like this.
Thanks!
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.
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.
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.
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.
Same here. I started reading it twice, but quit each time, because it was telling the obvious.
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.
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.
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 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.
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.
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."
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.
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.
The criteria seem pretty subjective to me.
#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.
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.
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.
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.