5 ms·

One of the great difficulty of tackling that problem is often FOSS projects are averse to design decisions like that made by someone relatively fresh to the pro

One of the great difficulty of tackling that problem is often FOSS projects are averse to design decisions like that made by someone relatively fresh to the project - even if the problem is incredibly obvious to the designers and not the core development team. You would have to spend a lot of time gaining trust to then be able to present an idea like switching domains. The duality of putting off design decisions until later, and also feeling like your current design is extremely personal (I've seen some projects where the maintainer immediately disregards a lot of proposals design wise because it's "good enough", as if that person just called their baby ugly), can make trying to make any progress on FOSS project feel horrible. It's a very interesting problem space I feel. There's so much room for improvement.

DrewADesign 4y ago
As a professional designer who's spent more time in my life developing FOSS than designing, I generally see FOSS projects refusing to accept design input, period. I've thought a lot about why and I see two broad problems: First, developers have a different fundamental perspective on interfaces than most people. They view interfaces as a wrapper that you use to interact with the important part: the application. To regular users, the interface is the application. I can't tell you how many times I've seen things like customizable color themes or ill-conceived typeface changes be the primary product of a developer-initiated "UX review," largely because they didn't know how to identify actual usability problems and wouldn't know how to craft solutions even if they did. If it persists long enough, maintainers don't just see their interfaces and user paths as flawed but good enough: they assume the mitigation techniques they've developed to work around a bad interface are best practices. Second, art school freshmen subconsciously trying to prove their competence to themselves give the harshest and least useful critique and often take constructive critique as a personal affront. That phenomenon seems generalizable: critique about things we're less confident in makes us feel more insecure than critique of things we're more confident in. If someone proposed replacing a core piece of the architecture with something different, they'd be confident enough to look at it and rationally decide if it's beneficial. Conversely, when developers see redesign proposals about interfaces they were never confident in to begin with, they get defensive, and design proposals get dismissed or bikeshedded to complete buggery. I think these two things imbue the FOSS development world with indifference to, or even distrust of designers. You only need to briefly look at threads on HN focused on design or interface to see the open disdain many developers have for designers. "Ruined by designers" is a pretty common refrain. Despite our unicorn reputations, I know lots of designers/developers, and every one that I can recall at the moment contribute to FOSS... just never as designers because the process is so irritating. Myself included. It's just not worth the amount of work that goes into a competent design proposal, noting that I would implement it personally, only to have it summarily dismissed by people with false confidence in their analysis.
- hyperman1 4y ago
  Let me respond as a developer with admittedly no taste at all, who both committed and fixed plenty of atrocities: Just like security, design is one of these things where snake oil salesmen are everywhere, to the point that finding a good one without becoming a designer yourself is hard. I also notice you identify as an artist, not a psychologist, which seems the wrong approach to me. So what will happen if I let designers loose on my program? They might have real insight and improve things a lot. Or maybe they'll go all artsy and put lipstick on the pig, leaving me with an even worse program in lovely pastels? Or maybe they'll dumb down an interface in an attempt to create a granny-safe rocket launch pad, leaving the actual rocket engineers frustrated? Or they'll just move stuff around for the sake of moving stuff around, creating a lot of busywork and forcing user retraining without any upside. I've seen all these things happen. So what is your advise to this dev? How do I get designers that actually improve the design?
  - waboremo 4y ago
    Standardize communication, if the team talks on discord, have a channel for design. If there are github issue labels for feature requests, have labels for various design requests. Things like this go a long way! Contrast how people feel about translation changes vs design changes. Most people don't even know if the translation is valid! They accept it however easier than design changes purely because there is so much more standardization with translation changes. Create spaces where design talks can happen without people feeling like they're stepping over others toes. Create a design document that new members can reference, copy, and base changes from. Figma is a great tool for this, but even if you don't have a design in place, even an open github issue or notion page stating the pulse of the project is great. What is the brand, why are the colors the way they are, who is the main user of the project, what are current discomforts about the design? It's hard to propose design changes (beyond micro issues) when designers have absolutely no idea what was actively chosen and what was a throwaway idea. This design document isn't just for designers! Developers also need it, especially front end developers who would need to know important things like hey we do not have access to images beyond 50x50 from the API. I feel as though these two can go a very very long way with designers. They aren't silver bullets by any means, especially not designers who aren't developers at all, but it can go a long way to encourage larger creative solutions. Oh and A/B testing! You don't have to have a grand official A/B system (although there are quite nice systems these days), even releasing a change but explicitly asking users for their feedback on it can go a very long way in improving trust on the team and moving design decisions away from "personal taste" and onto "this change caused a 30% drop in purchases" objectivity.

