findings-report.md

Designers in OSS: Summary of diary studies of designers contributing to OSS

In 2022, Vermont Complex Systems Center at The University of Vermont awarded Superbloom an OCEAN grant (Open-Source Ecosystems and Networks Research Awards program) to investigate and give designers (who are currently contributing to OSS) an opportunity to describe their experiences in a safe environment and through anonymous, privacy respecting means. We were able to award a sample of designers a stipend to record diary study information for contributing to OSS.

This short research project aimed to investigate some key questions related to design in OSS and fill some of the larger systemic "gaps" of information from non-code contributors' experiences in OSS. Due to the limitations of the study, all of these questions were answered from the designers own perspectives and therefore have their own personal bias.

• What are the experiences that designers contributing to OSS commonly have?

• What are the conditions that can set designers up for success within OSS projects, specifically regarding "contributions of design"?

• What conditions create a sense of inclusion, both at the project and community scales, for designers in OSS?

• What is a design contribution and how is human centered design understood within OSS communities?

• How do designers and OSS project developers/maintainers/communities describe "successful" design contributions?

• How do designers describe a "successful" relationship with OSS project developers/maintainers/communities around their OSS project?

OCEAN’s mission is to "study how open source communities come together to solve complex problems". The nature of human/user centered design is to solve problems using research and design methods that center the varied users of the tool they seek to solve problems for. However, little is known about how designers contribute to OSS projects pertaining to origins of contribution, reasons for contribution and contribution in relation to development work.

Design is sometimes done by developers and sometimes by those with design skills. It’s difficult to understand where these roles and boundaries lie and with whom, and what are optimal conditions for success.

Through our involvement in the open source design community, we have heard many stories from designers about the barriers to participating, the lack of tasks and projects to contribute to, and the clear ways to sustain contributions as a designer.

Key research has been done around "usability" and "users" (beyond how to "scratch their own itch" developer design and build their OSS) being listened to in a design capacity for OSS projects (Raza & Capretz 2012, Hedberg & Iivari 2009, Bødker et al. 2007) along with research into gatekeeping methods (Rajanen et al. 2015) that designers have experienced in OSS projects when they contributed design.

There are, however, very few accounts of designers' experiences in OSS in their own words that have been documented and compared.

Study structure

In order to obtain an understanding of our participants, we started off the study with a series of semi-structured interviews lasting approximately 45 minutes. Here we asked critical background questions such as:

• How did you start in OSS?

• How did you start in Design?

• What OSS do you contribute to and participate in?

• How do you decide on a project that they’d like to work on/contribute to?

• Do you contribute to OSS as part of a paid role, volunteer (free) or both? In what ratio? How does paid/volunteer OSS work feel to you?

• What kind of design do you find yourself spending the most time doing? UX? UI? Research?

• What kind of processes and communication happens between you and the others that work on the OSS? Who else works on the OSS? When does communication work and when does it not work?

• Thinking ahead to when you might stop contributing to the OSS projects you do, how would you like to leave that project? What would the design aspects look like to you?

We moved from individual interviews to create a shared communication channel via Slack (a group chat app) as a means to remind and offer support to the designers in the study. The initial intake interviews showed that the designers wanted to be able to speak with the other designers involved in OSS as they desired to be in community with them. This suggests that though there are some communities and spaces for designers, many do not have access to them or those in existence do not presently work for the diary study designers.

Through a series of questions (built in Google forms), the designers used questions to record their weekly OSS diary submissions. They could also use free form documents, audio recordings or video recordings to do this. Most designers opted to respond via the form question and answer function, and some asked for additional video conference calls to clarify details, or clarified their needs by asking questions in Slack.

An idea of who we studied and what OSS they contributed to

We published an open call for designers to participate in a diary study and selected as many globally distributed people as possible, limiting our bias towards residents and citizens from historically well represented countries. Our participants were from and reside in: Canada, USA, Nigeria, Brazil and the Netherlands. Our participants were sixty percent women identifying and forty percent man identifying. Sixty per cent of participants were early in their design (and OSS) careers, forty percent were postgraduate students. All of our study participants had been contributing to OSS for at least one year.

Participants identified as:

• Contractor freelancers (serving some OSS clients but not all, mostly volunteer OSS contributors)

• Part-time postgraduate students and part-time paid OSS designers

• Full-time designers on OSS projects

• Full-time postgraduate funded students (volunteer OSS contributors)

• People that run their own companies (not primarily serving OSS clients)

Participant ID	Part Time / Full Time	Employment Status (Contract, Staff, Self-employed, etc)	Student (postgraduate)	OSS Projects contributed to
Grey	FT	Self-employed	No	2-3
Pink	PT	Contract	Yes	3
Yellow	FT	Staff	No	3-5
Green	FT	Self-Employed & Contracts	No	4-6
Blue	FT	Staff	Yes	2-3

Forty percent of participants were paid for their OSS contributions and sixty percent were unpaid volunteers.

Approximately ten OSS projects were contributed to in some way across the study. These projects ranged from educational tools, spoken language apps, websites, events, browser extensions, open data, scientific tools, academic tools and visualization tools.

We asked our designers how they found their way into design as a career, and while twenty percent of the designers started out as developers, another forty percent had a background in art and design, and forty percent had a background in other subjects e.g. music, marketing. Most of the designers had taken a course that was not part of their undergraduate degree or became interested in User Experience or Human Computer Interaction from sources on the internet such as Nielsen Norman Group or Coursera.

How did these designers first become involved in OSS?

We learned there were a variety of ways designers came to discover and contribute to OSS. Many found their OSS pathway by engaging with communities, either around design, a coding language, university programs/groups or a group formed around a particular usage/purpose of OSS (e.g. Hacktoberfest, Linux groups, Python groups etc.). The critical similarity being that early on in their OSS design journey, all had contact with a person/people who had experience in being present in OSS as a contributor. From the way that our participants spoke, these were all reasonably positive and supportive experiences, which reinforces the need for positive early community inclusion experiences.

One designer who also identifies as a "developer hobbyist" found a local meet-up for Ruby coding language where most people identified as developers 5-6 years ago. They were curious and looking for communities to hang out with as a hobby developer, which then led to their sustained involvement in a particular OSS project. Another participant originally identified as and contributed to OSS as a coder, but then found an OSS community in need of illustrations and logos and contributed those. They then grew their career as a designer through OSS community participation and contribution.

One designer started their OSS journey in 2021 when they saw an article about OSS design and then joined a discord community called "Design Buddies". There, they searched for OSS Design and another community member’s name popped up and they messaged the community member. After a series of messages asking about OSS and design, the designer mentioned a particular OSS project they had used for music to which they were interested in making a design contribution. This led to them to make their first design contributions with support from the other community member.

Another designer was involved in OSS while studying at university where there was a FOSS program (OpenRIT) but did not contribute to FOSS outside of that program. After graduating, they were hired to design OSS tools and have been there ever since. They describe their contributions as completely paid work, though this definition gets fuzzier as they often need to write and submit fundraising applications (in volunteer time) for certain design work that is not prioritized in the typical grant funding cycles of their OSS (e.g. writing grant applications) to help explicitly fund design work they believe is critical to the OSS. A designer ended up changing their whole tool ecosystem after seeing a friend working on a Linux machine with free and open source tools. It is worth noting this designer does not know how to code and describes themself as aligned with progressive social movements. This designer spoke about the existence of, and participation in OSS as "liberating" and "ethical".

