It seems reasonable to conclude that system designers have the opportunity to be a user and as such to figure out what the user will need. I think what the designers often do is consult with groups of people who are in positions similar to the typical user.
But again, it shouldn’t be hard for the designers to figure out the needs of the user by sitting there and working the keyboard a little. And I mean they should figure out most if not all such needs.
Another way to think of this is the quality of the product is fully the responsibility of the people making the product. It’s how the system has functioned for many centuries. Until digital technology came along. Maybe it has to do with the culture of people who become coders. I was friends with one guy who invented a product for Microsoft. Of course, he’s a brilliant guy. But he was the typical spoiled kid, a teenage hacker with intense focus who later met the right people. Many such individuals bring an attitude of entitlement to the game. I think this could have cultivated an industry-wide philosophy of “let’s milk the user.”
I don’t blame you for thinking the user needs to help design the system. I assume you’re touting the established beliefs in the industry.
What I would advise system designers is twofold:
1. focus on the distinction between the practical function and aesthetic function in product features, and try not to conflate the two
2. seek to produce order rather than chaos, recalling that the definition of order in physics is when a given event or phenomenon can only be achieved in one way (for example, don’t have two tabs on the same web page that do the same thing)
The marketing people are higher up the corporate food chain than developers, so good products are terminated prematurely, new designs are made that satisfy the marketing department more than anyone else, and then a development schedule is fixed that is always too short to develop for quality.
There are two major kinds of development projects. The first is the development of software products like "office suits" and "games". These experience no end-user involvement, and are conducted mostly to an overly tight time schedule. Marketing people don't seem to care about the end user. The strategy is to obsolete the previous versions and force customers to repurchase. The biggest of those, and the worst behaved, is Microsoft. (Remember "the ribbon" forced against the will of ALL users? I still use Word 2003 because of that unwelcome improvement.) How about those forced changes through the years, now the forced adoption of Win 11? This isn't about quality, this is about money.
The other type of development is software that is made under contract to solve a particular set of problems. This includes hospital management systems, power plant operating software, aircraft avionics, and so on. Projects in this category is where you find the systems designers, once known as "systems analysts". Those people are trained to interview the user community to discover the data flow and data needs of the organization. Once these analysts are through with their discovery phase, the user organization has an understanding of their own workplace as never before. The design phase is supposed to include "buy in" from everyone who was interviewed during discovery. Once designs are approved actual software development commences. Software development should remain as flexible as possible in order to accommodate late breaking understandings.
Systems analysis and software engineering definitely have process and quality rules. Teams composed of younger people often violate those rules. Schedule pressure imposed from outside of the development team cause a great deal of damage to system quality. It is almost impossible to control that, given the management hierarchy and the non-technical nature of marketing and upper management dweebs.