I'm admittedly a hammer seeing everything as a nail, but as a designer, I see so many opportunities in FOSS lost to basic, unnecessary branding and usability oversights. Developers shouldn't expect themselves to be able to do good design work any more than designers should expect themselves to be able to make scalable, reliable, maintainable, production-ready code. It's a specialty for a reason! Incorporating designers into FOSS projects from the beginning seems like a no-brainer, but design is nearly universally considered a superficial matter to be considered once the real work of back-end development is done (which is generally never.) It's one of the reason that open source alternatives will remain the alternatives rather than the standards. Good design takes a lot of up-front work, and once you get ignored or bikeshedded into oblivion with one design proposal, the liklihood of doing it again is pretty much zero. Definitely my white whale, but it kills me to see so many great projects that could have so much more impact if they enfranchised specialists to design the look and feel.
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.
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.
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?
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.
How would you treat the same problem if it was security, or some really deep performance-critical vendor-specific database design issue or any other problem that wasn't practical to learn yourself before acting? Design is absolutely no more full of snake oil salesmen than web development, for example, you just intuitively know how to spot shitty cargo cult WordPress 'developers' and not shitty designers.
Look up examples of design proposals for user interfaces. Unless it's critically important, aesthetics won't even be part of the equation at first... Core User Interface design is no more related to decoration than development is. Most UI design proposals deliberately use low fidelity block-outs and wireframes to avoid getting sucked into a useless cul-de-sac about Joe hating Green and Jane hating helvetica.
The process of interface design should involve users directly, have sound reasoning you can interrogate, and work directly towards solving problems. There should be defined user paths or user stories or storyboards that address the problems your users solve with your software, and the easiest, most efficient, must intuitive way for them to do it. Every element should have a reason for being where it is and working like it does for the users who need it to work like that. If it involves a change, that needs to be justifiable.
Have them slap together a quick prototype, even if it's a series of still frames. If you see something that works less efficiently than it did previously, well that user story needs to be amended or a new one created. It's it intuitive? Post it publicly and ask for comment being aware that some will just oppose any change and squash bikeshedding by reminding people of the scope of the proposal. There will likely be multiple rounds of revisions. A core tenet of UI design is acknowledging that pulling a big chunk of design out of your ass without consulting users is an insta fail.
Taste comes into play more with branding and identity, though fundamentally you're still solving problems with interrogatable reasoning... They're just communicating to who should be interested in your software and how they should feel about using it. This is a different design discipline, and while some interface designers have experience in both, don't assume it.
Definitely don't assume someone with a pretty design portfolio can design your interface... Their portfolio should include studies of ways they made software interfaces more effectively solve their users problems.
I definitely agree with these two major pain points. It relates to some of my personal experience as well, you would have to effectively solo an entire design markup just to potentially get key FOSS members on board with design changes.
You have the same problem when trying to show an early mockup to a paying client, they keep picking at things that aren't going to be that way in the final, so you wind up rarely involving them until you have a really solid draft ready. It's a tradeoff you actively make because you're getting paid to make those micro-decisions for them.
It's unfortunate because I feel FOSS could work wonderfully with design, so much of what makes design great also makes FOSS amazing, but the bridge just isn't there.
Yeah... the big difference with paying clients is that they know there's a need, and they know they can't do it themselves (even if they incorrectly think they know enough to judge why.) Working with FOSS is essentially cold-calling clients having done a design proposal upfront.
Speaking as someone who was mainly a "developer" for a while, one frequent problem I see from developers is that they assume they can excel at everything because they are good at coding. Since coding is a hard task that not everyone can do well, they think this talent applies to everything else.
Just a few weeks ago on here, there was a developer complaining about not getting any attention through his efforts on social media, and from what he said he did, it was easy to tell he did not know what he was doing and severely lacked the sophistication needed to succeed. Instead of paying for marketing, he decided to do it himself and was about to give up without even thinking about paying someone else to do it.
This is hubris that is commonly seen in developers.
Solid example, thanks. Worth specifically noting that we shouldn't be quick to judge, though. Every one of us has succumbed to novice cockiness at some point in our lives. People who build things, like developers, gain novice-level knowledge of everything from interface creation to domain-specific knowledge to copy writing to photo editing by osmosis. I'd be lying if I said I was any different.
My hours of dev contributions to FOSS projects over the decades are somewhere in the low 5 figure range. Despite having a formal art school design education, I never contribute as a designer because FOSS projects are usually openly hostile to design input, even by someone like me who can implement it themselves.
> Rude. People can learn to do multiple things without being pigeonholed, you know?
Pigeonholing by not expecting specialists to be competent outside of their specialty? I have considerable professional experience as both a designer and a developer in the past decade-and-a-half, and a couple of other completely unrelated careers in the decade before prior. You're fishing for things to be offended by, and probably misjudging the amount of design understanding required for actual competence.
Having worked as a professional software developer in a reputable development organization for over a decade with steady advancement before I decided to go to school for design is a good enough indicator for me. Being asked to speak at a couple of conferences about my dev work is another good sign I guess.
Suggesting that being a software developer doesn't also qualify you to be a designer seems to have really bothered you for some reason. I don't think saying so is any more controversial than saying automotive engineers aren't automatically car interior designers or that being a civil engineer doesn't automatically make you an architect. If you feel like you're a great designer, fantastic. Enjoy your broad skillset, as I enjoy mine. If you feel like my comment somehow challenged that, weird but sorry?
No, it's just amusing how hypocritical you are. You can be a designer and a developer, but nobody else can?
You:
> Developers shouldn't expect themselves to be able to do good design work
Also you:
> Having worked as a professional software developer in a reputable development organization for over a decade with steady advancement before I decided to go to school for design is a good enough indicator for me.
> Developers shouldn't expect themselves to be able to do good design work any more than designers should expect themselves to be able to make scalable, reliable, maintainable, production-ready code.
Reread that sentence. It does not say developers can't do good design work and it doesn't say that designers can't write good code: it says they shouldn't expect to simply be able to do it. Nobody should expect to be able to do anything non-trivial they haven't deliberately learned how to do. Unless you have evidence that most developers have done the years of learning it takes to become a competent interface designer, that's just not a controversial statement.
If you're going to continue trawl my comment for minutia to be aggrieved by instead of making any coherent counterargument, you're on your own.