Many of the designers' motivations for OSS are shared. There is a belief that free and open tools are "good", and healthy for the technology ecosystem and designers want to offer their time and skills to them. When designers have an understanding of "healthy technology/infrastructure" purposes, they can better understand why a project exists and offer more relevant design support. The second most common reason designers get involved in OSS is to build up skills for their own careers and portfolios, either through paid or unpaid contributions.

How do designers decide whether they’d like to contribute to or work on an OSS project?

Most designers were aligned in how they first came to the decision to contribute to an OSS. The following being the most common ways of deciding an OSS project is ready for design contributions:

• Is it reasonably clear what the OSS project wants from the design/designer? Is the project clear what problems they want solved by the designer?

• Am I able to do that skill/task or am I able to learn how to do it for this contribution?

• How "in need" is the project? Are there others that can do this or does the project have good enough support to get this done elsewhere?

• Is this OSS a one-person project and is it still active?

• How close is this OSS to my culture/geo-location? Will I be able to contribute in my native language comfortably and be welcomed with my context?

• Does the documentation make sense to me and can I learn enough about the OSS in order to participate?

One designer described a problem with OSS and design contributions early on in the process: “OSS (projects) don’t create design issues very often. People (running OSS projects) don’t know how to describe the problem although OSS people may know there is a problem. Very few if any are managing the problem or issue”. These were described as "stagnant problems".

Most designers are looking at the OSS project’s GitHub and looking for "activity" and recent issues. This helps to alleviate some designers' fears described by one in the study as “(I’m) hesitant to just contribute a design and it’s tossed into a void and you never know if (and hope) someone will do something with it. I want certainty”. Interest in a project’s activity extends to social media spaces designers are mostly active on, that developers are not (e.g. Twitter, Dribbble, Behance, LinkedIn etc). If an OSS project is active and communicative on platforms they see an "alive" project.

For the rare designers paid to work on projects, they described them as being "handed" to them, and the OSS project’s attitude as “we have a ux designer now! We can get help”. These paid designers sometimes have a choice about who they want to help but this is often dictated by the funding for a particular piece of design work on a specific OSS. As described above, one designer discussed taking this into their own hands by writing their own funding applications to improve parts of OSS that are underfunded and lack attention, such as accessibility improvements in their own volunteer time.

People with marginalized identities often make choices about which OSS to contribute to based on how welcoming the OSS community appears and how relevant the OSS is to their cultural context. This often happens by way of a friend recommending a specific OSS to the designer and assurances of its safety. These marginalized people want to know in clear terms that they will be valued not only for their contribution, but for who they are, as a person, trying to be better represented in OSS and Technology spaces. Such considerations are somewhat familiar to designers in open source in general, as design and designers are a marginalized function in OSS, as it is often under-valued and under-represented as a core component of building usable (OSS) software.

Many of the designers involved in the study believed that OSS should not be short-changed by missing out on design contributions, because of how design has been largely absent from OSS spaces. As one designer states, “Just because you don’t have lots of money doesn’t mean that you don’t deserve a proper logo/design.” This extends to all forms of design. Our participants contribute to OSS projects and often, designers are frustrated by OSS projects when they do not implement their contributions. This connects back to the core belief that design improves (OSS) software and OSS deserves attention too.

What tools do designers use when contributing to OSS?

We wanted to understand what tools designers were using across their contributions. We discovered that the designers in this diary study the most frequently used tool for design is a word processor, usually Google Docs, and in one case, Libre Office. Primarily these were used for design research related documents and ways to communicate and clarify designs or processes around conducting design work (e.g. usability tests, accessibility reviews). Designers also used Notion and largely described this as a documentation and document sharing tool to use between team members.

The communication tools that designers used were largely dictated by what was used by OSS maintainers or projects. This ranged from enterprise paid tools to OSS communications and work sharing tools. The communication, including video conferencing, and chat tools used were: Slack, Telegram, Discord, Webex, Zoom, email, Reddit/forums, Internet Relay Chat (IRC), Element/Matrix, and Jitsi. In one instance a designer described "picking up the phone and calling a stakeholder". This was described as a transformative process in terms of making decisions and having clear communication with that stakeholder. The same designer also described meeting fellow OSS contributors in person and working together as a critical component to ease both their working relationships and that current design work.

All of the designers at some point used either GitHub or GitLab either to upload images (.svg and other file types) to relevant issues and/or pull requests, or to communicate with developers and other people working on the OSS.

Two of the designers were actively working on code alongside design tasks and typically used Microsoft Visual Studio Code but also mentioned using Brackets and Codepen.

A unique events tool called Hubilo was used by one participant in order to set up and organize the OSS event to which they were contributing. This participant also used another video conferencing tool called Around.co. Other unique tools that were used were Audacity, which is typically used for audio editing work and iMovie. This is likely because there were participants working on OSS projects that dealt with audio and video files, for example needing to upload video content to an events website and OSS that processes sound files.

The design tools participants used were a mix of paid and free proprietary commercial tools, e.g. Adobe Suite (Photoshop, Illustrator, etc), Figma, Canva, Pixlr, Axure RP (a prototyping tool), and some OSS design tools such as Penpot, GIMP and Inkscape. Additionally, accessibility-specific tools were mentioned for tasks like checking color contrast.

Some designers also mentioned using common image browsing websites when building websites such as Pinterest and Dribbble.

Notably, only one designer described using pen and paper as a tool to complete their work.

What artifacts were shared across the sixteen weeks?

Most participants shared either UX research written documents, repositories (GitHub/GitLab) or websites of information as “artifacts". They rarely shared User Interface (UI) progress design with us, but they did describe the processes involved in designing the UI elements such as technical requirements, conversations with users and developers/owners of the OSS projects. As interface design was clearly occurring, the question is “why was it so rarely shared?”. One plausible answer is that these "artifacts" (that were also shared with us in the study) are specifically made for sharing within the OSS projects, and are also of great importance for collaboration between different expert groups. It might be possible that some of the designers in the study wanted to show “finished” or “impressive” artifacts, rather than work-in-progress documents.

Four collections of contributions focused around OSS events for particular technologies and the design work required to operate those events (e.g. illustration/graphics, merchandise design, event website design, form design etc). The remaining design contributions were a combination of User Research documents (user testing plans/scripts and Heuristic Analysis) and results, UI/UX design visuals in shareable design file formats, design/visual systems for projects to follow, accessibility research/design and design insight/guidance in issues/PRs.

Some contributions could be described not strictly as "design" but communications, collaboration preparation, organizing, community coordination and stakeholder management. Often these are essential tasks that enable design contributions. Each participant contributor spent time on both “design contributions” and the essential work around design. Some delved more deeply into project management and product management as well as organizational administrative tasks.

Designer-developer collaboration

Designer and developer involvement and collaboration was a recurring theme in the diary study and reveals behaviors which could give us clues as to how design is regarded by developers and other roles in the OSS, as well as the nature of design being a collaborative process informed by not only users, but business/product goals and technical constraints.

One participant reported to be involved in code more frequently than others, spending up to fifty percent of their working time on coding. This participant mentioned activities such as “(opened a) public repo to start a website for the (OSS organization’s) Diversity and Inclusion Workgroup” and “Merged some contents from other team members onto the page”.

On the other hand, other participants barely mentioned coding, if at all. A notable example of the attitude towards coding is one participant’s comments “I made two commits to repos. Usually I let other people handle GitHub”. This participant even reported this as the highlight of their week, which suggests that coding as an activity is viewed positively, and perhaps even empowers designers.

At some point, all designers used GitHub or GitLab - traditionally seen as tools for developers - for communication and collaboration with developers. However, the participants also mentioned struggling with the tools: “(I’m) Not sure the best way to use GitLab for design tickets.” “I hate GitLab, it is confusing and the team did not put me as (a) developer yet.”

