I just find the entire post reductive and limiting in terms of its view of what software is or should be capable of. It is describing a philosophy applicable f

I just find the entire post reductive and limiting in terms of its view of what software is or should be capable of. It is describing a philosophy applicable for software that has a particular purpose - mostly productivity desktop applications, it seems - which is just a very long way from all software. "I, as a user, should know what I can do with it and what I can’t do. I always know what’s happening, where I am and what is next. Everything comes easily to me. I don’t get stuck, never feel lost or stressed out." This is clearly not a reasonable design goal for a puzzle game. It’s not a good goal for a call center queue management system. It’s not even a reasonable design goal for a search engine! Oh, but you’ll say the author only means within the bounds of the tool’s interface the user should understand what options they have, not be burdened with additional stress of trying to figure out how to interact with it, etc. Which is just.. yes, obviously, you shouldn’t build software to just screw with people (oh, but… puzzle game?). But overall, taking responsibility for a user’s stress/calm and placing the burden on all software to try to “exude calm” into any situation is… it’s an opinion, but it’s not a particularly interesting one?