I define “complexity” in a practical way. Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system…. If a software system is hard to understand and modify, then it it is complicated; if it is easy to understand and modify, then it is simple….
Complexity is determined by the activities that are most common. If a system has a few parts that are very complicated, but those parts almost never need to be touched, then they don’t have much impact on the overall complexity of the system….
Complexity is more apparent to readers than writers. If you write a piece of code and it seems simple to you, but other people think it is complex, then it is complex. [emphasis in original]
— A Philosophy of Software Design by John Ousterhout (Page 5 - 6)
Ousterhout is talking about the code itself, so he says “readers” and “writers,” but in this excerpt we might also usefully substitute “users” and “developers” respectively.
As a user of a system, I often—indeed, usually—don’t care how complicated a thing is in its internals, or what language it’s written in, or what the social nature of its open source community looks like. What I mostly care about is interface design: how do I interact with this thing, whatever it is? Occasionally in the past I’ve seen snarky and dismissive comments about people who fixate on and complain about the latest graphical design changes in Windows or macOS, and—while Microsoft and Apple can, and frequently do, get it wrong—at least those complainers are arguing about the right thing: ultimately, a computer is of no use if it’s not used, if it can’t be used.