One participant said “I was unfamiliar with how to make a GitHub webpage so I had to send feedback on the content by email rather than editing it myself”, indicating that they are genuinely interested in using these tools, but a lack of understanding and onboarding to the tools causes frustration.

Conversely, developers were more involved in the design process, with designers “Getting responses from developers about design proposals”. All participants mentioned getting feedback from the developers as a crucial step in their process. One participant went into more detail about how “Developers decided to simplify a button, removing unnecessary text, and suggested some icons to replace the text with”. Often, designers go out of their way to ensure better collaboration with developers, with one participant mentioning that “(I) made a user-flow diagram to make my designs more comprehensible”. The results of these efforts also don’t go unrecognized, as one participant reported that “a developer found my organized Figma files useful”.

We can clearly see that when interested and encouraged, developers are able to participate in discussion about design aspects of the OSS they are part of. Designers in this study are making consistent and sustained efforts to understand the OSS from various perspectives. This gives us a clue as to why lack of communication and feedback responses can block designers from fruitful OSS involvement, since design thrives on collaboration and cooperation.

It is clear to see that not including designers in the aspects of OSS which are seen as more within a developers’ domain eg access to repositories, ability to merge code or know how a web/digital infrastructure is set up, creates some of those gaps in knowledge captured in this study and distances and disempowers designers in the developer dominated domain of OSS.

Openness practices

For most of the designers, the process that OSS used was open enough when it came to transparency in the design aspects, and some made other efforts to be open with their design, and their work in general.

Participants share assets and resources with their community and other stakeholders in an effort to be more open. Sharing these assets is also limited by the processes of the organization they work within, as one participant mentioned that they “cannot submit any (design work to us as the research team) before the design has been approved”.

One participant “invited new contributors to oss design to participate in the project” and another “joined another (geolocation) community … about free culture and communications in general” indicating that they interact with the community they are part of as well as new OSS communities in an effort towards being more open.

One participant mentioned migrating to an open source tool to be more open, and they also reported having issues with the previous, not OSS design tool. “I’m on the way! Using Penpot and not Figma, maybe?” “Penpot can not navigate between pages yet”.

A not often spoken about aspect of openness is around how openly users can access the OSS. One designer mentioned that, through their design work, the users were able to ‘discover’ this open tool to use with their families. "I'm not sure if this counts, but for the first time, most parents in my region were finding out about this free (and open source) learning tool for their kids.”

The motivations for being open seem to follow some general themes. Participants who share their assets and resources do so for easier collaboration with stakeholders, as one participant was “Trying to re-organize my Figma design for better handoff”, presumably referring to a developer handoff and another “created a speaker's kit for all speakers with design assets and slide templates”. These assets were reported to be received positively by whomever they were shared with. “I heard back from someone I shared open design resources with that it was helpful and that they will be using our contributions”.

The risks inherent with not being open with your design were evidenced in one interaction where “[a] Collaborating designer took the wrong design file and got an outdated asset in his work. So it needs to be retracted and redone.”

Another motivation for sharing assets was to have more involvement from the community, as one participant “shared the doc with the team at (OSS community organization) for other designers to make inputs”. Growing and strengthening the community itself was also a motivation, whether it was by interacting with other members of the community, or by giving credit where due “Apart from my design contributions, I also had conversations with other open source designers and project owners on the future of design in OSS for 2023.”

However, growing a community is no trivial feat. One designer spoke of their efforts to ‘open up’ their processes and ask for more designer involvement. It appeared not to work “I am stuck with the same amount of pressure as usual. I'm hoping to take a less stressful but more profitable action this year by speaking with the larger open source design community”. This demonstrates the effort exchange needed by designers to either focus on openness or continue through the work solo. Both take effort and designers (like other functions in OSS) are time-limited, and they must make careful and risky choices with choosing to open up more.

Designers speaking about success

Success via feedback

Designers measured the success of an ongoing project in two slightly contrasting ways: when receiving no feedback (but no resistance) and receiving feedback (with low or understandable resistance). The designers saw their work as successful when they saw the feedback they received as relevant and useful. Often, the designers saw their designs as successful, which is unsurprising since they used usability tests and user interactions to inform their design.

Designers tend to assume “they’ve got it right” (i.e. are successful) if there are no questions or feedback on their design work. This was less so if the designer did not seem particularly confident about their proposed design.

Participants also viewed “slow” feedback negatively – the lack of communication was seen as a progress blocker. There is a distinction to be made between the two kinds of “no feedback” mentioned by the participants. One is positive, i.e. the design is “good” and there are no changes required, and the other one is negative, i.e. there is a lack of any feedback from the other stakeholders, which is frustrating as it hinders progress. This can be confusing to differentiate between but was informed by paying attention to the nature of the communication before this feedback event. If the communication had been generally positive and active, no feedback was good. If the communication had been lacking and generally negative, no feedback was bad.

One participant described “usable feedback” as the best kind of feedback, referring to feedback that is specific enough to give guidance where needed but not resistant to design as the method of improvement. One designer consistently described success as “When I get feedback on what's wrong in my design and get next steps that are actionable”. We, the study researchers, would like to highlight the use of the word “wrong” here. We saw from the qualitative data that designers spent a lot of time communicating, understanding and collaborating with stakeholders and OSS project contributors as well as the users of the OSS tools. ‘Wrong" is a word that could refer to a number of different specific interactions, mostly likely that the opinions of the OSS project maintainers are "correct" and the designers are "wrong" (or possibly misinformed from a technical capabilities and/or specification’s perspective). Designers rely on OSS project developers and maintainers to define what is "correct" throughout the process of design. Outside of the OSS space, designers tend to rely on a "user" perspective informed by direct research or a design hypothesis process which predicts and explores user needs.

The needs of open source projects are often described in short problem descriptions called issues, managed on a web platform. This is very common for code and code-adjacent tasks. However, design tasks are frequently not present as issues on these platforms. If they exist, details are often missing. Therefore, designers’ issues do not follow the same patterns as development issues.

It is worth noting that, though "issues" are the way that developers/coders define the work to do on OSS software, designers tend to rely on brief documents (which are similar in tone to issue criteria, but often more verbose) as well as iterative collaboration and feedback cycles with "clients" or "stakeholders". The notion of "feed yourself" by picking up an issue, writing code, submitting a pull request and gaining line by line feedback is not a practice that designers (across UI, UX and Design Research) are familiar with and it is arguably not a practice that maps to design processes. Here we observe a consistent tension when we look at design in software development, particularly that of OSS which is more dispersed, piece-meal, remote and with "gaps" in communication, knowledge and time — unless designers can assert themselves as user voices and the design process as the process that defines "correct" and "wrong", “correct” and “wrong” will be defined by the developers and maintainers’ opinions and time.

Theoretically, designers could assert themselves as the voice of the user and the evidence in the design process they utilize as what defines “right" or "wrong". However, given designers' marginalized position in OSS projects, they are mostly unable to define this themselves. Thus they defer to the more powerful developers to define the "right" or "wrong" of their design contributions. The section ‘Processes: who makes decisions and how are they made?’ speaks to the power differential and existence and accessibility of governance documents for designers.

These opinions are still vital to good production of software, as they contain insight into technical capabilities and overall project understanding, however, developers and maintainers should not be held to a "standard" when it comes to giving informed and experienced design related feedback. Especially when design is likely not their area of expertise or learned knowledge.

