Thanks Daniel, that’s very helpful. What I’m finding (reluctantly) is that the teams with the most mature UX practices tend to be smallish teams that are funded with dedicated PM and UX teams. This shouldn’t be a surprise but it begs the question: Why do ‘classic’ FOSS teams struggle with PM and UX teams? It’s not that they can’t achieve big goals but it more that they all have some painful story about “how they want to work”, e.g. GIMP, Linux Desktop (as a group), or even graphic editors like Krita all have some type of UX team but there is almost always drama around history and culture that make UX, if not very very slow, at least problematic.
The goal of my talk is to focus on positive examples and NOT shame any specific team. My point is that it appears the most, if not all, of the positive UX examples are these type of small focused (and funded) teams. It’s a bit hard to avoid talking about that (which I know will likely blow up in my face)
Let me add Cockpit here.
Cockpit is a web-based graphical interface to administer Linux servers.
From my impression, they have some good practices:
establish a clear product vision,
communicate the vision in clear words,
tackle one common problem in Linux server administration: use a simple GUI instead of hard to learn Linux commands, but anyway have a Linux terminal in the browser if you need to work with Linux commands
have a “Design first” approach
explicitly use design drafts (created with Penpot etc.),
run usability tests,
iterate and release often.
One thing that makes me a bit sceptic are the targeted users: everybody from Linux layman to expert admin, which is IMHO a bit too unspecific.
However: I used it for a while and like it. To be honest, I run it on an OpenMediaVault 5 host, but I prefer Cockpit over OMV because of its ease of use. I don’t know how it compares to OMV 6 with its revamped GUI now.
Cockpit is a Red Hat sponsored free software project and AFAIK the project is run by Red Hat people.
Sometimes it is interesting to look at adjacent communities. I found that tools in game creation communities are an interesting case:
Like open source software, they are for a community of people the creator is part of…
…but they are often focussing on end users/non-programmers
Like open source software, there is an emphasis on creation, creativity…
…but not in code, but via music/graphics/animation.
Most likely, these apps don’t have dedicated roles like designers, an explicit roadmap and other indicators of “good” design practice.
Interestingly, some of the free tools share their source code, but not all of them do. I guess, in a community with a large proportion of non-programmers, it might not be that interesting. The tools seem also created by single creators; the collaboration that FOSS promises might not be as useful to them and/or pose a significant overhead. (Seems this community’s view on licensing is also different, even for the creative works in graphics and music; the similar-to-FOSS Creative Commons Licenses are rarely used; instead a brief paragraph stating creator’s wishes about commercial use and attribution are common)
I want to add to this - as a designer in the industry for a very long time now. It never really occurred to me to be a FOSS Designer. I always just thought of open-source as a developer world. Literally the other day, was the first time I thought “I wonder if designers can contribute to open-source and how that works?”
If a designer has input into a FOSS project it’s going to be hard to get that implemented because they may not know the language that the particular project is written in. They have to rely on other volunteers being willing to help them implement their recommendations. And everyone has their own recommendations.
as @jcklpe said here too - I really wonder how they will prioritize; but I guess it would be just the same with code contributions. In the end the ‘owners’ of the product will implement if they see fit.
So perhaps its more of a requirements to contribute. For example - if you want to contribute design there needs to be a fully clickable prototype, notes, and documentation on the changes you are making and why. The design needs to be open so that anyone with the link can also access any assets available (or also upload new assets to the pull request)
In the end, if it gets implemented or not would be really up to the “PM” of the project.
Perhaps if we created a simple framework for people to understand how to contribute, more people would be willing to do so.
Designers may not know the language, but if they have an interesting contribution, the owner can definitely reach out to them to discuss more so they can allocate time to implement if worthwhile.
As I’ve talked to other FOSS projects it’s clear that those with the most effective UX are just more organized. They plan, they have roadmaps, they prioritize. This is the world in which UX is very helpful.
The smaller repos with little UX experience are MUCH harder to work with. I’m very empathetic to their pressures. But many don’t understand what UX can do, and how it can save them time.
There really are two UX paths here: 1) To introduce UX into a repo that doesn’t understand UX well and 2) Work for team that appreciates UX and knows how to prioritize it. Both are reasonable goals. The risk with #1 is that they may not want it and honestly, there may be little anyone can do.
This is why I’m trying to call out the teams that do great UX to show that it is happening, get the community to know it can happen and get people to say “more please”.