Hello, I’m an intern with OpenRefine (an open source data cleaning software) and I’m working to improve how designers are onboarded and contribute to open source projects.
I would like to know the workflows and tools that communities use to define and help publish GitHub issues and actionable workflows for designers who want to contribute to open source projects.
Please let me know if you can help, I promise it won’t be a long chat.
Alternatively, I understand if it’s a dent in your schedule and have put together my questions in a Google form and would appreciate the feedback.
It has many aspects, but in my experience, open source projects are rather code focussed, so a lot of what works and does not work falls and stands with the developers.
Find out which tasks developers are willing to work on. Some parts of the software might have super cumbersome code, some parts might be fun to improve etc.
Find out what kinds of feedback/UX input is seen as trustworthy. The role of “the expert” in a non-coding discipline is often eshewed in FOSS projects (Then, non-coders they are “not skilled” or they are non-code “experts who just come and tell us what to do”). But there are also many communities which might trust a heuristic review, a small scale usability test or just expert opinion. The latter might be packaged in interface guidelines, which actually can be an excellent way to push for better UX, since the format is similar to other guidelines that developers follow in their work.
Prevent frustration by being clear what can be worked on. A lot of open source projects present as “open for all contributions”. Experienced programmers already know that they need to find out what “all” exactly means. For designers, be specific: If you can only change interface copy, manuals and icons: say exactly this. Do not say “happy about all your suggestions” and then it turns out that e.g. changing the widget arrangement of a dialog window is already very cumbersome and no dev likes to do that (On the contrary, if it is relatively easy, write that!)
This also involves how open source communities use the different options and tools, how to structure GitHub issues, how to use labels, how to use the GitHub teams, how to use GitHub projects to track and manage tasks and so on.
some things my team and I did at Wikimedia that go more in the direction of github use (but we used phabricator, so some things do not translate 1:1)
We used a UX tag for issues. Retrospectively, maybe a UI tag would have been better for being tagged by others (UI/user interface is somewhat concrete, but what UX is more abstract and thus less used by people not being UX designers). For internal use by a small design team you can create any tags you like (like UX-concept-Research or whatever), if you want others to use them, it needs to be obvious and familiar.
We provided a UX issue template (however, it was more used by us to specify issues than leading to a lot of people using it directly)
User Story: As a user, I want to _________ so I can _________
Context of use: I assume the user would to _______ because___
Current Problems: Currently, _________ this is not good, because ________
Possible Solution: One way to improve the situation for the user is __________
This might not be the best way to do it, but it has some non-obvious features:
The user story is a known element, but this one asks to get a goal (so I can…) so people are less likely to write “…as a user, I want to have this feature now…”. In a way, also Context and Current problems try to get some more context, too.
People often come with solutions. This makes sense in a culture that sees itself as action-focussed and eshews anything management-like. However, “lets build X” does not work well with design. There is room for that in the template, but the issue frames it as one way not as the only way.