> In many ways, the whole point of AI applications is that it should feel like magic because something that you previously had to do by hand is now fully automated with believable intelligence. If you’re thinking about taking traditional forms of UX and adding AI to them, that’s an okay starting point but not a defensible moat.

No. Stop! Please! I want my UX in an app to do the damn thing I precisely intend it to do, not what it believes I intend to do - which is increasingly common in UX design - and I hate it. It's a completely opaque black box and when the "magic" doesn't work (which it frequently does not, especially if you fall outside of "normal" range) - the UX is abysmal to the point of hilarity.

That's fine, but there are many tasks (for example, natural-language processing) where there is no classical way to precisely define the steps you want to be performed, and hand-tuning a list of keywords or heuristics is time-consuming and less accurate than reading through the texts yourself. In this case, providing high-level instructions to an LLM to read through the text and attempt to apply the spirit of your instructions is invaluable.

It's been going downhill for a while, even before AI. The VC-funded React SaaS craze took the "put something barely functional on the web, make some subscription cash" model and scaled it to what is essentially a scam/spam industry.

So if the UX feels increasingly framed in terms of what the "developers" see/want/believe to be profitable, and less from the actual user's perspective, that's because the UX was sketched by hustlers who see software development explicitly as a "React grind to increase MRR/ARR."

This is a good summary of the downturn of Google search. It constantly tries to offer you the kind of results it thinks you should want, not what you actually searched for. Thank god for Kagi and other up and coming alternatives.

Similar vein - I can't even type "2 + 2 = 5" on my iPhone anymore because the keyboard keeps suggesting "2 + 2 = 4" as soon as I finish the first part and autofills it when I hit the space. It's extremely frustrating, and I feel like a keyboard is a prime example of a system that should do what I say. If I make a mistake, I'll correct it.

I don't see integrating AI into UI/UX to be incompatible with enabling the user to do as she intends. In fact, I think the thoughtful use of AI could better help users do what they want. It is annoying when "smart" features completely miss the mark, but it's a worthy pursuit in my book.

> I want my UX in an app to do the damn thing I precisely intend it to do, not what it believes I intend to do

This is pretty weird epistemological phrasing. It's a bit like saying "I want to know the truth, not just what I believe to be the truth!"

I think the "the user doesn't really know what they want" idea has been taken a bit too far.

Basically all applications these days are like this. Rather than assume users are sentient, intelligent beings capable of controlling devices and applications in order to achieve some goal, modern app design seems to be driven by a philosophy which views the operators of applications as imbeciles that require constant hand-holding and who must be given as little control and autonomy as possible. The analog world becomes more appealing every day because of this.

Developers expect UI controls to afford fine-grained control over functions as if they’re a thin wrapper for the API. For example, if there’s some condition that prevents something from happening in a program and there are one or two things you can do to mitigate it, most developers would rather know the process failed and be given the choice about how/when to proceed. Our understanding of what controls ‘should’ do based on a sophisticated mental model of software architecture, networking, etc. We don’t have to deliberately reason about what the computer is doing— we just intuit that it’s writing a file, or making a web request, etc etc etc and automatically reason about the appropriate next steps based on what happens during that operation— sort of like writing code. Knowing that the process failed and how gives us valuable information that we can use to troubleshoot the base problem and possibly improve something.

Nontechnical users do not have that mental model: they base their estimation of what a control should do on what problem they believe that control solves. The discrepancy starts with misalignment between the user’s mental model of the problem, and how software solves the problems. In that hypothetical system where some condition is preventing something from happening and there are one or two things you can do to mitigate it, the nontechnical user doesn’t give a fuck if and how something failed if there’s a different possible approach won’t fail. They just want you to solve their problem with the least possible amount of resistance, and don’t have the requisite knowledge to know why the program is telling them, let alone how it relates to the larger problem. That’s why developers often find UIs built for nontechnical users to be frustrating and seem “dumbed down”. For users concerned only with the larger problem and have no understanding of the implementation, giving them a bunch of implementation-specific controls is far dumber than trying to pivot if there’s a stumbling block in the execution and still try to do what needs to be done without user intervention. Moreover, even having that big mess of controls on the screen for more technically-sophisticated users increasing cognitive load and makes it more difficult for nontechnical users to figure out what they need to do.

It’s a frustrating disconnect, but it’s not some big trend to make terrible UIs as developers often assume. Rather, it’s becoming more common because UI and UX designers are increasingly figuring out what the majority of users actually want the software to do, and how to make it easier for them to do it. When developers are left to their own devices with interfaces, the result is frequently something other developers approve of, while nontechnical users find it clunky and counterintuitive. In my experience, that’s why so few nontechnical users adopt independent user-facing FOSS applications instead of their commercial counterparts.