Missing formatting
Barriers for design according to developers
Introduction here
Firstly, the project contributors were asked about their general perception of design, its importance and barriers for creating more design influence in FLOSS projects. It was clear from the beginning that almost all of the developers agreed that it was a very important aspect of software. One developer said that “In my eyes, it’s of equal importance with the quality of the code.” (Interview #1, Jellyfin). However, by extension he also argued that design “(…) takes a low priority for a lot of projects, unfortunately (Talking FLOSS in general, here)”. This developer argued that a barrier for strong design choices in FLOSS would be to ensure that “(…) more developers take up an interest in this. Perhaps stress the importance of getting some UX concepts when training developers. Getting devs to understand that UX is just as important as code and should be treated with the same focus and care” (interview #1, Jellyfin). Interestingly he still argues that the most important aspect for him in FLOSS projects is ensuring high code quality. He argues that having code of high quality means that it’s easier to approach, which will result in more contributors and a more active project overall. This notion is also confirmed by the founder of Taskcafe that said that he does not […] ever plan a design with those things (for instance usability) specifically in mind” (Interview #3, Jellyfin). His first priority was also implementing the basic features and such before planning new goals for the project. He does however say that getting, for instance, UX designer feedback would be helpful for his project. (Interview #3, Taskcafe). Contributor #4 also argued that “it would be nice to kind of have a push through that and get to a point where we’re happy with the architecture and to have a stable, solid, or release where we can kind of get to that point where we aren’t making huge architectural changes” (Interview #4, Jellyfin.). In other words, again confirming this idea that code quality is the underlying basis for project success.
Some of the other developers outright said that “(…) it’s not really a thing that I really think about.” (Interview #2, Jellyfin). This developer argued that his concept of usability was more technical in nature. One such example would to be the ongoing database issues in Jellyfin that very much becomes as user experience problem in that movies and other media is slow to appear in the frontend when added (interview #2, Jellyfin). The very same developer does however voice the opinion that even though his understanding of such design work is limited he “(…) feel like it would be really interesting to see what they had to offer. It would, I think it would be really neat to have, say all of our applications once they eventually stopped being web wrappers to have like a semi cohesive UX feel to them.” (Interview #2, Jellyfin). Interestingly, one of the developers from the Android client argued that their current design efforts are “(…) currently doing fine, but maybe it would get better if you had such people, I can’t really imagine it.” (Interview #8, Jellyfin). The very same developer does however confirm well known design concepts such as the need for coherence, visibility and the increasing need for guidelines as a project scale due to the complexity of changes when many people contribute. This seems to suggest that what he cannot imagine is not the need for design, rather how the contribution would work in itself.
Another finding with regards to developer perception of design seems to be influenced by their experiences in their workplace. This has to do with how a traditional organizational trope is that designers provide the visual aids to the developers for implementation, which in some sense excludes developers from making these decisions. Some developers in Jellyfin voiced a concern that design contributions could be seen as “being told what to do”.
“Some don’t like the organization that having a UX/Usability team provides. A lot of developers see FLOSS projects as a playground after work. Like you work on things that aren’t interesting for money, but then you work for fun in the evening. Having more organization and a process (RFCs or a design process) might feel too rigid for some” (Interview #1, Jellyfin)
This does seem like it would be a concern to some, however it can also be argued that this is only true if the potential designers in the project engage in with the project in a way that confirms that rhetoric. As seen in the above paragraph developers has shown their interest in seeing exactly what having designers on board the project could offer (Interview #2, Jellyfin). Confirming this, another developer said that he thinks that “(…) nobody, at least in Jellyfin, will ever feel looked down upon by their (meaning designers) ideas. Every hand in FLOSS is helpful.” (interview #5, Jellyfin). A notion to support his idea, is that fact the Jellyfin already has other positions in the project, for instance the project manager(s) (Interview #7, Jellyfin), that provide non-code contributions. As such, having design contributions does not seem that far off. What seems to be the important discovery with regards to maintaining developer freedom while supporting designers in engaging with FLOSS projects, is that the project participants discuss this dynamic and how such design contributions are to be benefitted from the most. In this way, everyone is included and the project can avoid the idea that design contributions are assertive in nature.
In summary, it would seem that the developers’ perception of design concepts are overall that they are very important concepts to consider when developing software. However, it does also seem that they do prioritize code quality over for instance design choice, and it might also look like some developers might not understand how designers could benefit the project, or are afraid that their ideals could interfere with what they chose to work on.