DrewADesign 4y ago

As a professional designer who's spent more time in my life developing FOSS than designing, I generally see FOSS projects refusing to accept design input, period. I've thought a lot about why and I see two broad problems: First, developers have a different fundamental perspective on interfaces than most people. They view interfaces as a wrapper that you use to interact with the important part: the application. To regular users, the interface is the application. I can't tell you how many times I've seen things like customizable color themes or ill-conceived typeface changes be the primary product of a developer-initiated "UX review," largely because they didn't know how to identify actual usability problems and wouldn't know how to craft solutions even if they did. If it persists long enough, maintainers don't just see their interfaces and user paths as flawed but good enough: they assume the mitigation techniques they've developed to work around a bad interface are best practices. Second, art school freshmen subconsciously trying to prove their competence to themselves give the harshest and least useful critique and often take constructive critique as a personal affront. That phenomenon seems generalizable: critique about things we're less confident in makes us feel more insecure than critique of things we're more confident in. If someone proposed replacing a core piece of the architecture with something different, they'd be confident enough to look at it and rationally decide if it's beneficial. Conversely, when developers see redesign proposals about interfaces they were never confident in to begin with, they get defensive, and design proposals get dismissed or bikeshedded to complete buggery. I think these two things imbue the FOSS development world with indifference to, or even distrust of designers. You only need to briefly look at threads on HN focused on design or interface to see the open disdain many developers have for designers. "Ruined by designers" is a pretty common refrain. Despite our unicorn reputations, I know lots of designers/developers, and every one that I can recall at the moment contribute to FOSS... just never as designers because the process is so irritating. Myself included. It's just not worth the amount of work that goes into a competent design proposal, noting that I would implement it personally, only to have it summarily dismissed by people with false confidence in their analysis.

hyperman1 4y ago
Let me respond as a developer with admittedly no taste at all, who both committed and fixed plenty of atrocities: Just like security, design is one of these things where snake oil salesmen are everywhere, to the point that finding a good one without becoming a designer yourself is hard. I also notice you identify as an artist, not a psychologist, which seems the wrong approach to me. So what will happen if I let designers loose on my program? They might have real insight and improve things a lot. Or maybe they'll go all artsy and put lipstick on the pig, leaving me with an even worse program in lovely pastels? Or maybe they'll dumb down an interface in an attempt to create a granny-safe rocket launch pad, leaving the actual rocket engineers frustrated? Or they'll just move stuff around for the sake of moving stuff around, creating a lot of busywork and forcing user retraining without any upside. I've seen all these things happen. So what is your advise to this dev? How do I get designers that actually improve the design?
- waboremo 4y ago
  Standardize communication, if the team talks on discord, have a channel for design. If there are github issue labels for feature requests, have labels for various design requests. Things like this go a long way! Contrast how people feel about translation changes vs design changes. Most people don't even know if the translation is valid! They accept it however easier than design changes purely because there is so much more standardization with translation changes. Create spaces where design talks can happen without people feeling like they're stepping over others toes. Create a design document that new members can reference, copy, and base changes from. Figma is a great tool for this, but even if you don't have a design in place, even an open github issue or notion page stating the pulse of the project is great. What is the brand, why are the colors the way they are, who is the main user of the project, what are current discomforts about the design? It's hard to propose design changes (beyond micro issues) when designers have absolutely no idea what was actively chosen and what was a throwaway idea. This design document isn't just for designers! Developers also need it, especially front end developers who would need to know important things like hey we do not have access to images beyond 50x50 from the API. I feel as though these two can go a very very long way with designers. They aren't silver bullets by any means, especially not designers who aren't developers at all, but it can go a long way to encourage larger creative solutions. Oh and A/B testing! You don't have to have a grand official A/B system (although there are quite nice systems these days), even releasing a change but explicitly asking users for their feedback on it can go a very long way in improving trust on the team and moving design decisions away from "personal taste" and onto "this change caused a 30% drop in purchases" objectivity.