The problem is that learning how to do things is really expensive for many people. I think the fundamental problem isn't user-centered design but lopsided bifur

The problem is that learning how to do things is really expensive for many people. I think the fundamental problem isn't user-centered design but lopsided bifurcation in who the users are. For a product like a recipe/grocery app, I genuinely don't care about abstraction layers it uses below its UI. I just want my wife and I to plan our meals and do our grocery shopping in a time-efficient way. I don't want to run into situations where "it doesn't work" and I have to figure out why. For a product like gulp.js, vim, or google chrome's layout engine, I really do care about those abstraction because I am trying to build things with them and I expect that I'll run into situations where "it doesn't work" and I have to figure out why. So give me the conceptual tools to do so. If that means source-diving without clear documentation about how to do that spelunking, fine. I'll procrastinate on it and be unhappy, but I'll do it. So starting from that perspective, any improvement on the fixing-things experience is a blessing rather than an irrelevance. But some things necessarily straddle both. It would be very difficult to fund a hardware manufacturing supply chain for a phone without mass-market appeal. Yet the app ecosystem that produces much of the value of a smartphone requires some ability to do things the phone manufacturer did not anticipate, even if it within a playpen.