To support the discussion around opinions on design, a comment from a designer suggests the root of the problem – “(it would be good)... If stakeholders understood what I meant in Slack or a synchronous meeting and were able to give feedback”. Here we notice that design and the processes it utilizes are sometimes not understood by people that are not experienced in design or with design processes. Therefore they may struggle to give effective feedback on design beyond "It’s good", "It’s bad/I don't like it”.

If a designer is unsure whether a design will be accepted it means they might delay working on it. As one participant said:“There was a delay in feedback from my prior conversations with the maintainer, and I was unable to kick off immediately” and “I try to set up calls with maintainers who leave comments on the projects. The feedback has been slow as well.”

From the data we saw a gap of between one week and three-four weeks in essential feedback designers were waiting on. This often drives the designers to persist with asking for feedback or in some cases move onto another project where they are given feedback more consistently and quickly. As discussed in the "How do designers decide on an OSS project that they’d like to work on/contribute to?" section, designers want to know they are adding value and are needed by projects.

Success via completion of design and/or "live release"

All designers universally celebrated contributions that went "live" in a "finished" way such as websites being accessed by the public/people outside of the project. “I know that the design has been accepted when they say "they look great"?? and asked for the files.” is how one designer described completion success.

However, most designers were unsure when something would go live if they were unable to control the process and actually publish the work themselves. “Not sure which designs will be implemented when, since we're not using product management strategies”.

Designers also expressed frustration around design that, in their opinion, was ready to go live but instead was held up by rounds of approval or at worst, by developers or maintainers requesting design changes. “The logo was already done, it was not so good in my opinion, but it was usable, then some people started to think too much about it to change. It is not good because we are a little bit late with the materials and social media content”.

Success via knowing what is a priority for the OSS

Measuring progress on priorities was difficult and one designer spoke consistently of the need for a product or project manager to guide them to the highest priority task. Designers in this study expressed that they had ‘a good idea’ and were confident in their knowledge of what needs to be done and when (especially in terms of the design), either based on information and feedback from the OSS project developers/maintainers or based on user research and feedback. From our researcher perspective, we saw that designers were using established user research and user insight gathering practices in their design work and thorough processes for checking their assumptions.

Designers employed a lot of tactics in order to better understand priorities in the absence of a documented roadmap or plan for the OSS, or when the OSS plan exists in a single mind or collective of OSS community members' minds and is subject to change. One participant described a way to learn from stakeholders:“Not much of a hack, but I've started to get important stakeholders (often project leads) to sketch out their ideas more so that I know what they're thinking”.

Designers commented that there were “no clear roadmaps for implementation” of the OSS and that while issues and meetings presented a pathway, these were not always coherent or indicative of any wider objectives. This didn’t present as much of a problem in OSS projects that had external deadlines, such as events and conferences, and also didn’t present as much of a problem when the designers had some authority and/or were held in high regard within a particular project. See the section ‘Processes: who makes decisions and how are they made?’ that speaks to power and governance for more detail.

Overall, when it comes to design priorities within OSS, many projects are still nervous about making decisions on what design should focus on, as, unless user research or user research has already been gathered and understood as user insight, there is then a question of whose opinion of the OSS takes priority and in what capacity do they trust design changes? As one designer states “Most projects are still very skeptical about making design changes”.

Success via attracting more designers to the OSS

A subtle measurement of success and joy expressed by designers in the study was the ability to work with other designers. The same joy was expressed by designers when they worked with other role functions on design tasks in the OSS projects that they contributed to. One designer had an explicit goal of attracting more designers to the project through the way they distributed and built tasks. _“The goal of the OSS community this year was to network and get more designers. We understood from past events that webinars, workshops, and Twitter spaces were the best ways to gain African contributors”. _

When gathering collaborators in OSS for design tasks there is an awareness from designers already in OSS that most designers are newer and looking to gain certain types of experience with their contributions.“This is a challenge because most designers looking to contribute are new designers and are contributing to open source to gain experience”. We observed this can be tricky for designer contributors for two key reasons — time and a sense of responsibility. The amount of time designers have to spend working on OSS is often limited, as they can end up spending time on design-adjacent tasks. When the additional designers are new designers, they often end up managing the design work and providing good tasks to supply newer designers with experience. Many designers in the study expressed "wanting to do actual design work" so the responsibility that comes with onboarding new designers is high in terms of what they, as an established designer in the OSS project, feel they must do to provide a good experience.

Future hopes for a specific OSS project in this study, is that increasing designers working on OSS design tasks would “Reduce the pressure on me and the other active contributors”. We did not observe that increasing the number of designers working on OSS has an effect on the OSS during the sixteen week diary study period but we suspect the benefits extended beyond the sixteen week diary period. We would need to observe this beyond the sixteen weeks in this study to discover benefits and challenges.

Though more designers contributing to OSS means success, the specifics can be tricky: “Working with other designers (means it) can sometimes be hard to convey a consistent design style that you want to maintain”. When working with other designers doesn’t go smoothly, the subsequent "coordination and fixing of design" in order to retain consistency can be complicated labor and can unintentionally communicate an untrue lack of efficiency of design. When these complications arise, we can look towards the lack of support for design in OSS tooling and platforms as a hurdle.

The reality for most of the designers in OSS is that they are primarily working solo on design tasks. “Most of the time I ended up being the only one doing the designs as the rest of the team are mostly developers”. Most solo designers expressed great joy when able to collaborate with anyone and happily shared documents and diagrams that were collective efforts.

Aside from attracting other designers specifically to the OSS, on multiple occasions, one participant stated the need for product/project management and how they were consistently performing product management tasks. They described success in terms of getting a product manager to help by contributing “I need more organization for delegating what tasks need to be done -- i.e product manager!”.

Success via acknowledgement, inclusion and collaboration

Positive acknowledgment was a big motivator for not only success but also generally helping the designers involved to have a good time contributing to the OSS. Overall positive comments were given to all designers across the duration of the diary study. Some of these comments were specific to designs, and some of the comments were directly from users who were excited about improvements to the OSS as a result of involvement in usability testing and design.

These comments demonstrate the type of positive feedback designers receive that encourages them to continue. “We received positive feedback and met with community members who were very excited about the software” and “The landing page was well received by the public”. The following comment is also paired with another indicator of "success" which is receiving a publishing or live date for their design work. “I received a very positive response on the logo designs I've worked on for the OSS project and dates are planned for the launch of new logos”.

An additional benefit to complimenting and acknowledging design’s positive influence on OSS is that it can make other roles and functions in the OSS interested and invested in the design process. “The Django team complimented the website I did. Which made them interested in my work”. One designer explained this indicates potential for more design collaboration and involvement from this team in the future in the form of synchronous design collaboration. “Yes, I like talking with (users) and engineers/developers while mocking up our discussion in front of them”.

There were also examples when designers or design (as a practice) were misrepresented or designers were not included in some OSS processes. “Participation in a conference was mis-represented and was upsetting”.

Two designers spoke of being excluded from GitLab as a platform which meant they could not participate and affected their contributions and mood towards the OSS. “I hate GitLab, it is confusing and the team did not put me as developer yet” and “it's my first time using GitLab for documentation. As a designer I never need to use tools like this.” Ensuring that designers are onboarded onto platforms and tools in an empowered way is critical so that they feel included in the project. This can be done by making them aware beforehand what access permissions they will have to tools, and the OSS developers and maintainers asking designers about their knowledge levels ahead of onboarding. This is further explored in the following general comment about a designer that doesn’t feel like part of the community and the difficulty in being somewhat of an outsider. “I noticed if you are not part of a community it is difficult to contribute as a designer”.

