> a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.

This is completely lost on most developers, which is why interface and UX designers exist. Developers, especially in FOSS projects, often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software. They’re smart enough— they just don’t want to have to learn about technical implementation details for the same reason most developers are perfectly content to use personal bookkeeping apps instead of learning the best ways to organize that data and making the spreadsheets manually. Most non-technologists get no dopamine hit from solving technical problems, have no need for the requisite knowledge needed to confidently do that, and are often just trying to make the computer do what it must so they can get back to doing what they’re actually passionate and knowledgeable about. When a competing product has an interface built for people without that mental model, it would have to be pretty fucking expensive to not be a no-brainier for most nontechnical users.

> They’re smart enough

I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.

I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's impossible to do any amount of front-line support without collecting some horror stories.

One of my favorites is spending nearly 10 minutes trying to get someone to read a single word on their screen correctly, in a dialog box that was blocking them, containing fewer than 10 words, so I could find the cause of their problem. After nearly 30 minutes to figure out that they had a popup blocking them, and not "the computer doesn't work".

What eventually worked was getting them to spell it to me backwards. That strategy has worked out quite well in other cases too - I suspect because it avoids some of people's built-in autocorrect and dyslexia (autoincorrect).

(I honestly mostly enjoy tech support, and I've done it for many years, sometimes professionally. But some people do seem like lost causes, and are not just having a bad day)

I have experienced this in person with a developer who was failing to debug something. An error message was popping up on screen and he was reflexively clicking it away faster than anybody could read it. Even after being told “an error message is popping up, don’t dismiss it”, even after being told “[do the thing that triggers the bug] and then completely stop without doing anything else”, and a whole bunch of other ways of phrasing it, he was unable to understand that the error message contained useful information that we needed to see. I’m not even sure he was consciously aware it existed or that he was doing it. After many failed attempts at getting him to stop I literally had to take the mouse away from him and do it myself. I was shocked that apparently nothing anybody could say would stop him from dismissing the error message without even looking at it.

That's even worse than the "I'm getting an error when I ..." type! ("...ok... What's the error?")

The flip side of this is the pleasant surprise of working with a near-retirement age grandma who assures you that she "isn't technical" and "doesn't know how to use a computer", but will studiously write down every keyboard shortcut on little post-it notes and add it to their collection like they're porcelain cats she found at the Sunday markets. I've watched some of these people operate a computer in a manner reminiscent of watching an F1 driver at work, the screen just a blur as their fingers dance over the keyboard.

This sounds like "Smart person who has little technical experience and might have cognitive decline from age". The world is fully of people who's intelligence is legitimately lower than you might expect.

> The world is fully of people who's intelligence

What an example of a sentence a person *whose intelligence is lower than you might expect would write. I can only imagine this was intentional.

Could you clarify? Are you using the typo as this basis, or something else?

Absolutely, the ones that are clearly trying more than make up for the rest imo, and some are stunning. There are a lot of them. And many of the rest are just having a bad brain day and need help rubber-ducking to see the thing right in front of them - we've all been there, many times.

There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.

I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here.

Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.

This makes for better experiences, as reality gets bound by.. well.. reality. So you don't get these weird failure modes that live in the gap between the narrative (e.g. "everything just works") and reality (e.g. "networks are always black magic").

This is also important for the user, because by having _a_ mental model (even if it is very low-res), they gain the ability to diagnose issues themselves and not be completely helpless once the magic box breaks down. They might not know exactly what to do, but the direction is very clear.

Agency is important. A lot more important than convenience. And fake convenience through frontloading short-term rewards for long-term systemic instability.

That's one of the things that surprised me (in a positive way) about Mac OS X when I first got to use it -- it actually does indeed do lots of things in an _understandable_ and genuinely simple way. It's also clear how much work went into making the system behave in this way, it certainly wasn't an accident.

In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.

> Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.

This is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc

Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.

Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives. Still, they get it. Some icons outlive their era, some don’t.

> In the 90s everybody knew how a paper book worked

I hope that’s still the case!

Nobody reads the docs. This will be even more true soon as LLM generated docs become more popular. I once read a user report "would be nice if I could move large Xs to uncover Y", filed a bug report myself to add the feature, and then realized that feature was already added and documented months ago, by me! I just updated it with an unobtrusive prompt/instruction to the UI when relevant. I definitely get lazy sometimes, but if you don't take the extra step to make sure a feature is easily discoverable and understandable in the UI, you're wasting almost all of its potential benefit.

I love the UX-design book: Don't Make Me Think.

Steve Krug's other book, Rocket Surgery Made Easy, got me into usability tests with real users, and how to get it in place in a corporate environment. It's shocking to watch real users use software.