Seems like a great product, but something about the URL is reminiscent of those scammy websites that try to trick you into downloading scamware.
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.
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.
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?
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.
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.
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.
Rude. People can learn to do multiple things without being pigeonholed, you know?
> I see so many opportunities in FOSS lost to basic, unnecessary branding and usability oversights.
It's FOSS. Feel free to contribute.
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.
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.
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?
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.
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.