Designer’s lives: Designers in OSS and their busy lives

[Erioldoesdesign]

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.