Comment by chefandy

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.