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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.