Processes: who makes decisions and how are they made?

[Erioldoesdesign]

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.