To compound the difficulty with inclusion and collaboration in OSS, designers often struggle to assert themselves in collaboration situations where developers, maintainers and users speak at length about particular issues or topics, and the designer doesn’t always feel empowered to steer back to what they need to make their design contribution successful. “Should I let someone keep talking passionately, because it was kind of derailing the meeting? Their opinions were valid, but only semi relevant”.

Success via accessibility and usability

Throughout the diary study period, a number of comments related to the accessibility of not just the OSS product but also the OSS contribution process in general. The designers seemed to have an awareness of when the OSS wasn’t meeting accessibility and usability standards, but only two designers worked specifically on contributions that improved the accessibility and usability of their chosen OSS. “We will not use tabbing as a method to navigate from the OSS cell to cell with a screen reader/keyboard. We implemented it, tried testing it, and got feedback that it was not preferred”. We can see a more direct correlation to the goals of accessibility as a design ‘task’ and the process it took through implementation and testing with users to ascertain success, or not.

Another spoke about success only being obtained once all accessibility goals detailed in an audit document were resolved. “We have set accessibility goals for the project, once we meet all of them, we can say the project was successful”.

Other comments made by designers were more about their approach to practicing design and noticing these moments when accessibility and usability were missing. “To test the OSS product, we had to download the software. It is not downloadable by everyone yet”. This comment demonstrates how certain users are excluded when specific operating system versions are not available to them, for example an OSS may have a version that works on android devices but not on apple devices.

In a general sense, designers try to encapsulate the voices of the users, which is inclusive of their accessibility and usability struggles. “I generally try to be the voice of the user”. When tasks related to accessibility and usability are not explicit we do see accessibility and usability being passed over and not explicitly addressed by the designers or OSS in favor of other, more important or time critical work. This is not surprising given the evidence we have of designers consistently stating they do not have enough time to address tasks in the way they would want to address them and that they struggle to communicate design motivations.

Communication

Designers were asked to describe what worked well and what didn’t work well in terms of communication.

“Feedback real time” and “(the communication process) Has to work well with the people that we collaborate with”. The designers had a preference for “email comms and chains of threads… could trace comms that way” alongside larger documents that can capture the processes used by the designer and the processes used by the particular OSS projects “Notion is great for documenting the process”.

Designers described being flexible to prevent communications problems to do with a tool used for gaining feedback, and expressed that they would find another tool or other methods to better fit the developers/maintainers in an OSS project.

Designers also recognise that, like themselves, some contributors are not always in communications channels or actively contributing. One designer described needing to be "persistent" with communications.

Designers expressed that meetings are not needed for small details but we also discovered in our study that sometimes small details or small decisions provoked complicated discussions.

Having direct communication with developers working on a specific OSS is important to the designers working on that same OSS. Meetings were described as sparse and not where work gets done but where updates happen. Written communications and comments in design files is where the progression on design work for OSS tends to take place. “If I don't get a response quickly I'll lose interest. I need people to be quick if it’s free contributions.” and “Comments are helpful - "’it’s good’ isn’t helpful (the feedback) needs to be more (defined) but there isn’t a good dialogue with the design.”

Another designer had a different opinion on meetings stating that they were “big on setting meetings. Working meetings are the way I get work done. I need to gather knowledge in the meeting and then also to demo design for feedback and make progress.”

One designer described communications on OSS projects as “easy because (they) text on WhatsApp and many are friends” and that most of their contributions to OSS have previously had design guidelines or places where they could gather information on how to do design for the OSS. Miscommunication hasn’t been an issue but slow communication in OSS where they are not friends with the other contributors has been present.

One participant detailed a specific challenge they have in that they are not confident with their English language skills and that most popular and prominent OSS operate in English. They were often worried about miscommunication from their side and did not feel good when they received feedback or participated in communication that was difficult for them.

The long cycle of communication in OSS

As explored in the success sections, the communication cycle was a large and recurring theme for designers in OSS.

Communications take a "long time" (between one week, which is described by designers as not long and up to four weeks which is described as long) going back and forth between designers and developers. “I spent quite a lot of time bouncing back and forth on clarifying the designs among the project team, the liaising designer I work along with for this project, and our supplier.” There is a common belief among designers in our study that developers are "busier" and doing "more important" work than others in the OSS projects. “The design team usually responds fast, developers take a bit longer to respond because they're working on more things”.

Designers made efforts to streamline and make communication go more quickly and tried to ensure designers put across the meaning, purpose and process of the design. “I also knew that my suggestion was accepted on improving the work process and I have to work on creating the new workspace on Notion now in hopes that this will speed up the communication process”.

