Sounds like a great way to view the people you build products for.
Sounds like a great way to view the people you build products for.
This same refrain--common whenever we bring up, say, gamers being bad customers--is getting as threadbare as the "privleged" stuff.
At the end of the day, our products serve to redress some shortcoming in our customer's toolbox. They don't want that shortcoming, or whatever problem that it represents, and our products are at their best subtle reminders of some lapse in happiness our customers have.
We don't have to assume anything about our customers beyond what is needed to deliver product. We might assume that they're nice, that they always give to charity, that they deeply and truly care about the lines of code we write to fix their inconvenience, and any number of other things.
Fact is, most customers do not a shit give. Most customers want the cheapest thing that makes their problem go away and does so as unobtrusively as possible. Most customers don't understand or care to understand the causes underlying their current pain point, and most customers even with that knowledge wouldn't change because reasons.
And you know what? That's fine. Hell, that's human. It's our job as craftspeople to make the best products we can, because that's what makers do. We don't need these outlandish assumptions about our target audience in order to kick ass and ship code.
~
Now, as far as the article is concerned, the tone of that is very much directed towards a young engineer who views (rightly or wrongly) customer complaints as absurd or moronic. And honestly? Most UI/UX things are clumsy wrappers over something that a line of commands would very easily solve, were we to provide our users with a CLI. Our drive is more and more to "don't make me think" about our interfaces, and honestly that is very much in support of customer-as-simpleton.
Part of the process of learning business is to realize that, while it is true that customers are lazy (don't want to spend effort solving their problem) and simpletons (don't want to think about what little effort they do expend), that is something that can be made a design constraint and used to make something that people will buy.
To a young engineer, yeah, people are simpletons when faced with their problem domain, but they need to learn to ship code for those folks anyway.