[cjs_ac]

Users are complete human beings, and their interaction with your product is a tiny slice of their life. They use your product to solve problems that they have. If the 80% of your product that they aren't using doesn't relate to their problems, they won't use it, even if they know that it exists. For example, I've never used Microsoft Word's mail merge function, even though I've known it exists for probably twenty years, simply because I've never needed to send out a form letter to a whole bunch of people.

Sometimes, there is indeed a new feature that could solve a problem that they have, but they don't know it exists. I've seen a lot of pop-ups in software that try to tell me about new features, but I never read them, because I'm always trying to do something else when they appear. Emailed newsletters also don't work, because the marketing people who design them always make them look like advertisements.

Finally, many computer users are deeply incurious about their computers, and are often too scared of breaking something to try an unfamiliar feature.

[XorNot]

But the thing is, being scared of something breaking is something we as software engineers have pushed onto users.

You click a control and something happens - you don't like it, but you don't know what turns it off or undoes it. There's no global state rollback. It's like the sheer terror those "don't show me this again" buttons instill - the concept is frightening even if I'm kind of annoyed by the message, and they rarely if ever include an explanation of exactly where to do to turn the control back on.

[bux93]

And this is only becoming worse in recent years. "Contact your administrator", "We are working on updates.." - I recently spent 10 minutes trying to find the actual location a powerpoint was saved to since every iteration of 'open location'/'open in sharepoint'/'copy link' just resulted in URLs with GUIDs or opening the document again rather than an actual path.

[thewebguyd]

That fear is very real, and I've noticed it on my team at work. Our (internal) help desk ticket work load has increased quite a bit over the past ~5 years or so, even though our user base hasn't changed much.

People are even afraid to do basic troubleshooting out of fear of breaking something and not being able to easily rollback to the point that something as simple changing the sleep settings on a computer results in a help desk ticket.

[energy123]

> their interaction with your product is a tiny slice of their life

Low cognitive load should be a major goal, and that doesn't mean the app can't be feature rich. Make the app very fast, or at least hide latency from the user. No esoteric icons, instead default to plain text. If you have icons, no artificial delay between mouse-over and tooltip. No smooth scrolling. No excessive whitespace. No elements that move around while the page loads. No scrolljacking. And actually use your app so a random user like me can't find multiple bugs in it.

Chatgpt website is a good example of how to tick some of these boxes to achieve low cognitive load, despite being feature rich. It's very fast, and mousing over an icon displays the tooltip immediately. Although they have a few UI bugs that they need to fix, I would give them an 8.5/10. Gemini website is an example of how to tax cognitive load despite being feature poor and "simple". It's very slow for large contexts, it scrolljacks, and it has numerous bugs. I would give them a 2/10, partly due to the fact that it hasn't noticeably improved for over a year since I started using it, despite being one of their flagship products.

[nradov]

Low cognitive load is not a good design goal for most software. I mean it's fine for something simple that sees only occasional, casual use. But for applications that enterprise employees use for hours every day the design must be optimized to maximize productivity over a wide range of use cases. The decision makers don't care about cognitive load.