Even with designers making efforts to communicate frequently and clearly (using explanatory documents etc) there are still challenges around who and how many maintainers/developers/OSS project people needed to be included in decision making. One designer detailed the number of people involved in agreeing “Generally, there has to be an agreement amongst the team (it's mainly 3 of us) on implementing a solution.” Another designer detailed some of the implicit or inherent hierarchy within OSS projects “(Communication has been) not too good, but more related with different scales (level of importance in the OSS) on making decisions”.

It was not uncommon for designers in the study to spend over half their time in a week on communications and in some cases, the entirety of their time contributing to OSS was spent on communications. “A Hundred percent (of the designer's time was spent on) communication. It's okay, I guess.”

Some of the reasons communication stalled makes logical sense, such as national holidays or time zone shifts. Since OSS may be volunteer-led there are times when designers and developers are working on OSS over holidays and weekends. It is expected communications will pause over generally established periods of rest, but it is still noted by designers when feedback was given in good time during these rest periods. “Communication was swift but due to time zone differences and holiday season, it took a few days for some to reply”.

In the study, we noted that one designer indicated when a developer/maintainer asked multiple designers for the same task. This is a way that OSS projects ensure that a necessary or time sensitive task gets done rather than implying that a specific designer can’t do the task. “Sometimes one single project might need to reach out to several people for the same task”. The designer that spoke of this in our study understood that asking multiple potential contributors is commonplace within OSS culture. Without this cultural understanding designers may think this approach to be rude.

Similarly, another designer spoke about how specifics of OSS and the function performed: coding, development as well any specific domain purpose of the OSS (e.g. Sciences, analysis, AI etc.) can be misunderstood, and knowledge taken for granted. “I encouraged someone to write up more clearly what work they had worked on because I was having trouble understanding what they were saying”.

Processes: who makes decisions and how are they made?

Overall, over fifty percent of designers' weekly time is spent on communication tasks in order to ensure the design work they do is best understood, and stakeholders are involved and aware of changes. As discussed in the communication section, communication tasks are not commonly described as part of ‘design work’. It varies from individuals and OSS projects how communication is regarded and categorized.

When the process becomes unwieldy, designers begin to say "there are too many people/stakeholders involved". The design work is then expressed as "hard to manage" which in our observation, means design takes more time than anticipated, and decision making, finalizing design iterations and feedback becomes confusing for everyone involved.

Like many people, designers find it difficult to keep revising design work based on opinions from other OSS members. This is typically not a problem if there are boundaries around feedback processes such as being time-bound and feedback being specific to requested design aspects. But most OSS projects do not have these kinds of processes in place ahead of designer contributions. It then becomes the designer’s responsibility to set the boundaries for their own work.

Below are a series of comments from designers across the study pertaining to the speed, clarity and specificity of feedback, and decisions on design work.

• “It was moving slower than expected. I need the designs verified and confirmed by the OSS main team. It took them a week to respond.”

• “I find that the process is always stretching way too long and slow to get verified. I am trying to figure out a better solution to shorten that process”.

• “Since it's a small team, we don't really follow an outlined process. I would like to map out user stories if possible”.

• “Getting a confirmation on the current work and to move on to the next stage was a little tough since responsibilities on tasks are not specified”.

There is a desire from the designers to understand the user goals of the OSS in order to design well. If that goal is not clear in one or more maintainer’s/developer’s minds, or documented well as a community discussion process, the designers often take it upon themselves to define that goal. Here a designer explains how they facilitated the decision/goals process by raising the topic “One decision on how to display specific types of data in a network-like graph. Project lead made the final decision, I brought the topic up.”

In some cases, maintainers/developers of OSS projects offered to share decision making power with designers. Designers expressed gratitude when decision making power was extended to them, but sometimes felt uncomfortable and lacked confidence in that decision making power when it extended into knowledge about the OSS that was unknown to them. Designers did not know how they could obtain decision making power without it being "granted". We found no references to governance or decision making agreements in the OSS the designers were involved in. This doesn’t mean governance was absent from these OSS projects, but designers did not express knowledge of it. If designers know about and are involved in governance processes for OSS, it might equalize maintainers’ power over design choices between them and designers. As one designer stated “Getting a confirmation on the current work and to move on to the next stage was a little tough since responsibilities on tasks are not specified.” Another designer talks about being unsure whether decisions were even made due to the way updates from the OSS were shared “Updates are not always shared with contributors. So I am unsure if any were made”.

One question remains unanswered; who should be making the OSS project/product decisions that inform design? This is a difficult question, and one that is often missed when OSS are small projects that are started to "scratch a developer or user community’s itch", and ultimately becomes a source of confusion and frustration when trying to ensure broad and inclusive user bases are designed for.

If an OSS project is meant to be from developers, for developers, decisions can be discussed, made and documented in code itself (Bolici et al, 2016). However, this developer-focussed model of self-organization around code is problematic when concerns of end users need to be taken into account and when different non-developer experts (like designers) work on the software, too.

Who are the "users'?

Sometimes there was a fuzzy line between the "users" giving feedback and the "people that also contribute" to the project. This is in contrast to other research on the role of users which is often attributed to those "outside" of the organization (Woolgar, Steve 1990; Agre, Philip E. 1995.). The definition of when an OSS stakeholder is a user, community member or a contributor is unclear. If the stakeholder also helps to develop and build the OSS in a "has committed code" way then they are typically called contributors and if not, they are named as users or community members. These different ways of categorizing "users/community members" and "contributor users" expressed itself in what they were involved with and whether this was "active" (participating in discussion in a meeting/issue, writing responses to accessibility needs etc) or "passive" (being a "tester" in a usability test scenario). A way of addressing this confusion about user definitions could be through collaboration with design researchers, who help projects understand the nuances of their users. Knowing that designers can contribute this user definition work as a design contribution is a good step towards better understanding users and where their insight is most valuable (in regards to their OSS usage) and also in inviting design contributions beyond ‘visuals’.

As one designer states “I did not speak with users that aren’t part of the organizer team”. This phrasing suggests that the organizing team are also users but not the kinds of users they had in mind for the particular task or need. Here we can see a clear way to improve user centered design in OSS by helping designers to define rough definitions of user types of the OSS collaboratively with OSS project team members.

When discussions were held about any aspect of their work or the design of the OSS, designers largely described maintainers, developers and other people involved in the OSS project as "contributing" and "collaborating" on design. This supports the idea that some OSS is built in community with others and that everyone involved in using, contributing or collaborating with the OSS is part of its sustained existence.

The most contact users had with the OSS was typically through structured usability testing in meetings. A designer had tried to create an asynchronous process for gathering usability insight but it was unclear if they were successful. “We discussed trying async usability testing. We have not actually tried it yet but discussed the pros and cons and started forming a plan.” As with many user focussed design processes, it seems as if the limiting factor was the approval process for the "formalization" of gathering usability insight. As researchers we see this gap for open resources for designers contribution to OSS and the OSS projects themselves around asynchronous usability testing processes, formalization of usability insight and helping to understand when user feedback is at a state that is permissible or substantial evidence to progress a user centred design decision.

One unique usability testing interaction was not designer initiated. A graduate student researcher who tested (the OSS) in their work reached out to the designer of that OSS. This graduate student researcher and the designer decided to meet up at a conference to discuss these results.

Another way that designers learned to understand users was through a website’s usage metrics. They were able to tell when "users" started accessing and using a particular website page they had designed and built. “I suppose much later when we get real user feedback on the built form we will know if the suggestions incorporated into the design this week were useful or not. But we won't receive that feedback until more development work has been done.”

The term "real" here is interesting and relates to the beginning of this section where our designers had trouble defining who was considered a project collaborator, user or fellow contributor (user). In our researchers' experiences, developers and maintainers can be viewed as being ‘too close’ to the inner workings of an OSS tool to be described by designers as effective user feedback sources. This further expands the complex issue about how to describe different types of users in OSS.

Broadly speaking, users were defined by their participation in usability or user testing. Testing was used as a positive mechanism for many of the designers to involve developers, other designers and community members of the OSS into "user insight" design processes. This appeared to lead to, in later weeks situations such as “The team (developer and leads) had discussions about user-friendly labels for describing data types, had discussion about the UI for a filter” and “The project lead for the browser extension started an outline for a human-readable information architecture for our data”.

The other notable definition of a "user" is when "bugs" were submitted in relation to design. “One user mentioned that the registration button on the mobile sign-up landing page in the event was missing”.

Finally, there was one instance where a designer directly collaborated with a user on design work “In the (OSS project), I designed in contact (collaboration) with the team that is the user too”. This could be one case of participatory design in OSS, or as close an extrapolation from the diary study data as possible.

Designer’s lives

Dealing with an overwhelming amount of design work and an absence of requested design work

Throughout our study, all of the designers had a full workload. Additionally, they stated they had more work than could feasibly be completed within their time constraints. Their time constraints were limited by how much time they had to contribute within a given time period and whether other individuals in the OSS projects had done their part to unblock designers on their tasks when asked/required. If unblocking happens across multiple tasks then designers now have to contend with many tasks needing work. This typically occurred for designers contributing to more than one OSS project at once.

Different strategies were employed to deal with large workloads. One designer reached out to a different OSS community for help and received it from members there on a particularly difficult task.

Another designer explained that “(I) ran a meeting where (users) gave feedback on a UX design mockup”. There was a lot of feedback after this meeting so to follow up a teammate offered support. “The project manager on the project offered to collate and organize that feedback for me so that I wouldn't be overwhelmed by it”. This situation meant that the designer had some feelings of "abandoning" the data from users and expressed their nervousness “I am usually very involved in the process of going through feedback so I am unsure if having a person between me and the users is a good idea or not, but we are trying it this time. I don't yet know if it will work well or not”.

When designers discover new groups or projects that need design they express positivity. However, designers are disappointed when these OSS projects only "require" one designer or don’t have many tasks for designers.

Designers typically look for new/other OSS projects when their current OSS project has exhausted design tasks or is stalling on decision making. Or when a designer is mentoring other designers who want to contribute to OSS and need OSS projects and tasks for mentees. This "seeking out new projects" behavior is typically only present in unpaid volunteer designer contributors and not in designers that are paid to work on an OSS tool. New opportunities may be found via an event, recommendation or conference talk/information and become excited about a potential collaboration on an OSS project previously unknown to them

Being paid for OSS contributions

All of the designers in the study were at one time, unpaid volunteer contributors. At the time of the study, only twenty percent of participants were paid full-time to work on OSS. Sixty percent of the participants were paid in some way for their contributions to OSS during the diary study period, either with a Part-Time salary or through project contracts. The remaining twenty percent described themselves as unpaid (though they received travel stipends for an event).

Eighty percent of participants stated that being fairly paid helped them with their livelihoods and demonstrated appreciation and respect for their design work. Designers also reported receiving ‘swag’ (tshirts, free tools and useful items) was an act of respect and appreciation for their work. Participants described OSS projects as having more flexible marketing budgets for aspects such as design, and stated they found it harder to be paid for UI, UX and design research.

One designer described being paid means the work is “more serious I guess?” and had an expectation that paid work would be better managed and planned by the OSS maintainers/teams, although the designer did not find this to be the case. Only twenty percent of the participants described the act of receiving payment as unpleasant (“I lose the joy when I’m paid”), and against OSS values (one designer described not liking the business aspect of OSS) whereas another participant spoke about the hope for universal income and that while that wasn’t a possibility they “feel lucky to be working on these projects and paid for it”. Another participant also described feeling lucky to be able to be paid for contributions and to speak at conferences. It’s worth noting the twenty percent contributing to OSS completely voluntarily had a full-time paid job. They spoke of the OSS community around them being composed of “people working state jobs” so they had relatively stable income in order to contribute to OSS.

Contrary to the above-mentioned view of pay being linked to business-like practices, one designer stated that “unpaid contributions causes burnout for volunteers”. We believe this is not solely linked to payment, but indicative of the absence of any kind of recognition or thanks for design contributions. Connected to this lack of appreciation is a comment by one designer about what is valued in OSS, and recognition across prominent OSS spaces such as GitHub “(It is) Sad that some people get paid for the same things you do. Makes you feel bad. Sometimes I joke about GitHub stars! And why is it only very technical people? Designers are still doing essential work. Big organizations or programs that help recognise designers are needed”.

When designers described not being paid in OSS, their focus was more around a lack of expectations on time, communication and commitment that comes with the freedom to choose when and what to contribute. This "structurelessness" comes with a particular learned impression of OSS as being governed "loosely" and in a way that allows for people to transition in and out of OSS contributions as they desire. A designer spoke of when an OSS project “devolves into cliques and possessiveness” where the “the main contributor has a lot of influence”, often dictating how the OSS should be designed and built even when designers are presenting them with user research that may evidence the contrary to their views.

There is still a notable absence of recognition of design and designers in OSS, and a narrative that design and designers are needlessly disruptive and pushy, sometimes even by the designers themselves. Being included within the existing systems of recognition is a good first step. Continuing to increase and improve designers’ visibility in these spaces is critical, yet a dedicated and specific way to recognise design in OSS is still needed so that design in OSS helps designers progress in their own fields of design. These fields of design are comparatively unaware of OSS as a viable place to practice design.

Designers in OSS and their busy lives

Below are some of the ways in which designers describe their goals at the end of the week study period, heading into their next working week. Most frequent goals listed first:

• Continuing ongoing weekly tasks already started for the OSS and preparing for any upcoming tasks

• Contribute more time to OSS

• Having design work “go live”

• Collaborating with others on OSS

• Talking to project leads about how the OSS displays and manages data on projects that use the OSS

• Focus more on a main OSS project

• Event planning

• Finding a better way to organize design issues on GitHub

• Taking time to explore design and sketch more

• Work being recognised by other designers and other open source maintainers

• Attending events to do with OSS

• Diversity and inclusion work

• Moving or creating design assets in Penpot to increase openness of design

• Coaching open source contributors

It was clear by the goals designers were setting, and some of the explicit comments they made they did not have enough time to fully explore design tasks in the way they wanted. They also mentioned not having time to act on important tasks. Talking and clarifying information with stakeholders was also high on the list of goals, and a consistent theme throughout the study. We can, however, see the range of goals that designers aspire to achieve as they progress through their design roles and contributions.

Designers described a number of differing life priorities, from postgraduate university studies to running their own business, to family commitments, to political changes in their country of residence, to paid work commitments and personal goals such as running half-marathons, to moving house and going to carnival. But they also struggled to balance OSS work with some unforeseen life complications such as unexpected travel, bureaucracy from employers, malfunctioning laptops, timezone difficulties and bandwidth issues. Designers lead busy and diverse lives, yet a consistent thread was that they didn’t get enough time to consider and work on the OSS they are aligned with.

Some designers skipped submitting diaries for vacation weeks, and had weeks where they described no progress being made on design contributions. This was also a tension at the start of the study as the designers checked in to ask what they should do if they "didn’t do enough work one week".

This seems to be connected to a common design challenge around nervousness in sharing work in progress (WIP) designs and also research study challenges around "have i done enough?". We corrected "have I done enough?" by reassuring our participants that we were interested in when they could not or did not contribute to OSS. That it was critical information in the process of design in OSS, and all participants understood why this was critical.

Sharing WIP design is a historically cultural challenge in design. As designers, we are taught that WIP design should stay within the design function until it's ready to be shared more broadly with developers and clients. This has changed with more participatory design yet there is still nervousness around what is shown to clients (or developers) because of the preparation for scrutiny inherent in the sharing. Therefore, designers often have the urge to share only "completed" designs with others, where "completed" means different things for each designer. In Open Source Design (and Open Design, a slightly different movement that is more to do with opening up design as a practice and process) sharing "messy" WIP files is encouraged. The comparable concept for development contributions is a “pull request” (PR) or “change request,” which is when a developer creates an event on a code repository and packages up changes that respond to one or more issues. Pull requests contain all of the code changes that were involved to address the change or improvement being contributed to the project. Although pull requests can be many different sizes and there are a range of norms around how a project uses pull requests, there is an unclear understanding of what is the comparable design contribution i.e. what does design need to be or look like in order to be regarded in the same way that a pull request is regarded for code contributions?

Ultimately understanding this is about defining what contribution processes are on OSS projects, and it can be, and arguably should be, an exercise for each OSS project to define collectively. This is also deeply intertwined with the way the tools (Gitlab/Github) work, e.g. a recent change on Github is the ability to have a “draft” pull request as a way of sharing early, messier development contributions. Due to the features available in the tools, OSS projects frequently define and document norms around code contributions, but less commonly covers design contributions. Trying to address the complexities involved in how design ‘fits’ into platforms and tools that are commonly used for development is a rich investigation area in itself.

What might make designers leave an OSS project and how might they want to exit an OSS project

The designers of the diary study had many challenges, mostly centering around communications, delegation, project/product management and the value of their work compared to time invested by them.

As stated in the communications and feedback sections many designers experienced the most difficulties when trying to communicate the design purpose, gain effective feedback or approval and work within time limits without much design support or working solo.

There were moments that some individuals seemed to be in extreme despair, where they were unable to receive help from fellow designers, unable to receive clear understandable and actionable feedback from developers/maintainers, and when working with a big OSS project team where discussions seemed to circle without clear understanding of what the design required in order to progress. This led to the designer being concerned “I don't feel safe to continue doing some things if no one responds and it turns into a bad cycle. We all waste time and (work will have to be) done again many things (have) already (been) done before". They then go on to make a proposal to the OSS project team where everyone in the OSS project proffers an answer. This situation is common in OSS projects where there are many participants and a lack of decision making governance. When absent, it typically becomes the added responsibility of the designer to aggregate and make sense of feedback as best they can, which could explain why many of the designers in our diary study spent much of their time on communications.

Designers often expressed disappointment when all of their time was spent on annotating specific details of a design artifact or document (e.g. This button in a UI does X, this usability study means that we know X about users etc.) or justifying why design should be done in the OSS, and no time was spent producing those artifacts or documents that directly contribute to design of the OSS in a given week. “Sometimes I wish I did proper design, not just talk about design. I get that it's part of the contributions, but I would love to work on projects as a designer.” Here you see the designer is aware of the necessity of communicating the purpose of design and clarifying design artifacts, but is fatigued by the consistent need to explain why and how design is done and what it improves.

Similarly, when a designer wastes time, they are frustrated as they know how precious the resource of time is “(I was) missing an InDesign file and wasted about 6 hours of my time (editing files in acrobat)”. This problem was shared by other designers about other tools they were asked to work in due to the choices of the OSS.

We asked a question to our designers not often asked to any OSS contributor. We asked how they’d like to leave a project and how they would like the design aspects to look when they leave. The designers in our study found this a confrontational question and particularly difficult given they don’t have a clear sense of who else in the community could continue their OSS contribution work, if there was anybody at all that could continue. Designers are a rare (but growing) resource in OSS and this is reflected in the answers to these questions which was largely described as a difficult question.

• Designers want seven things to be present before they leave an OSS project:

• The design work is done and continues to be done in open design software (so not proprietary closed software such as Adobe). However, these open source design tools are stated as "not as good as closed tools"

• The design is left in a way that other people can pick up and understand

• To leave the OSS in "a better place" in terms of design (this would be unique and specific to each OSS)

• To ensure that the OSS maintainers know how and what was done and the project is handed over slowly and carefully. Do not “ghost" and help knowledge be sustained

• To know the design will change after you"ve gone. OSS is about sharing and being willing to accept changes

• To plan the structure for the OSS to not just recognise design contributions but document them well too

• To inspire designers to get involved in the OSS

Most designers expressed a desire to never fully leave an OSS project and they would ideally stay on in an advisor role and be able to answer questions when needed. For many, participation in OSS was an ethical or socially motivated reason. In answering this question they wanted it to be known that they would never be truly "gone" from OSS.

Potential Future Research & Recommendations

Scaling up and continuing this work

This study was one of the first to capture OSS designers' experiences across multiple weeks and see what patterns and insights we could learn about designers' participation in OSS. There are however, many missing components to this study and many aspects that would benefit the OSS community widely.

These include:

• Inviting more OSS projects and community members to interviews, including those who collaborate with designers

• Better understanding the ways in which different roles view design and designers alongside the purpose of the OSS

• Including different types of OSS projects (e.g. OSS with an academic research focus vs OSS that is a developer tool etc)

• Exploring ways that enable us to better understand the scale and type of OSS projects and their design challenges

• Investigating what design challenges are common across all/most OSS projects

• Investigating more of the designers' contribution motivations and history in interviews: From a subject matter expertise point of view, Time spent contributing or observing OSS, Intended goals for OSS participation

In the future, we’d like to directly observe designers to see how their design contributions move through design stages to implementation within the OSS. We believe this will reveal the nuance in communications, delegation and the time needed to overcome the design challenges discovered in this study.

In order to be inclusive, ensuring we have adequate support for the inclusion of non-English language speaking designers to participate fully in this study would ensure we have a more global perspective on OSS design.

And finally, simply repeating the study with regular cadence allows us and others interested in this research to find trends and changes.

Emergent Recommendations

As an OSS project interested in receiving design contributions, review and take note of the ways in which designers decide whether to offer design to an OSS project. Some of these indicators for designers include ‘ Is the project clear what problems they want solved by the designer?’ and ‘Is this OSS a one-person project and is it still active?’ See ‘How do designers decide whether they’d like to contribute to or work on an OSS project? ‘ section.

Know that most designers are going to use commercial, proprietary tools to create design unless offered, encouraged and supported to use free and OSS alternatives. See ‘What tools do designers use when contributing to OSS?’ section.

All participants mentioned getting feedback from the developers as a crucial step in their design process. Often, designers go out of their way to ensure better collaboration with developers. See ‘Designer-developer collaboration’ section.

Designers measure success in many ways but common these are through healthy feedback cycles with usable suggestions for design, having designs implemented, understanding priorities and who/how decides them, growing the design community sustainably and being acknowledged positively for their contributions. See ‘Designers speaking about success’ section.

Communication is a difficult process and designers make great efforts to ensure design contributions and the purpose of design is communicated well. Making equal efforts to understand design’s purpose and benefits is a positive step for OSS. See ‘The long cycle of communication in OSS’ section.

Ensuring your governance and decision making processes are documented and accessible to designers will help them understand how decisions are made. Having transparent ways of how designers can hold decision making power in the OSS includes both design and users' voices. See ‘Processes: who makes decisions and how are they made?’ section.

A way to improve user centered design in OSS by helping designers to define rough definitions of user types of the OSS collaboratively with OSS project team members. See ‘Who are the ‘users’? section.

There is a gap for open resources for designers' contribution to OSS and the OSS projects themselves around asynchronous usability testing processes, formalization of usability insight and helping to understand when user feedback is at a state that is permissible or substantial evidence to progress a user centred design decision. See ‘Who are the ‘users’? section.

Being included within the existing systems of recognition is a good first step. Continuing to increase and improve designers’ visibility in these spaces is critical, yet a dedicated and specific way to recognise design in OSS is still needed so that design in OSS helps designers progress in their own fields of design. These fields of design are comparatively unaware of OSS as a viable place to practice design. See ‘Being paid for OSS contributions’ section.

Understanding and defining what contribution processes are on OSS projects for design is an exercise for each OSS project to define collectively with designers. This is also deeply intertwined with the way the tools (Gitlab/Github) work. See ‘Designers in OSS and their busy lives“ section.

As OSS projects interested in sustainability of their OSS, considering the list of what designers would like to see happen to design in OSS as they transition out of contributions can help to guide succession planning in design. See ‘What might make designers leave an OSS project and how might they want to exit an OSS project’ section.

Literature and research referenced

In order of appearance:

1. Raza, Arif and Luiz Fernando Capretz. “Do open source software developers listen to their users?” ArXiv abs/1507.06893 (2012): n. Pag. https://api.semanticscholar.org/CorpusID:1733658

2. Hedberg, H., Iivari, N. (2009). Integrating HCI Specialists into Open Source Software Development Projects. In: Boldyreff, C., Crowston, K., Lundell, B., Wasserman, A.I. (eds) Open Source Ecosystems: Diverse Communities Interacting. OSS 2009. IFIP Advances in Information and Communication Technology, vol 299. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-02032-2_22

3. Mads Bødker, Lene Nielsen, and Rikke N. Orngreen. 2007. Enabling user centered design processes in open source communities. In Proceedings of the 2nd international conference on Usability and internationalization (UI-HCII'07). Springer-Verlag, Berlin, Heidelberg, 10–18. https://dl.acm.org/doi/10.5555/1769821.1769824

4. Rajanen, Mikko & Iivari, Netta & Lanamäki, Arto. (2015). Non-response, Social Exclusion, and False Acceptance: Gatekeeping Tactics and Usability Work in Free-Libre Open Source Software Development. 10.1007/978-3-319-22698-9_2. https://link.springer.com/chapter/10.1007/978-3-319-22698-9_2

5. Author Bolici, F. (2016) Stigmergic coordination in FLOSS development teams: Integrating explicit and implicit mechanisms. Cognitive Systems Research, vol. 38, Science Direct, 14-22. https://doi.org/10.1016/j.cogsys.2015.12.003.

6. Woolgar, S. (1990). Configuring the User: The Case of Usability Trials. The Sociological Review, 38, 58–99. https://doi.org/10.1111/j.1467-954X.1990.tb03349.x

7. Philip E. Agre. (1995). Conceptions of the user in computer systems design. The social and interactional dimensions of human-computer interfaces. Cambridge University Press, USA, 67–106. https://dl.acm.org/doi/10.5555/214811.214823