Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'd like to exercise some of my UX/UI knowledge by contributing to a couple of the FOSS projects that I've used over the years. I've found that these projects usually have a huge deficiency in the area of UX.

I've also found the task of contributing very daunting. I setup some user scenarios and testing for a bug tracking suite and tried to submit my findings, but couldn't get a response from anyone on the team, including the UX/UI team "lead."

A fork of that same project has resulted in some UI changes, but they're still missing UX and I'd like to chip in. What am I up against? Will the scenarios, wireframes, suggestions, and testing data be useful to a team of donation developers? Does anyone have experience with this?

share|improve this question
    
I'd love to help FOSS projects as well, UX is usually largely ignored. I would love to be able to help the devs on many of these projects but am unable to just make the actual changes in code myself. –  Ben Brocka Nov 9 '11 at 19:20
    
Great question. I wish I had an answer for you. –  JohnGB Nov 9 '11 at 19:22
    
Ditto on the great question thought, I will put up a bounty if this doesn't get answered. –  jonshariat Nov 9 '11 at 23:01
add comment

2 Answers

up vote 16 down vote accepted

Good question, and impossible to answer, but here's my suggestion:

1) Pick out what you really want to improve

Since you're not in control of the project yourself, this boils down to your ability to convince the right people.

Also, since you're not implementing the issues yourself, you need to find a way to get other people to do something that you wants to get done.

The first thing you need to do, is to pick issues you really want to improve.
Go for the tangible issues. These are more likely to find the way to the right people.

Pick your battles!

2) Documentation of you findings

Since you are need to convince people, you need an effective documentation of your findings/suggestions. Note that I don't say "thorough", "deep" or "massive" documentation - but effective.

The only really effective argumentation tool I know is video documentation.

You can point at guidelines, research and test result statistics - but these are easy to ignore. A video replay on the other hand is such a powerful tool, that it is very hard to ignore. Everyone hates to see users that struggle with their product.

(Which in turn gives you a huge responsibility to use this wisely, and not abuse this to get what you want. But thats another story.)

Pick your battles and wrap them up nicely.

3) Easy to implement

As I said in my first point, you need to pick the most important issues - in addition you must show some suggestion on how they can solve the problem. (I know that you have done so in your situation, but I'm trying to answer a bit more broadly :-)

Just pointing out problems wouldn't get them fixed.

If the solution is served on a silver plate, it's a lot easier to apply the improvements.

Pick your battles, wrap them up nicely and serve them on a silver plate.

4) Presentation of the message

And how should the suggestions be presented to the project lead? I believe that the ordinary official channels are not enough. Yet another e-mail might be flagged, but eventually it will drown in the crowd. The same applies to bug-reports and feature request. Other issues will very easy defeat these "eye candy" and "nice to have" kinds of issues (especially those with low substance).

Therefore, write about your suggestions in a blog. Get some discussion and coverage, and get some other people on your side. See if the project has an account at uservoice.com, if not - create one yourself.

[battle, wrap and you know the drill...] and get some supporters!
Then you can point out your suggestions to the project lead.

5) Get feedback

Finally. Respect that other people have other interests, and that your suggestion is one out of many other issues on the road map.

We prioritize UX very high (with good reasons, of course!). But we know that some people enjoy money more (even though we keep telling them that UX = money!), and that some people just don't get the point (especially when we keep telling them that good UX leads to things that the users don't notice.)

But sometimes, the lack of engagement is just an illusion. They might have reviewed your suggestion properly, but still concluded that other issues are more important. Remember that something that may seem like an easy fix, like rearranging a menu or use a different wording, might in fact have ripple effects that makes it hard to apply.

Therefore:
Get feedback from the community and the project lead. Find out if the suggestion was to hard to implement or if it's just not prioritized. Every FOSS project lives it's own life and has a unique community. Some are very open and some are repellent. Get involved with the project and try to figure out the best way to contribute.

share|improve this answer
1  
+1 Visuals always go a long way to people 'getting it', - as well as how the changes fit in to the 'big picture' or the 'long plan'. Nobody says it's going to be easy. It's hard enough trying to get some people to even consider UX - let alone effectively cold calling to try and bring it on board! –  Roger Attrill Nov 10 '11 at 14:00
1  
I think my best approach would be to not only do all of this, but leverage my knowledge of coding (and the platform specifically) to make it even easier to implement. I'll give it a shot and see how it goes! Thanks so much for the advice! –  Nic Nov 10 '11 at 15:38
add comment

Seems like a sensible thing to do with your time, well before you do the things suggested in Jørn's answer, is to first ask the project developers if they want your help. Specify what your expertise is, and what you can and can't offer. If the devs don't reply, aren't interested, or are too arrogant to accept criticism (not that common, but it does happen), then don't waste your time. Move on to a different project.

Also, remember that most open source devs are users too (that's a large impetus for the development of many smaller projects, since there's no financial reward, and the glory wears off after a few nagging feature requests). If the devs are developing the project primarily for themselves, they may not care what other users think, or may hold specific ideals that don't fit with your understanding of what most users need. Just look at the Gnome/Kde battle that raged all last decade for a prime example. In such a situation, it's going to be very much in your interest to scope the field as much as possible before you start. Find out as much as you can as soon as you can about what the lead developers think is important in UI design. Developers may think that a UX review would be a good idea, but then completely change their minds as soon as the suggestions start coming in. If you have a shared understanding before you start, it will be much easier to find points of agreement, and ways around points of disagreement later on.

As for finding projects to offer help to there are a bunch of sites out there that track projects. Two in particular that might be useful are http://www.alternativeto.net, which can help you find open source alternatives to common software, and give you an idea of popularity; and http://www.ohloh.net which can help you gauge the effort being put in to a project, including how quickly development is happening, and how many people are involved. Both sites are user-editable.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.