Two rough draft lists.
Designers that want to get involved in open source projects:
- Don’t burst through the door and start yelling that you’re all doing it wrong. That might be true, but things were not made to suck on purpose.
- Instead, ease in. Find out where the daily conversation happens. Join and start asking questions. “Why is this working like this?”
- Usability tests are an ideal way to show which things need improvement.
- Write a review of the software. Highlight what you think works well and what could be improved.
- Have a user centred process. Stick to it. Show the work, take people along on the journey towards a solution.
- Small teams get things done. Take in all the feedback, pick out the useful bits but stay true to your vision.
- Have a vision.
- Make sure you care. But not too much.
Open source projects that want to involve designers:
- Not only code is gold.
- Design is not the surface layer over a bunch of code. Allow people to dig in, have some patience with what may seem like silly questions.
- Do you know who the software is for? And what those people want to achieve with it? The answers to these two questions are required foundations or effective design can not happen.
- Ask for reviews from your users (or: which support questions keep popping up in your bug tracker?)
- If every feature is important then nothing is important. Design is about making trade-offs, so prioritise. Making this thing easier to do will make those other things less obvious.
- Interaction designers create the different paths through the software. Information architects organise and structure the necessary words, sentences and other content objects. User interface designers make things look consistent and create the right visual hierarchies. Usability specialists will show you what your users experience. What kind of design expertise would your project benefit from most?
- Be prepared to write the code that implements somebody else’s ideas.
Yup, plotting my FOSDEM talk in the open :)