It’s even worse, I think. Good UX design looks deceptively easy, but is actually incredibly hard. So hard that a lot of programmers don’t even recognize how terrible they are at it, or how high the skill ceiling actually is. They think UI design is pretty colors and rounded buttons.
In a functioning software company, the managers recognize this skill difference and simply order the developers to implement what the designers suggest. They grumpily do. (It’s obviously not always so stereotypical. I’m exaggerating to make a point.)
In a typical OSS project, no one can give orders. The programmers ignore any good design suggestions because they don’t recognize those, and implement their own crappy ideas instead. Sometimes while arrogantly dunking on the designer who tried to make a contribution. Consequently, UX quality is abysmal, and anyone who could fix that is driven away. I don’t see a solution to this.
I think part of the problem is also that it's sometimes more difficult to implement a nice and usable design. Instead, it may be easier to write code that does everything it needs to, but forces the user to jump through hoops to get what they want.
Sometimes making software more user-friendly may even cause the code to get more "ugly", because instead of a nice and elegant piece of software that only solves the core problem, you now have to deal with all the weirdnesses of how people perceive the problem as well. Taking away complexity on the user's side almost always adds complexity to the code. And if you're the developer, it's very easy to think that the tool you created is perfectly usable, because you understand everything about the mental model that went into it.
As a product design lead, your comment and the comment you’re replying to reflect my experiences both with open source and with commercial development. For me, part of the solution has been learning how to communicate with developers. I’ve also found it helpful to broaden the scope of UX I consider to include the developer experience, data processing workflows, and the design of CLI and API interfaces.
>In a typical OSS project, no one can give orders. The programmers ignore any good design suggestions because they don’t recognize those, and implement their own crappy ideas instead. Sometimes while arrogantly dunking on the designer who tried to make a contribution. Consequently, UX quality is abysmal, and anyone who could fix that is driven away. I don’t see a solution to this.
Generally, going into an open source project as a stranger and suggesting to make architectural changes without expectation of pushback is not a good idea. Any change there is going to trample on someone else's workflow. You have to build up trust first before people see you as an authority, that is the solution and it's often the only one. It's worked for some projects such as the recent post about Audacity, even though it's a bit of an extreme example because the person was already established as a well-known designer: https://news.ycombinator.com/item?id=26995610
I don't blame the programmer for dismissing suggestions they don't understand but it's also not cool if you were "dunked on" so I'm sorry if that was your experience. Keep in mind that's still better than some, a lot of projects will just ignore suggestions completely if they figure you're just not part of their target audience, and they don't have the budget to expand that audience.
No need to be sorry, I'm not the designer in this story -- I'm the grumpy sofware engineer, and nowadays sometimes the manager. I'm also a desktop Linux user who is regularly annoyed by the sad and confusing state of opensource UX. What makes me so pessimistic is that I know the social dynamics that typically cause this, and have seen them play out in lots and lots of mailing list discussions.
Of course that's not a logical inevitability, things can change with more understanding. Your link actually makes me very happy, I hadn't seen this. Let's hope that this works out, and becomes a model that more OSS project can follow.
Programming a complex system can be achieved from the bottom up: Volunteers keep adding and sharing stuff. Old stuff becomes obsolete. The system marches on.
UI design in contrast is a top-down effort. You can't just mix and match various works from people. It's about information flow and consistency. A unified interface has to be agreed upon, and then implemented across the board. And any part of the system that fails to meet that standard, essentially breaks the UI.
In a functioning software company, the managers recognize this skill difference and simply order the developers to implement what the designers suggest. They grumpily do. (It’s obviously not always so stereotypical. I’m exaggerating to make a point.)
In a typical OSS project, no one can give orders. The programmers ignore any good design suggestions because they don’t recognize those, and implement their own crappy ideas instead. Sometimes while arrogantly dunking on the designer who tried to make a contribution. Consequently, UX quality is abysmal, and anyone who could fix that is driven away. I don’t see a solution to this.