Scott Jenson
Working on my "UX and Open Source" talk, it's clear the challenges are much the same as with proprietary software: you either understand what UX has to offer or not. The key difference is philosophical.
Some FOSS teams feel central control is unnecessary. As UX is often about making hard tradeoffs, it feels counter to the culture.
However, FOSS teams need to make hard technical decisions all the time: they DO have (some) central control! UX is no different
Adrian Cochrane
@scottjenson I'd say the main issue FOSS projects typically have in embracing UX is in understanding how to fit UX designers into their workflow.
Our workflows are built around developers breaking down problems & building up solutions. So often the mistake is made to point UX designers to individual issues.
Or other times it is hard to bring a UX designer to dedicate necessary time to a project.
Probably what's needed is to tutor interested project leaders in UX!
Scott Jenson
What do YOU feel #FOSS needs in order to embrace #UX? There are clearly going to be teams that 'just don't get it" and I'm well past worrying about them.
But there are teams that truly want better UX. I want to understand their needs. I'm assuming much of it is just having a better grasp of what #UXDesign wants to offer: broader exploration (and research) so the conversation can be more grounded and drive shared team decision making.
Scott Jenson
@alcinnz I would agree. The classic answer is "post and issue" or "submit a PR" Square peg in a round hole.
I'm leaning to getting teams to back up and think about 'planning' more than 'doing'. Back up a bit and create a few roadmap-ish things (user journeys, user studies, navigation maps, exploratory designs) so the team has a central understanding of the problem
Scott Jenson
@pevohr Fine, I'm just saying "like-minded" people in a repos should include some "UX discussion" in their 'mindedness' It's no different than coding, just another set of ideas to coordinate on.
Paul Rohr
@scottjenson The mindset is to recruit contributions from other like-minded developers, so you don't have to waste time rejecting work that's unlikely to fit.
Consider the old IETF mantra of "rough consensus + running code". When collaborating with others remotely, it's much easier to make decisions (between proposed designs) when you have something that works to play with.
Then meritocracy comes into play. You can see how design X vs Y works in various situations + then pick.
Paul Rohr
@scottjenson Coding standards + project goals are artifacts that emerge fairly late in larger projects. Earlier on, all you have is the taste + design sense of whoever started the project.
The reason the project got rolling at all is because that individual (or small set of friends) had a coherent enough approach to produce something interesting enough that others wanted to join in. Codifying that taste into FAQs is an artifact to help speed up reviews of those contributions.
Scott Jenson
@pevohr I don't really see how to do that. You can't have 10 different 'itches being scratched' in a project and expect the UX to be coherent. I'm trying to make the point that any project that wants a consistent UX needs to do some amount of shared planning.
But this point goes WAY beyond UX! Code PRs aren't just accepted without question, they are reviewed (and rejected) based on some coding standard/project goals. UX is no different.
Paul Rohr
@scottjenson I'm not sure what scale of projects you're trying to target, but a possible cultural mismatch is your focus on "teams".
There's a long-standing bias in many #OpenSource projects towards individual contributors + what they can accomplish. Scratching "my" itch or working on "my" feature. I'm looking for feedback on my design or pull request or implementation to get it landed.
Fit your #UX contributions into that model + people will know what they're working with.
Paul Rohr
@scottjenson Absolutely. The practical question then becomes how to increase the number + quality of UX-minded discussions.
If you switch your focus from "teams" + methodologies to smaller ad hoc groups of interested individuals who care about collaborating on some facet of a project, what might that look like?
How are concrete designs introduced? Who is coordinating those ideas? What artifacts do these interested parties have to discuss?
０７６萌ＳＮＳ is a social network, courtesy of ０７６. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All ０７６萌ＳＮＳ content and data are available under the Creative Commons Attribution 3.0 license.